I settled on the current button input scheme for FATCAT pretty early on in the design process. But since I realized I've only mentioned it in passing so far, I'll just write this short log specifically on that subject. 

How it works

The input scheme is super simple. There are three buttons: Left, Right and Enter. Each button can be used for two input actions: The first action is just a short button press. The second is press and hold. The system response to those actions will depend on the current system context.

Button	Short press Action	Press & Hold Action
Left	L	LH
Right	R	RH
Enter	E	EH

That's it! There are no button combinations or double-clicks or anything like that. Just three buttons, used to perform a total of six input actions.

The reason why

There are few parts of the UI where it would've been tempting to use a more creative input scheme. One such part is the PLAY mode (see the "User Operations Flowchart" in project files). In that mode, E is used for cycling between playing individual tracks solo. But sometimes you'd also want the option to cycle between muting individual track. But alas, there's not enough buttons for that. One way to activate muting would be by using a double-click or some combination of buttons.

Another use for extra input actions would be as shortcuts to functions that currently requires navigating the MENU mode. Such shortcuts could be used to speed up the song editing process somewhat. 

However, there are two reasons against implementing those kind of solutions:

The first reason is consistency: The UI outputs very sparse information, and it doesn't explicitly tell the user what information is shown at the moment. It's all fine as long you remembers what op mode you're in. But once you get "lost" things can get confusing, especially if you're in the process of learning how to operate the device. The UI will give you subtle hints on what the current op mode is, but an inexperienced user might rely on trial end error in trying to navigate back to a familiar state. Such a process would certainly be more frustrating with a large number of possible actions at your disposal. It would also become less appealing to attempt using trial and error as a method of learning the UI, for the same reason. 

The second reason is performance: FATCATs hardware design demands that button inputs are registered by means of polling. For the UI to remain responsive during playback, polling must periodically interrupt the program loop that generates the playback audio stream. A higher number of possible input actions makes these interruptions longer, which in turn increases the risk of audible distortions. Although it's unlikely that polling of a few more input actions would result in any substantial difference in that respect, I still find it prudent to keep polling duration at a minimum as part of an effort to minimize CPU workload in time-crucial parts of the main loop.

Side note: I implemented the feature for individual muting of tracks by dedicating a special patchbay connection to it, which modifies the behavior of the E action.

Triggering of input actions

In general, Left and Right are used for cycling through values, while Enter is used either for selecting the current value (using E) or to activate an alternate function (using EH). 

For that reason—although the input actions are the same for all buttons—they way they are triggered works differently for Left and Right as opposed to Enter: 

• The L / R action will trigger immediately after the corresponding button is pressed. After a short delay the LH / RH action will trigger repeatedly for as long as the button is held. 
• The E action will only trigger once Enter is released. If the button is held for a certain time, EH will trigger instead of E. Holding the button after that point will not trigger any more actions.

Since the system response to E is generally of a different nature than EH, only one of them can be allowed to trigger on any press of Enter. For that reason the system must await Enter release before interpreting the action.

L / R will generally result in the same system response as LH / RH. While editing a song for example, R will advance you to the next step of the song, while RH will auto-scroll forward through the song. Because of this, it doesn't make sense to wait until Right is released before registering the R action; That would only make the UI unnecessarily unresponsive. 

There's one exception to that rule though: In PLAY mode, L / R is used for changing patterns, while LH / RH is used for changing the song tempo. The systems way of handling that is to first switch pattern when L / R triggers; Then if the button is held long enough to trigger LH / RH, the pattern switches back and the tempo starts changing instead. That's an ugly solution, but I use it nevertheless since I put a higher value on UI responsiveness.