I added on a little module to allow rings to switch resonator mode with a trigger input.
does anyone know if it would be possible to change the code of rings to allow polyphonic voices to carry through resonator mode switches?
Currently it cuts off previous audio and starts anew.
A small solid state relay! Works like a mechanical button but instead of your finger pressing it, a voltage presses it. I soldered some wires from the back of the button to the relay so I could either use it manually or with a trigger. you can also send it the same voltage for a while (like a long press) and it works the same way.
I gotta say that’s pretty cool! Didn’t know that was such a straight-forward mod.
I wonder how significant a rewrite that would be. It would require having two modes simultaneously active and my intuition would be that might too much for the module’s on-board processor. I’m genuinely curious what @pichenettes says on the topic.
You’re going to deal with three problems actually:
- Gain management. At the moment it’s done globally, with constants making sure that the different resonator types roughly give the same output amplitude. You’ll have to rework this to account for the fact that each voice will need to have its own gain in the mix. https://github.com/pichenettes/eurorack/blob/master/rings/dsp/part.cc#L569
- Per-string resonator type setting. You need to keep track of which resonator type was active whenever each of the 2 or 4 strings was plucked, instead of having a global active resonator type (it’s called
model_) variable that is updated every time the button is pressed. So you need to keep an array with the active resonator type for each string, and whenever the button is pressed, you’ll have to instruct the module to only change the resonator type for the next string, whenever it is plucked. This is doable, but with a lot of code refactoring. When deciding which rendering function to call (https://github.com/pichenettes/eurorack/blob/master/rings/dsp/part.cc#L520), you’ll have to use the per-string
model_ setting rather than the global setting.
- The most serious problem is that some initialization code is called whenever changing the resonator type. You can’t avoid that because, for example, when you’ve been using the modal resonator, the virtual string hasn’t been fed any sample and haven’t had its parameters updated, so if you suddenly start updating the parameters of, and feeding samples to, the string, you’ll get a nasty glitchy discontinuity. That’s why I reset the state of the string and modal structure whenever the resonator type is changed (https://github.com/pichenettes/eurorack/blob/master/rings/dsp/part.cc#L67). You’ll have to experiment and find a compromise between the glitch caused by correctly resetting the string/modal structure (it takes some CPU cycles to fill those samples with 0s), and the glitch caused by not resetting anything.
Note that the most graceful behavior would be to run in parallel the excitation signal into resonators of all types, and crossfade at will between them. But that would require several times the available computational power.
Thank you for all of the info!
If I flashed this IC might it be able to handle parallel excitation?
or at least handle maybe 6 or 8 voices instead of just 4?
This is a different IC family, so you will have to rewrite all the low-level code, and redesign the board too. At this cost you might as well buy a second Rings and a crossfader