99 Presets (of Beer on the Wall)
I have revisited the UI code and now have (what I believe to be) better ways to handle the reading and writing of presets. It's back to the separate "Load" and "Stor" encoders I had in the first place, but it retains the two step write process, and adds new "following" features, as well as multiple system presets.
As before, the two-step write requires two sequential presses of either the "Stor" encoder or the new write pushbutton (in any combination). The first press places the write logic in the "armed" state and now changes the encoder label (rather than the encoder value, as I was doing previously) from "Stor" to "!WR!" and blinks an LED. The displayed "Stor" encoder value remains the write target slot (which is good), and once the write is performed the "Load" encoder is set to this value too. Having "Load" follow "Stor" after a write seems like the safest thing to do, as you generally want to play and edit the copied-to preset after a write, and not the copied-from source. And if the value of "Load" was different than that of "Stor" then the "Load" value change is additional confirmation of the write.
Similarly, loading a preset by rotating the "Load" encoder sets the "Stor" encoder value to the same as that of the "Load" encoder (unless "Load" is set to a negative read-only slot, whereupon "Stor" is set to zero). Having "Stor" follow "Load" after a preset read makes things safer because it automatically sets the write (and any edits you may be doing) to the slot & voice you're currently playing, and not some other (& therefore dangerous) slot. I believe Roger suggested this change something like a million years ago - and as usual he was right!
By the way, the new SW debounce filtering is working like a champ on the sleazy RS write pushbutton, which I admit was a pleasant surprise! I thought the debounce period might be too short for it, but I haven't seen a bounce or glitch out of it yet.
I've also implemented more than one slot for the global system preset parameters. The motivation behind this is to cover the case where more than one person plays a particular D-Lev regularly, and perhaps one of the users likes a reversed volume field sense, or a non-linear volume field, or a different pitch field sensitivity, or a shifted pitch field, etc. I've found changing these types of settings even slightly to be quite disorienting to my playing "style" and comfort level, a direct indication of how much I'm relying on "muscle memory" and spinal training to hit (or not hit, truth be told) the notes. Even if the axis numbers were written down, it would be a bother to have to dial them back in every time you wanted to play the thing. So saving them for each player is an important good thing, and the question is then how best to do this.
Previously, writing to preset slot 0 also stored the system parameters, and powering the thing on was the only way to load them. This worked pretty well, but it obviously only covered the single user case and felt a bit non-intuitive. Things were arranged so that preset [-127:-1] were read-only, and [0:127] were read/write. Slots [-127:-1] could only be written to via the serial port librarian software, so they played the role of "factory" presets, and slot [-128] was where the lone system preset existed.
At first I tried the following, using the "Load" and "Stor" two encoder arrangement for everything:
[-127:-120] read-only system presets
[-119:-1] read-only voice presets
[0:119] read/write voice presets
[120:127] read/write system presets
To keep the system presets from instantly loading when the "Load" encoder was set to them, I made it so system preset reads required the pressing of the "Load" encoder to actually do the load, but this produced two unfortunate side effects. The first was the loss of zeroing "Load" by pressing it, which I missed more than I thought I would. The second was the unavoidable loading of slot 119/-119 when transitioning up/down to the system preset zones, which was just weird.
In the end I decided to pare the number of voice presets down to the following:
[-99:-1] read-only voice presets
[0:99] read/write voice presets
Unlike most other digital sound equipment/software that I've used, this is my first "bowing" to base 10 on the D-Lev, and I'm only doing it because I can't use the full range in the first place - and reducing the range gets me out of having to come up with tons of voices to fill it!
Access to the system preset load & store slots has been moved to two new "Load" and "Stor" encoders on the SYSTEM UI page:
[0:3] read/write system presets (located at slots [100:103])
This allowed me to restore "push to zero" back to both of the "Load" encoders, as loads can (and do) happen as soon as the "Load" encoder is changed to a new slot (with the "Stor" following it as described above).
I also decided to nix the read-only system presets. They do have a use (immutable store for safety) but in the end their inclusion seemed more fluffy and confusing than substantial and useful. Four R/W system presets should be more than enough. As with the voice presets, system slot 0 (@ slot [100]) is loaded at power-up.
As a result of this exercise I more closely examined the roles of both sets of "Load" and "Stor" encoders, and I ultimately removed them from the system parameter EEPROM save / restore mechanism. The only other encoder also outside of system storage was the UI page encoder on the lower right, and I was able to incorporate the display of it into the normal display of the other encoders. It's more consistent and cleaner now.
So there it is, the first 90% of the D-Lev SW required 90% of the development time - and the final 10% required the other 90%!