What is KVR Audio? | Submit News | Advertise | Developer Account

Options (Affects News & Product results only):

OS:
Format:
Include:
Quick Search KVR

"Quick Search" KVR Audio's Product Database, News Items, Developer Listings, Forum Topics and videos here. For advanced Product Database searching please use the full product search. For the forum you can use the phpBB forum search.

To utilize the power of Google you can use the integrated Google Site Search.

Products 0

Developers 0

News 0

Forum 0

Videos 0

Search  

Feature request wot I just done thought of

Official support for: mutools.com

Moderators: mutools, muzycian

skitchy
KVRist
 
310 posts since 19 Jul, 2010

Postby skitchy; Fri Feb 22, 2013 7:13 am Feature request wot I just done thought of

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 <
Banned

Postby > DiGiT <; Fri Feb 22, 2013 9:45 am

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
KVRAF
 
5552 posts since 24 Jun, 2008, from Europe

Postby mutools; Sun Feb 24, 2013 2:13 am

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?
User avatar
pljones
KVRAF
 
4555 posts since 8 Feb, 2003, from London, UK

Postby pljones; Sun Feb 24, 2013 9:43 am

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
KVRAF
 
5552 posts since 24 Jun, 2008, from Europe

Postby mutools; Sun Feb 24, 2013 10:07 am

pljones wrote: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.

Moderators: mutools, muzycian

Return to MUTOOLS