Buses proposal

[bwhitman]

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.

[bwhitman]

A more concrete buses spec:

We make a new parameter Y = bus_input. bus_input can be 0-7 (internal rendering buses), or 8-15 (external input buses). bus_input is 0 by default (if not given)

We also make a new parameter z = bus_output. This is 0 by default (first stereo output) but can be up to 7.

Ignoring audio in for now, imagine a Juno-6 patch that has Y1 in it. This would mean that any (eg) chorus, EQ, or reverb command only turns on for that bus. We also make a Y2 for every dx7 patch, so that those effects do not render for those patches. We implement this by having more fbl in our rendering (instead of 2, we can have 8 of them)

Now, I want the audio in to go through an echo. I send AMY Y8M1. This tells AMY that bus 8 (first external input) goes through echo with level 1.0. I can render effects on any input.

Not giving bus_input (which really means bus_input=0) means the rest of the AMY commands in the message render into a default bus (the way it works now). Audio input will not be affected if bus_input is not given with an effect command.

To mix buses, we can use volume. Y9V0.5 will change the volume of the first input. To set pan on buses we use pan. V9Q0,1,1,1 sets the PAN_COEFs for a bus.

To send buses to other outputs, we can use bus_output, so e.g. sending external input 0 to the output bus 1 is Y8z1. bus_output is 0 if not given, the default now, just sending audio to the first output.

Buses are stereo pairs. I could imagine a future bus parameter that breaks apart stereo pairs and allows you to address channels individually but we shouldn’t worry about that now.

Buses can be a list of buses. bus_input = 1,2 should work. So should bus_output=1,2

[dpwe]

I feel like a bus is a bus and an output is an output. Oscs are assigned to buses, each bus has effects parameters. Then outputs are mixed down from buses. I think this is pretty much your syntax, it's just the terminology.

In this view, external audio-in could be another bus as you suggest (instead of an osc). I'm not sure how to pan a mono external input - right now pan is a property of an osc, and I think of buses as all stereo. I'm not crazy about a pan parameter in the final mixdown, but it's possible, then another flag to make a bus mono?

[dpwe]

Oh I think maybe there's a difference in how we specify the final mixdown. Your bus_output=1,2 suggests you set the output as a property of some signal source.

For me, that would be output_1_mix=',,1,,,', output_2_mix=',,1,,,'. Which signals appear on which outputs is determined by independent parameters owned by each output; it's not the source's business.

My approach allows the precise mix level on each output to be set differently, a bit reminiscent of ControlCoefs vs mod_target.

[dpwe]

Here's what I'm thinking now:

• Each osc has a bus parameter, e.g. v0y0, or, more likely, i1iy0 (assign all the output from synth 1 to bus 0). All busses are stereo. When that osc renders, the final destination of its panned output is determined by its output bus. The osc can only contribute to one bus, and there's no separate gain, it adds into that bus at 100% of its level. This is your (internal) bus_input
• Each bus has independent FX i.e. EQ, chorus, reverb, echo. y0x-3,0,3 to set the EQ for bus 0.

Note: There's something a bit subtle here: events have an implicit object-field structure: Traditionally, an event has a specific osc to which its field values apply; voice/synth commands are generalizations, with osc(s) is/are implied, and global FX are exceptions since the osc is ignored. For an osc-directed command, bus is just another field to set (so, another value in struct synthinfo). But there are now bus-directed commands (e.g. commands to control the FX), where the same field in the message now specifies the object of the command. I don't think this will cause any problems, although it does allow some odd constructs like v0y1M0.5 - assign osc 0 to bus 1, and set bus 1's echo level to 0.5.

So, a multitimbral setup with multiple Juno and/or DX7 preset patches would put each synth on a separate bus, then add the preset-patch-specific EQ and chorus settings appropriate to each bus. Then, the final output would have weights of 1 for all those busses, so they all are mixed into the output.

• We additionally have outputs, which are defined as set of mix weights applied to each of the busses.

We could define other outputs with additional vectors of bus-mix weights. I'm not sure if we want to have a whole series of generic outputs 0..N, or whether we have specific commands for each named output type, e.g. main_audio_mix=[1,1,1,0,0,0,0,0], cv1_out=[0,0,0,1,0,0,0,0]. I think this covers your bus_output concept. Probably we give each output a specific number (main audio out = 0, CV out 1 = 1, etc.), then have the mix command be Y<output_number>,<bus 0 gain>,<bus 1 gain>,....

You mention 8 "external input busses". Right now the single stereo audio_in is materialized as a signal with AMY as an osc with wave=amy.AUDIO_IN0. These inputs can have ADSRs and gains controlled by vel inputs, can have filters applied, etc. If, instead, audio_in appeared on its own bus, we could still apply FX independently to that bus, and mix it into the output at its own level, but we couldn't put it through a VCF. In the future, one could imagine a wider range of signal-processing primitives within AMY that could be applied to audio input signals (or the output of other oscillators, e.g. via busses), but we don't really have that yet. But if we did, we would probably define its input as a bus arg.

That might lead to some interesting order-of-evaluation issues, like, if a unit takes a particular bus as input, do we expect it to be this frame's values for that bus, or the preceding frame? If it's the preceding frame, we'll need to consume the input block before we start writing it again for this frame. If we want it to use this frame's values, we'll need to make sure that all the modules outputting to that bus have executed for this frame before we process their combined outputs. And what happens if the audio-input unit tries to write out to the same bus? I guess the easiest fix there is to require that a unit using a particular bus as input must have a higher-numbered bus as output, then evaluate the units sorted according to their output bus.