Audio and Midi/Event sharing between exported VST/i

Hengy · 4 Jun 2005

yes, i just had a similar thought. some kind of communication module that'd let compiled vsts exchange data, - could have some really nice uses, just not sure how feasible it'd be

ik_ik_ik · 4 Jun 2005

Interesting idea!

Certainly should be feasible to implement something along the lines of subliminal's senderella. There's got to be the potential for some nice flexible way way to pass different types of data or signals between exported VSTs using a simple send/receive addressing system.

Hmmm, could be some really interesting things possible with that!

Cheers,

Inigo

lalo · 5 Jun 2005

yeah 🙂

glad you like the idea guys 🙂 let's expand it and give more possible 'practical' uses to 'tease' jorge and malc for the 'not-so-near' future 😉

lalo

ik_ik_ik · 5 Jun 2005

How about something IP based so there's then also the possibility to send/receive "packets" (MIDI, signals, data structures, etc.) between nodes on a network (internet)?

There's the potential to somehow make use of a host/client scenario too where data structures could be shared for example - one node acting as host and one or more behaving as clients and accessing data structures on the host node.

A "local" connection e.g. within a host on the same machine would simply be a special "local" mode or loopback connection.

Inigo

jorge · 5 Jun 2005

ik_ik_ik wrote: How about something IP based so there's then also the possibility to send/receive "packets" (MIDI, signals, data structures, etc.) between nodes on a network (internet)?

There's the potential to somehow make use of a host/client scenario too where data structures could be shared for example - one node acting as host and one or more behaving as clients and accessing data structures on the host node.

A "local" connection e.g. within a host on the same machine would simply be a special "local" mode or loopback connection.

Inigo

That's what we were planning. We already had network components working with IP numbers on the old SM version 0.8 before we started again from scratch. I think at some stage we'll improve on the old ones and include them with the new synthmaker.

ik_ik_ik · 5 Jun 2005

Great 🙂 I remember using the old SM years ago but I hadn't remembered the network stuff. It'd be interesting to see what the old components were.

lalo · 5 Jun 2005

ik_ik_ik wrote: How about something IP based so there's then also the possibility to send/receive "packets" (MIDI, signals, data structures, etc.) between nodes on a network (internet)?

There's the potential to somehow make use of a host/client scenario too where data structures could be shared for example - one node acting as host and one or more behaving as clients and accessing data structures on the host node.

A "local" connection e.g. within a host on the same machine would simply be a special "local" mode or loopback connection.

Inigo

yes..the only problem could be from eventual audio glithes hiccups when the tcp-ip is sending/receiving... but i've to say that this is only a suspect...infact pd is based on a kind of mechanism like this..and didn't glitch..if it does it is because portaudio isn't yet ready for extreme low latency performance

let's see 🙂

but it can open a huge potential...

my main interest would be share audio-buffers and midi-buffers between different plugs 🙂

lalo

Nu Audio Science · 5 Jun 2005

Lalo you been reading the mixer thread at KVR Tracktion ? I was going to ask for this exact thing today 🙂

lalo · 5 Jun 2005

Nu Audio Science wrote: Lalo you been reading the mixer thread at KVR Tracktion ? I was going to ask for this exact thing today 🙂

nope ..i didn't read that..i'll go now 🙂

lalo

NothanUmber · 5 Jun 2005

Nice idea! Perhaps one could use the open sound control protocol ( http://www.cnmat.berkeley.edu/OpenSoundControl/ ). From what one can see here http://www.cnmat.berkeley.edu/OpenSound ... -spec.html there should be enough possibilities to serialize any kind of SM specific information so SM created modules could communicate with each other by using all available features and with non SM ones with the "least common base". (There are several interesting applications available that already support that standard, just look at the site linked above) and if the trend to replace midi with osc in the medium term future should continue then SM would already be prepared 🙂

Greetings, NothanUmber

skOre · 5 Jun 2005

ALERT ALERT

SUPER PRESSING ISSUE!!!

DEVS: CONSIDER TO DO SOMETHING INCLUDING THESE OPENSOUNDCONTROLS IN THE FUTURE

I really think this is a road worth taking!

Tom7777 · 5 Jun 2005

This is sort of like my radio signal like bus send and recieve idea for non wire required schematics but would go out of the plugin into another one. Since i don't make music over a network or anything im more interested in being able to have a feature like this to chain effects together when running or something as the ip idea wouldn't really help me at all.

lalo · 6 Jun 2005

skOre wrote: DEVS: CONSIDER TO DO SOMETHING INCLUDING THESE OPENSOUNDCONTROLS IN THE FUTURE

I really think this is a road worth taking!

me too..me thinks OSC will have a great future mostly in the live-media scene....think about the flash osc server to interect in both ways OSC<>PD or OSC<>Max/MSP...even if is a different thing from the idea i suggested in the thread..should the OSC be a different topic?

lalo

NothanUmber · 6 Jun 2005

lalo wrote: be able to share audio/midi/whatever (like arrays/samples/etc..) data between different exported VST/i... | .even if is a different thing from the idea i suggested in the thread

Well you wouldn't have to "see" that OSC is used. For the user the mechanism could e.g. look like that: You have a new icon "replicate" on the bottom of each component (at least where it makes sense...). Now this component is automatically syncronized with all other components with the same name (be it that this component is in the same schematic or in an other application on another computer - in this case OCS would be used but that's completely transparent to you). So one could replicate primitive data (floats, strings, ints), all kinds of buffers (sample and hold, upcoming new sample buffers...) or even gui elements for remote controlling purposes. And if one already has the underlaying OSC support then adding some components for generic communication with non-SM-OSC-supporters shouldn't be a big deal (perhaps that could also be encapsulated in a user friendly manner, haven't done an investigation which features could be regarded as a reasonable "biggest common base" so one would have to have a look there...)

Greetings, NothanUmber

P.S.: A midi send/receive shouldn't be a big problem: One would only need e.g. a replicated midi "delay" (with a delaytime of 0 or 1 samples) for this. A similar "bus delay" would also be nice so that you could transfer whole busses as lalo suggested