Feature request: Ambika interface with stateless page memory, for non-visual operation

I originally posted these thoughts to a visually impaired potential Ambika user in a gearslutz thread and I believe my thoughts there were relevant to discuss here as well:

Do you think it’s a good feature that the Ambika remembers what page was last selected beneath each of the eight switches? In other words, if you’re on the S1 mixer page and move to the S2 filter page, and then press S1 once, you’re taken directly to the mixer page, and not to the oscillator page? Or would it make more sense to always “press S1 once for oscillators, S1 twice for mixer, S3 twice for voice LFO”, and so forth?

I believe it would be easier to operate the Ambika purely from muscle memory, if there always was a consistent sequence of button presses and knob twists to set a specific parameter.

There is one problem though, and that is the S8 system pages. The parameters on the system pages depend on the switches below, which means that there doesn’t seem to be a way to escape out of the system pages reliably with a specific user input - you’ll always need to check visually on the display what page that is active. Nevertheless, I believe that a move towards stateless page memory would be a benefit to anyone who doesn’t like to depend on looking at the display when operating the Ambika. And as long as the amount of subpages is three or below, you save more time by having a consistent set of steps to change a parameter, than the supposed time you “save” by having the system remember your last active subpage beneath a switch, but with you then having to verify this state visually every time you press a switch.

Any thoughts of the benefits and drawbacks of stateless page memory? Am I the only one who feels that I’m constantly arriving on the wrong page by accident? Especially on the Shruthi, but also for the Ambika. (I realize that this is only possible for the Ambika which has a very flexible knob/switch layout - the Shruthi interface is simply too crowded for a stateless interface to work)

I like that it remembers where it was last… Makes more sense to me. The way Ambika works now is a very depended on visual feedback through the display anyway.

Remove this line and you’re good to go!

https://github.com/pichenettes/ambika/blob/master/controller/ui.cc#L395

Thanks for the tip, Olivier!

I’ve been able to successfully build the Shruthi firmware before, so this should be possible for me to test out on my own.

Forgive me for being a useless idiot - hopefully I’m just a confused soul with no programming experience:

How do I build an ambika.bin that I can put on the SD card? I’ve tried the commands “make”, “make all”, “make bin” and “make bootstrap_controller”. But none of them seem to give me a .bin for the controller, it’s either a .bin for the voicecards or a .hex for the controller.

Can I maybe upload the “ambika_controller.hex” using SysEx, following the instructions for “Emergency firmware update” in the manual? Or do I need to use an AVR programmer for this, according to the instructions on the Ambika firmware installation page? I was hoping to avoid opening up my Ambika.

make -f controller/makefile bin

Thanks again. :slight_smile:

I’ll try this out when I get home tonight.

It works perfectly! Many of you will probably not notice the difference, but at least I can now manipulate the Ambika with much more confidence.

I’ve attached the compiled .bin here, in case any of you are curious and want to try this change yourself.

ambika.bin-stateless-ui.zip (34.5 KB)

This might actually be a nice preference to add.