Buses proposal
bwhitman opened this issue · comments
We have a couple of quality of life issues that a "bus" could help us obviate
- some patches use chorus, some do not. chorus is currently synth-wide. so it makes it hard to do a multimbral operation
- some patches use EQ, some do not
- we would like to route some signals to non-audio ports (DACs for CV operation)
Let's add a bus construct, where oscillators are rendered into a bus and effects can be added after summing into that bus.
If this sounds complicated, never fear, we already have two buses! fbl
is used on multi core hardware to render a group of oscillators. We then sum those and add effects to them together. What if fbl
could be, say, up to 6, instead of two, and you can assign oscillators to a bus number. By default, they would be set up like they are now, into two buses by their osc #, (0-AMY_OSCS/2, AMY_OSCS/2-AMY_OSCS)
. But a parameter, say, U
/ bus
, can be added to the oscillator to override this bus.
Then, synth wide "effects" like (currently) chorus, reverb, eq can also have U
/ bus
set alongside them (with default being all active buses), e.g. chorus_level=1, bus=0,1,3
. And (for example) juno patches can have bus numbers pre-set into ones that need chorus / eq / etc and those that don't. Then dx7 and juno voices could be played simultaneously with chorus only on the appropriate ones.
(Future) a bus can be indicated as non-audible, or have its volume set per bus for mixing. Other C code could peek into a bus to, for example, send the bus output to a non-audio sink, like a i2c DAC on Tulip for modular synth ramps.