Feature request wot I just done thought of
-
- KVRist
- Topic Starter
- 335 posts since 20 Jul, 2010
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
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
-
- Banned
- 897 posts since 8 Jan, 2005 from Detroit
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.
- KVRAF
- 12739 posts since 24 Jun, 2008 from Europe
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?
- KVRAF
- 7137 posts since 8 Feb, 2003 from London, UK
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...
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...
- KVRAF
- 12739 posts since 24 Jun, 2008 from Europe
You're right, indeed.pljones wrote:That sounds like it would be an issue on a single core as much as on multi-core.
And not really a dev area i intend to go to.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...