17 Dec
2009
17 Dec
'09
7:41 p.m.
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>.
This would mean that any program that wants to find out which Jack B:B:T or
Frame were on
or if there's been XRuns, wouldnt have to be a JACK client, because its been
abstracted to
the "Master OSC Host".
I think this method would allow better inter program operability, as any
"useful" information
that one program could share, other could read.
This would be most effective, if we also requested that programs followed a
specific naming
convention for features that each program has.
EG:
Save : /<prog_name>/save_state
Load: /<prog_name>/load_state
etc
I'd like to get the communities feelings towards an initiative like this,
feedback/criticism/opinions welcomed!
-Harry Haaren
17 Dec
17 Dec
8:08 p.m.
On Thu, Dec 17, 2009 at 6:41 PM, Harry Van Haaren <harryhaaren(a)gmail.com> wrote:
This would mean that any program that wants to find
out which Jack B:B:T or
Frame were on
or if there's been XRuns, wouldnt have to be a JACK client, because its been
abstracted to
the "Master OSC Host".
i don't many comments on this overall idea, but i do find the notion
that a program wants to know about the internal state of JACK without
being a JACK client, and yet, unlike a simple shell script, is willing
to participate in a 2 way IPC protocol to find out a little .... odd.
also, please keep in mind that the basic semantics of OSC make
query:response interactions really rather tricky to implement in a
robust way. meaning that they will work in 98% of cases, and the other
2% will just either unfathomable and/or unfixable.
18 Dec
18 Dec
4:36 a.m.
Harry,
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.. ;-)
You want service discovery. There is already something out there that
does that, it's called DNS-SD - and it is probably already running on
your system :)
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net
10:53 a.m.
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
12:05 p.m.
On Fri, Dec 18, 2009 at 9:53 AM, nescivi <nescivi(a)gmail.com> wrote:
On Thursday 17 December 2009 18:41:31 Harry Van Haaren
wrote:
Just to add...
I am one of the contributors for the Digital Orchestra Toolkit (hi
Marije!) and I am currently working on a C implementation, so this
might be of interest once it's ready. (It's coming along well, should
be public in January.. but I can make sources public sooner if there's
any interest.)
This solution is somewhat domain-specific, designed for creating
arbitrary mappings between controllers (input devices) and
synthesizers. So, not necessarily an answer to the proposal of this
thread, but perhaps interesting nonetheless.
Basically we found ourselves in a situation where we were making
Max/MSP patches to read input from digital gestural controllers,
usually by reading serial data from Arduinos, and we wished to perform
signal condition and connect these values to inputs to sensors.
We decided to try and design an approach which would _not_ require
maintaining some kind of central database, and that would work across
a network.
So the Digital Orchestra Mapper as we'll call it is basically a set of
standard messages which are communicated on a multicast port. Each
device (either controller or synth) announces itself on this common
bus, and then we made a Max/MSP GUI which can be used to assign
connections between outputs and inputs for known devices. These
connections may have arbitrary operations applied to them. From the
controller's point of view it is simply outputting signals, but they
pass through a "router" which converts these signals into different
messages before actually sending them on the network. There is one
router per connection, and the router is assigned to a specific
destination address. Therefore the multicast bus is only used to set
up connections and describe OSC namespaces, but the signal connections
are peer-to-peer.
Since I am more of a Linux guy, I am interested in using this outside
Max/MSP so I am porting it to C and hoping to provide SWIG bindings to
several languages. The API will look something like:
m = mapper_device_new();
sig = mapper_signal_new(... description ..);
mapper_device_add_signal(m, sig);
and internally in response to requested connections..
r = router_new(address..);
mapper_add_router(m, r);
...
... TODO: haven't finished designing the internal API for
specifying signal conditioning
and repeatedly,
mapper_update_signal(m, sig, value);
Essentially the user program just creates a "device", assigns
"signals", and repeatedly updates them, and then the API takes care of
communicating with the network, finding a unique network name, making
connections, etc.
On the synth-side, I think a callback interface will work for
responding to updated signals, similar to LibLo's message handlers.
Steve
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. 
12:13 p.m.
Greetings,
I have no idea if this is useful:
http://www.niallmoody.com/otherprograms.htm
Check out Mouse2OSC.
Niall's made some other nice software. He graciously updated Mouse2OSC
so I could test it with Common Music/GRACE. I haven't got around to
those tests yet, but I did check it out with AVSynthesis. It worked
perfectly.
Best,
dp
5404
days inactive
5405
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
6 participants
participants (6)
-
Dave Phillips -
Florian Faber -
Harry Van Haaren -
nescivi -
Paul Davis -
Stephen Sinclair