On implementing side-chain support

[tzhau]

Side-chaining is where an auxillary audio signal is not mixed directly into the plugin output. A classic example is the vocoder, where your voice modulates another sound.

Events (zzub peer control) and side-chaining (vocoders, modulators) share conceptual similarities, and I further believe a shared base could be possible.

Events are typically processed at each tick, while a side-chain signal needs to be processed at sample level.

Use case: A sinusoidal modulation of a filter cutoff. Done as an event it is sent at each tick, but this means that at higher frequencies the sine would be sampled at far too low a frequency than required. Resulting in a stepped sound. For higher frequency sines or perhaps modulation with your voice, you would need to side-chain an audio signal into the parameter. The plugin would probably be tailor built for this purpose.

Not all parameters can typically be side-chained though. Notes and parameters that lead to filter coefficient recalculation for example. And currently zzub plugins could support side signals only with plugin_does_mixing and some input() calls.

So my proposal for implementing side-chaining:

1.) Make a connection type that is specific for audio signals that can modulate a plugin parameter.

2.) Make it so that all sidechain connections are not mixed into audio output.

3.) At each tick, set the parameter bound to the side-chain to the signal value.

This would be the default for all parameters, keeping in mind tick bound parameters such as Note and Filter coefficients. 4.) Now it is up to the plugin self whether it would support further side-chaining for a parameter.

Typically phase parameters for flangers and filters. Implementation by calling an input() method or perhaps auto-incrementing pointers. So summarized: Side-chaining defaults to event for all parameters, with deeper resolution available if plugins support it.

Now that side chaining does the job of events in essence, a second goal is perhaps to merge the two in the future. Events are then basically audio data...everything is data...a simplicity in that, from the dataflow languages. Advantages:

1.) Event effects are possible. (Transpose the notes up or down, Arpeggiators).

2.) Same infrastructure used on audio can be used for events. (creation, inspection)