Feature request wot I just done thought of

[skitchy]

Okay, so here it is - crosstalk between instances of MUX.
Essentially, in one instance of MUX, you create a 'send' module and assign it a 'channel' value. Then in another instance of MUX, you create a 'recieve' module. By assigning the 'recieve' module the same 'channel' value as the 'send' module, any audio data plugged into the 'send' module is sent through a virtual wormhole to the 'receive' module.

Its actually not a new idea, and I have actually requested it in a few other software packages over the years, but nobody has ever implemented it AFAIK. I know it is technically possible though as there are some plugins that do this sort of thing already (SKNote has one I think).

The obvious use is sidechaining, but I can think of a whole load of others

[> DiGiT <]

This is definitely a request thats been voiced before (by me) and although there are a few ways around it using existing technology, none of them have acceptable latency. passing midi from one mux to another can be done well enough but not audio.

[MuTools]

I had some draft thoughts about this and i think there might be serious difficulties wrt multi-core processing. When plug instance 1 is directly sending realtime data to plug instance 2, then what if the host processes PI 2 before PI 1?

[pljones]

That sounds like it would be an issue on a single core as much as on multi-core. If you have two instances of MuX, how can it tell the host there is a dependency between the two and the host should processed one before the other? You also have the problem that if the data was meant to be returned from the second instance to the first (i.e. the second instance is an effect), you're immediately introducing a delay that wouldn't be there if there was a single instance - i.e. bufferA in MuX1 gets sent to MuX2 for processing, so MuX1 is now waiting for the result -- how is this handled?

I guess everything could go via an external process, with the VSTs just being tiny little agents that (a) provided a UI and (b) conveyed data to/from the host and the external process. The external process would then have to act like a "stand-alone" MuX. I can see this could still have sync issues...

[MuTools]

That sounds like it would be an issue on a single core as much as on multi-core.

You're right, indeed.

I guess everything could go via an external process, with the VSTs just being tiny little agents that (a) provided a UI and (b) conveyed data to/from the host and the external process. The external process would then have to act like a "stand-alone" MuX. I can see this could still have sync issues...

And not really a dev area i intend to go to.