It’s specific to the Sweet Sixteen - a Eurorack Adaptation of 16n.
If you’re using I2C to connect a 16n and an ER-301, the ER-301 needs to be on before the 16n tries to connect in Master Mode. Now, if you’re using a desktop unit, that’s easy: wait for it to turn on, and then connect. But if you’re running everything off the same Euro power supply, it’d be useful to force the internal code on the 16n to delay starting up, to ensure it can connect.
I know this because there are people using 16n + ER-301 entirely happily without such a feature.
My inclination is that this is a derivative work, rather than the original, so it’s up to the derivative work to maintain its own firmware. I’m also not convinced it’s worth a byte of editor config. (Yeah, yeah, one byte, but I’m trying to keep my total “device options” config to 16 bytes for $reasons).
Alternatively, this is exactly the sort of configuration that every Sweet Sixteen user would want, which means it could be set at a firmware level, rather than an editor level. Which would keep the implementation much like it currently is: set a configuration define in the config.h file to enable the delay, if it exists, do it. Then, maintaining a fork of the firmware would just involve setting one configuration option in a header file. I’ll note that Sweet Sixteen is kinda running its own fork anyway, what with its “using pitchbend as a high-resolution CC”, which I have not implemented.
What we are running into here is a classic open source dilemma: when is a derivative work a different thing, rather than the same thing?
I’m not hugely into making decisions about the firmware that runs on 16ns based on devices that are… very clearly not desktop faderbanks. But, for instance, the editor has no provision for channel outputs that aren’t CCs right now, either, so adding “this one feature” still doesn’t mean the Sweet Sixteen is fully supported by the editor software.
I’ve mentioned this in DM with @M4ngu, but may as well share it out loud now it’s been raised here. My preferred implementation would be:
- Sweet Sixteen continues to maintain its firmware fork.
- It just has a default delay on boot anyway, no issues there, and it maintains that via a simple code flag (as I think it can be set to a value most users wouldn’t complain about even if they didn’t need it)
- I’m happy to add to the devices list that the editor supports; the correct device ID would also have to be implemented in the S16 firmware. (This is an easy alteration).
- Then, in future, if somebody wants to extend the editor (and S16 Sysex spec) to support the pitchbend style configuration, as long as it didn’t interfere with existing firmwares, I’d consider that patch. I’m not interested in writing that patch myself.
