Re: [LAD] OSC: Divide & Conquer, or build a Stronghold?

On Thursday 17 December 2009 18:41:31 Harry Van Haaren wrote:
> Hey all,
>
> I've been keeping myself busy lately, mostly with Python and OSC,
> and I'm using multiple clients/controllers to send messages to a
> sampler with an OSC interface.
>
> From this experience it seems to me a good idea, to have a kind of
> "central"
>
> place where all Audio programs "Announce" thier OSC port & program name &
> version,
> so the linux-audio-desktop can be a little more "coherent" for lack of a
> better word.. ;-)
>
> We could create a kind of "Master OSC Host" which would keep track of
> which clients are running, and which ports they are using. This would be
> easiest
> to do if EACH client, would "register" itself on an agreed port.
>
> So if a client wants to read some information, they could query the
> "Master OSC Host" with a standardised set of questions about the current
> state of QTractor/Ardour/<Any OSC capable program>.

I think the OSC protocol in and of itself is too general for this to make
sense on a global level.

It seems you have already in mind a specific subset of kinds of data to
exchange between programs.

There have already been several approaches for this on specific topics.

Such as the Digital Orchestra Toolkit Mapping tools,
http://idmil.org/software/mappingtools, for mapping data between digital
instruments/controllers, and software synths. There they define how to
announce your controller and how to announce your synth, and then you can
create arbitrary mappings.

Personally, I have worked on an osc-based data-exchange framework for
exchanging data (such as sensor data, but basically any data) between
different collaborators, creating light, sound, video or other media with
their programs, that work on interactive performances or installations.
See http://sensestage.hexagram.ca

In the WONDER software (http://swonder.sourceforge.net) we created a central
control host which transfers and translates OSC data between the different
components of the software. Some of that concept could be generalized for
programs to share any kind of osc messages with each other.

There are also some attempts amongst livecoders to share clocks for playing
together...

To summarise, it could be an interesting project, but be aware that, since the
OSC standard is so open - in principle it doesn't even specify the method of
transport, though most often UDP (in most cases) or TCP/IP (fewer cases) is
used, but there are also implementations that use a serial port transmission
(very few cases) - (getting back to my sentence) and the implementation and
use of it in various programs varies a lot, some are only taking incoming
transmissions and don't send messages, if based on UDP and TCP/IP, some send
from a fixed port, some don't, some can listen to multicast messages, others
don't. You have to consider whether you want to require them to adhere to a
specific namespace, or whether you want to work with their existing
namespaces.

That being said... a general purpose osc-mapping program could be really
useful... something you can put between two programs (one sending, one
receiving), that translates from one namespace to another, and possibly does
the required translations.

sincerely,
Marije
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Dec 18 20:15:03 2009