Bus concept, more semantics with channels?

[p0nce]

Instead of N ins, M outs, a plugin would specify buses and each buses would have a (potential?) number of channels.

For VST 2.4 the bus would be flattened.

This item would require to put more knowledge of bus and channels into the client (currently they only exist in the audio callbacks), in order to implement bypass and other things in this place too.

Some things are in clients derived implementation when they should be in parent.

Hopefully this would allow to be more harmonious with how AU work, and handle mono and stereo buses likewise. The main problem is that I know next to nothing about VST3 and AAX, and that IPlug is like that for a reason.

[p0nce]

• Need to know how AAX handle this first.
• IPlug2 is like IPlug in that regard

[p0nce]

Should fix #186 first.

[p0nce]

AAX has a better design imho than that, it defines a format for input, a format for output, and eventually format for "aux" inputs.

[p0nce]

I don't think it's critical until someone wants a sidechain input.

[abaga129]

This is something I would like to look into more closely. On the client would this replace LegalIO or would you think LegalIO and Buses would work together?

[p0nce]

LegalIO would need to be replaced by a new description

[abaga129]

Checklist to implement this

• [ ] #186
• [ ] Decide on bus semantics for Dplug:client
• [ ] VST implementation
• [ ] VST3 implementation
• [ ] AU implementation
• [ ] AAX implementation
• [ ] LV2 implementation
• [ ] Test, test test!!!

[p0nce]

This is entirely related to a WIP implementation of "Audio Modules" in #259 (EDIT: mmm, can be left for later)

[p0nce]

Is there a way to do it while maintaining compat for 1-1 and 2-2 plugins? would be awesome... else it will be extra painful to have differet path for "bus" and "non-bus" clients.

Or perhaps the generic Client needs to be rewritten to be plugin format-like, and then the various clients can be ported to Client2.