28 Feb
2005
28 Feb
'05
5:09 p.m.
My impression is that more and more applications are moving to
OSC for inter-process communication.
Question 1: Are most audio/midi applications converging on OSC?
Are there any moving away from it? Or are there other strong
contenters in this area?
AFAIK all linux audio/midi applications use an arbitrary UDP port
number, and rely on manual configuration of this for the server and
all clients.
With OSC popularity increasing this will pose a growing problem
for end users who have to configure the ports, and for developers
of client programs that want to interact with multiple servers.
The answer to this issue is service discovery, which was recently
discussed on the OSC_dev list [1]. That thread leads to a product
called howl [2], which is an open implementation of mDNS/redezvous/
zeroconf (take your pick). It provides 3 daemons (of which 2 should
be run) and some libraries.
Using this implementation all applications would (ideally) register
or discover services using the howl libraries. Apart from this, the
programs would communicate via OSC.
To me this seems like a lot of overhead for a relatively small gain.
OTOH it seems like a very flexible and future-proof solution.
An alternate way I've been considering is an OSC-based service
discovery daemon. It would accept OSC messages to register and discover
services. The advantage of this is that it only uses 1 small daemon,
but more importantly that applications do not need to use any additional
libraries besides the OSC one (<insert liblo plug here> :). So far I
can see 6 input messages for such a daemon, with 4 response messages.
The disadvantage is that the daemon would still need an arbitrary port
number, and all applications would need to know it (at least for a while).
For intra-host discover the daemon could still interact with howl or
something like it if that is needed. But if this approach is successfull
we could request one dedicated port from IANA.
Question 2: Are there other better alternatives?
Question 3: Which alternative is better or do you prefer? (mDNS/OSC-daemon)
The only thing I haven't mentioned yet is LASH. Well, in my opinion it
is the prime example of an application that needs to interact with all
other linux audio/midi appications. As such, I think it could gain most
from a service discovery scheme. And there has been talk about using
OSC for it [3].
Comments/suggestions/questions? Blast away! Phasers on stun please!
And Steve: appologies for stepping on your turf.
Best regards,
--
Martin
[1] http://www.create.ucsb.edu/pipermail/osc_dev/2004-December/000841.html
[2] http://www.porchdogsoft.com/products/howl/
[3] http://music.columbia.edu/pipermail/linux-audio-dev/2004-August/009288.html
[4] http://www.cnmat.berkeley.edu/OpenSoundControl/
---------------------------------------------------------------------------
30 years from now GNU/Linux will be as redundant a term as UNIX/MERT is
today. - Martin Habets
---------------------------------------------------------------------------
28 Feb
28 Feb
5:35 p.m.
On Mon, Feb 28, 2005 at 09:09:49 +0000, Martin Habets wrote:
My impression is that more and more applications are
moving to
OSC for inter-process communication.
Question 1: Are most audio/midi applications converging on OSC?
Are there any moving away from it? Or are there other strong
contenters in this area?
AFAIK all linux audio/midi applications use an arbitrary UDP port
number, and rely on manual configuration of this for the server and
all clients.
With OSC popularity increasing this will pose a growing problem
for end users who have to configure the ports, and for developers
of client programs that want to interact with multiple servers.
The answer to this issue is service discovery, which was recently
discussed on the OSC_dev list [1]. That thread leads to a product
called howl [2], which is an open implementation of mDNS/redezvous/
zeroconf (take your pick). It provides 3 daemons (of which 2 should
be run) and some libraries.
Using this implementation all applications would (ideally) register
or discover services using the howl libraries. Apart from this, the
programs would communicate via OSC.
There is a proposed specification for discovery of OSC services that was
presented at hte OSC conference, I intend to support it in liblo at some
point in the future.
To me this seems like a lot of overhead for a
relatively small gain.
OTOH it seems like a very flexible and future-proof solution.
IIUC Gnome allready requires libhowl and mDNSResponder, so its not as
burdonsome as it could be.
An alternate way I've been considering is an
OSC-based service
discovery daemon. It would accept OSC messages to register and discover
services. The advantage of this is that it only uses 1 small daemon,
but more importantly that applications do not need to use any additional
libraries besides the OSC one (<insert liblo plug here> :). So far I
can see 6 input messages for such a daemon, with 4 response messages.
The disadvantage is that the daemon would still need an arbitrary port
number, and all applications would need to know it (at least for a while).
For intra-host discover the daemon could still interact with howl or
something like it if that is needed. But if this approach is successfull
we could request one dedicated port from IANA.
That is not as appealing to me, as the service will only be discoverable
on the local machine, whereas MDNS works on local networks.
I did consider this solution when I started implementing liblo, but
rejected it as too OSC specific.
Dave Robillard (sp?) has an another OSC-based idea that covers some of hte
same ground, but I'l leave him to describe it.
- Steve
1 Mar
1 Mar
10:15 a.m.
On Mon, Feb 28, 2005 at 09:35:34PM +0000, Steve Harris wrote:
Not sure what you mean by the gnome connection. I would recommend against
running gnome (or KDE) when doing audio work, but that's just my angle on
it.
That's just a matter of broadcasting. If the daemon listens on port 1234
it will respond to any client to that broadcasts to that port.
There is a proposed specification for discovery of OSC
services that was
presented at hte OSC conference, I intend to support it in liblo at some
point in the future.
Do you have a link to this spec? Was it the one based on zeroconf?
To me this
seems like a lot of overhead for a relatively small gain.
OTOH it seems like a very flexible and future-proof solution.
IIUC Gnome allready requires libhowl and mDNSResponder, so its not as
burdonsome as it could be. An alternate
way I've been considering is an OSC-based service
discovery daemon. It would accept OSC messages to register and discover
services. The advantage of this is that it only uses 1 small daemon,
but more importantly that applications do not need to use any additional
libraries besides the OSC one (<insert liblo plug here> :). So far I
can see 6 input messages for such a daemon, with 4 response messages.
The disadvantage is that the daemon would still need an arbitrary port
number, and all applications would need to know it (at least for a while).
For intra-host discover the daemon could still interact with howl or
something like it if that is needed. But if this approach is successfull
we could request one dedicated port from IANA.
That is not as appealing to me, as the service will only be discoverable
on the local machine, whereas MDNS works on local networks. I did consider this solution when I started
implementing liblo, but
rejected it as too OSC specific.
I agree it is OSC specific, but in my opinion that is big adavantage ad no
other protocols/daemons/libraries are needed.
--
Martin
4:48 p.m.
On Tue, Mar 01, 2005 at 02:15:46 +0000, Martin Habets wrote:
Not sure what you mean by the gnome connection. I would recommend against
running gnome (or KDE) when doing audio work, but that's just my angle on
it.
Some of the current freedesktop stuff requires an MDNS server, it was just
an example that its becming widly used on linux. FC3 runs an MDNS demon at
boot time for example.
Using an MDNS server means that you dont have to worry about implicitly or
explicitly starting an OSC discovery demon, or anything like that.
- Steve
On Mon, Feb 28, 2005 at 09:35:34PM +0000, Steve Harris
wrote:
Yes, and yes. http://www.opensoundcontrol.org/media/Rendezvous-OSC.pdf
spec is too strong a word. I think theres a working group looking at
it, but the binding of an OSC service into zeroconf is pretty aparent in
any case.
There is a proposed specification for discovery
of OSC services that was
presented at hte OSC conference, I intend to support it in liblo at some
point in the future.
Do you have a link to this spec? Was it the one based on zeroconf? To me this seems like a lot of overhead for a
relatively small gain.
OTOH it seems like a very flexible and future-proof solution.
IIUC Gnome allready requires libhowl and mDNSResponder, so its not as
burdonsome as it could be.
2 Mar
2 Mar
1:18 p.m.
On Tue, Mar 01, 2005 at 08:48:13PM +0000, Steve Harris wrote:
Not sure what you mean by the gnome connection. I would recommend against
running gnome (or KDE) when doing audio work, but that's just my angle on
it.
Some of the current freedesktop stuff requires an MDNS server, it was just
an example that its becming widly used on linux. FC3 runs an MDNS demon at
boot time for example.
Using an MDNS server means that you dont have to worry about implicitly or
explicitly starting an OSC discovery demon, or anything like that.
Thanks for explaining. Your point is that regular desktop machines will be
using MDNS already, or will soon.
--
Martin
On Tue, Mar 01, 2005 at 02:15:46 +0000, Martin Habets
wrote:
Yes, I did see that one. Am a bit confused by their use of _osc._udp versus
osc.upd in a URL. They are different entities, but they look soo similar.
Can you explain how they relate, please?
On Mon, Feb 28, 2005 at 09:35:34PM +0000, Steve
Harris wrote:
Yes, and yes. http://www.opensoundcontrol.org/media/Rendezvous-OSC.pdf
spec is too strong a word. I think theres a working group looking at
it, but the binding of an OSC service into zeroconf is pretty aparent in
any case. There is a proposed specification for discovery
of OSC services that was
presented at hte OSC conference, I intend to support it in liblo at some
point in the future.
Do you have a link to this spec? Was it the one based on zeroconf? To me this
seems like a lot of overhead for a relatively small gain.
OTOH it seems like a very flexible and future-proof solution.
IIUC Gnome allready requires libhowl and mDNSResponder, so its not as
burdonsome as it could be.
1:31 p.m.
On Wed, Mar 02, 2005 at 05:18:24 +0000, Martin Habets wrote:
Some of the current freedesktop stuff requires an MDNS server, it was just
an example that its becming widly used on linux. FC3 runs an MDNS demon at
boot time for example.
Using an MDNS server means that you dont have to worry about implicitly or
explicitly starting an OSC discovery demon, or anything like that.
Thanks for explaining. Your point is that regular desktop machines will be
using MDNS already, or will soon.
OR should be :) yes. You cant force people to install more software, but
the more reasons they have to install a particular service, the more likly
they are to.
- Steve
On Tue, Mar 01, 2005 at 08:48:13PM +0000, Steve Harris
wrote:
_ is the MDNS prefix, it allows you to resolve resources by
charateristics, rather than names.
The . in the URI protocol is unrelateed, thye just happen to use the same
character.
On Tue, Mar 01, 2005 at 02:15:46 +0000, Martin
Habets wrote:
Yes, I did see that one. Am a bit confused by their use of _osc._udp versus
osc.upd in a URL. They are different entities, but they look soo similar.
Can you explain how they relate, please? On Mon, Feb 28, 2005 at 09:35:34PM +0000, Steve
Harris wrote:
Yes, and yes. http://www.opensoundcontrol.org/media/Rendezvous-OSC.pdf
spec is too strong a word. I think theres a working group looking at
it, but the binding of an OSC service into zeroconf is pretty aparent in
any case. There is a proposed specification for discovery
of OSC services that was
presented at hte OSC conference, I intend to support it in liblo at some
point in the future.
Do you have a link to this spec? Was it the one based on zeroconf? > To me
this seems like a lot of overhead for a relatively small gain.
> OTOH it seems like a very flexible and future-proof solution.
IIUC Gnome allready requires libhowl and mDNSResponder, so its not as
burdonsome as it could be.
Not sure what you mean by the gnome connection. I would recommend against
running gnome (or KDE) when doing audio work, but that's just my angle on
it. 
28 Feb
28 Feb
10:34 p.m.
On Mon, 2005-28-02 at 21:09 +0000, Martin Habets wrote:
My impression is that more and more applications are
moving to
OSC for inter-process communication.
Question 1: Are most audio/midi applications converging on OSC?
Are there any moving away from it? Or are there other strong
contenters in this area?
AFAIK all linux audio/midi applications use an arbitrary UDP port
number, and rely on manual configuration of this for the server and
all clients.
With OSC popularity increasing this will pose a growing problem
for end users who have to configure the ports, and for developers
of client programs that want to interact with multiple servers.
This is definitely a huge problem. I'm working on numerous OSC
projects, and the connection establishing code is by far the most
annoying thing to do. I eventually came to the conclusion that clients
shouldn't have to deal with all that nuisance.
We have these nice patch-bay-like systems with Jack and Alsa that are
touted as the best thing since sliced break around here, but nothing
similar for OSC. The benefits are the same, except the downsides
of /not/ having such a system are worse (ie it's much more a PITA for
developers to figure out their OSC connections than just send along some
MIDI channel number or device file).
Consider a simple OSC sequencer that just records it's input and then
sends it out later - where does this input come from? It has no idea.
Where does it go? Who knows. Must every little app have hundreds of
lines of service discovery just to integrate with the system? Whether
this is needed or not isn't up for debate, just how to accomplish it
is. :)
So basically my goals are to make OSC using liblo as nice as audio using
jack, as far as "ports" and "connections" (in jack-ese) go, with as
little burden on clients as possible, and allowing user patching, etc.
The answer to this issue is service discovery, which
was recently
discussed on the OSC_dev list [1]. That thread leads to a product
called howl [2], which is an open implementation of mDNS/redezvous/
zeroconf (take your pick). It provides 3 daemons (of which 2 should
be run) and some libraries.
Using this implementation all applications would (ideally) register
or discover services using the howl libraries. Apart from this, the
programs would communicate via OSC.
To me this seems like a lot of overhead for a relatively small gain.
OTOH it seems like a very flexible and future-proof solution.
It is overhead at connection establishment time - irrelevant to actual
performance. Rendezvous is the way to do these things, no question. It
will only get even more popular over time.
An alternate way I've been considering is an
OSC-based service
discovery daemon. It would accept OSC messages to register and discover
services. The advantage of this is that it only uses 1 small daemon,
but more importantly that applications do not need to use any additional
libraries besides the OSC one (<insert liblo plug here> :). So far I
can see 6 input messages for such a daemon, with 4 response messages.
The disadvantage is that the daemon would still need an arbitrary port
number, and all applications would need to know it (at least for a while).
For intra-host discover the daemon could still interact with howl or
something like it if that is needed. But if this approach is successfull
we could request one dedicated port from IANA.
Question 2: Are there other better alternatives?
Question 3: Which alternative is better or do you prefer? (mDNS/OSC-daemon)
Actually, the solution myself and Steve Harris came to (on #lad) is a
combination of both. In order to accomplish user "patching" and relieve
the burden on clients, an OSC daemon will be required to maintain
information about what is patched to where, etc. However, rendezvous is
needed so things can discover each other (ie clients can discover the
patching daemon, and vice versa).
The "patching server" (called that from hereon for lack of a better
name) has simple commands like /set_destination
<url>, /remove_destination <url>, etc. You can imagine a GUI
jack-patch-bay like client for it.
From the client side, this will all be abstracted in
liblo behind a
simple jack-like API (where the client code doesn't know or care
where
it's messages go). I think this is best, and in fitting with liblo's
general philosophy.
Implementation wise, the scheme goes something like this:
- client broadcasts it's existance via rendezvous
- patching server replies to client, so now both are aware of each
other's existance
- (any) client can now set destinations for client. in other words,
osc-patch-bay functionality now works
When a destination is added/removed, the patching server will notify the
client (via OSC), and the client will update it's list of destinations
appropriately (this will all be abstracted by liblo's API though).
And that's it. No more manual port specifying nonsense, and clients
connection code has been reduced to probably a single liblo function
call (and a special lo_address token that means "send to all my patch
bay destinations")
The nice thing about this system (thanks largely to Steve) is that it
will also work with non-liblo clients, and so could become an OSC
'standard' if it catches on. At the very least it will promote OSC to
the same level of modularity that MIDI and Jack have, as far as linux
audio systems are concerned. Plus, since everything is network
transparent, programs run on other machines on the network will
automatically register their (er) "ports", so could magically appear in
other machine's patch bays - very cool.
I'm planning on writing this thing really soon, unless anyone has a
better idea. The actual server will be almost trivial, just the service
discovery and liblo abstraction will be slightly more annoying to
implement.
Cheers,
-DR-
1 Mar
1 Mar
6:27 a.m.
Hallo,
Dave Robillard hat gesagt: // Dave Robillard wrote:
The nice thing about this system (thanks largely to
Steve) is that it
will also work with non-liblo clients, and so could become an OSC
'standard' if it catches on. At the very least it will promote OSC to
the same level of modularity that MIDI and Jack have, as far as linux
audio systems are concerned. Plus, since everything is network
transparent, programs run on other machines on the network will
automatically register their (er) "ports", so could magically appear in
other machine's patch bays - very cool.
I wonder how to handle broadcast OSC messages in that context? They
are an important possibility in OSC when playing together with lots of
machine: One is sending to 192.168.0.255:xxxx and everyone receives
data there.
Ciao
--
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
10:30 a.m.
On Tue, Mar 01, 2005 at 11:26:23 +0100, Frank Barknecht wrote:
Hallo,
Dave Robillard hat gesagt: // Dave Robillard wrote:
I played with that in liblo, its not very hard, but it may break as few
client assumtions, so you have to be aware of it in OSC receivers.
- Steve
The nice thing about this system (thanks largely
to Steve) is that it
will also work with non-liblo clients, and so could become an OSC
'standard' if it catches on. At the very least it will promote OSC to
the same level of modularity that MIDI and Jack have, as far as linux
audio systems are concerned. Plus, since everything is network
transparent, programs run on other machines on the network will
automatically register their (er) "ports", so could magically appear in
other machine's patch bays - very cool.
I wonder how to handle broadcast OSC messages in that context? They
are an important possibility in OSC when playing together with lots of
machine: One is sending to 192.168.0.255:xxxx and everyone receives
data there.
7:39 p.m.
On Tue, 2005-01-03 at 11:26 +0100, Frank Barknecht wrote:
Hallo,
Dave Robillard hat gesagt: // Dave Robillard wrote:
Nothing at all forces a client to use the thing - that's very important!
Whatever works now will always work, this stuff is 100% optional in
every way - liblo clients can, of course, still send and receive to
whatever address they please.
But anyway, the patch bay app I envision will allow setting arbitrary
addresses without needing an application to claim them anyway. Picture
an "add port" button in osc-patch-bay that allows you to type in an
arbitrary address to define a 'destination' - normal, broadcast,
whatever.
-DR-
The nice thing about this system (thanks largely
to Steve) is that it
will also work with non-liblo clients, and so could become an OSC
'standard' if it catches on. At the very least it will promote OSC to
the same level of modularity that MIDI and Jack have, as far as linux
audio systems are concerned. Plus, since everything is network
transparent, programs run on other machines on the network will
automatically register their (er) "ports", so could magically appear in
other machine's patch bays - very cool.
I wonder how to handle broadcast OSC messages in that context? They
are an important possibility in OSC when playing together with lots of
machine: One is sending to 192.168.0.255:xxxx and everyone receives
data there.
Ciao 
9:20 a.m.
On Tue, Mar 01, 2005 at 01:27:38PM -0500, Dave Robillard wrote:
When a destination is added/removed, the patching
server will notify the
client (via OSC), and the client will update it's list of destinations
appropriately (this will all be abstracted by liblo's API though).
How would you handle SC3's way of doing things ?
When you create a new OSCResponder object in sclang, this does not
create a new port - it just adds a new 'accepted source' for messages
coming in at the one and unique sclang port (57120). OSCResponders are
created by specifying the source, not a local port.
Given this, the JACK / MIDI patchbay is not the correct model. For both
JACK and the ALSA sequencer, connecting multiple outputs to the same
input just adds / merges the signals coming from those outputs. This is
not the case for UDP: messages coming in from different sources remain
quite separate, and a client in effect never needs more than one input
port.
--
FA
10:59 a.m.
On Tue, Mar 01, 2005 at 01:27:38PM -0500, Dave Robillard wrote:
Yes, rendezvous is the general purpose answer to the problem. It will get
more used over time, and it is exactly that which may pose a problem.
But what happens when someone turns on the rendezvous-enabled washing
machine during your recording session? Or consider the M$ Windows machine
that publishes, retracts and queries like crazy. You'd have to create
a subnet for your audio studio to artificially limit the scope of
rendezvous.
At the moment rendezvous is a very open/liberal system. I'm all for that
off course, but with growing popularity I think it will gain some security
features. That could be bad news for folks who just want to get together
and jam.
I was thinking along the same lines here. But the point is that if you
use rendezvous only for daemon discovery, then the overhead costs more than
the benefit you gain (remember every application would need it).
I see the usage scenario as follows:
- client does a broadcasts to the oscsd port of a "/ping" message.
- oscsd acknowledges it.
- client request a service using a "/request service_name" message.
- oscsd responds with either the URL of the server, or responds with
a negative acknowledge if the service has not registered.
For servers (i.e applications providing services) the first 2 steps
are the same. After that is publishes it's services using
/register service_name service_URL
messages.
An application can provide multiple services, and register to multiple
services as well. It can use one port or multiple, use one OSC address
or many.
So basically my goals are to make OSC using liblo as
nice as audio using
jack, as far as "ports" and "connections" (in jack-ese) go, with as
little burden on clients as possible, and allowing user patching, etc.
It seems our goals are the same, although user patching should not be
needed IMO.
The answer to
this issue is service discovery, which was recently
discussed on the OSC_dev list [1]. That thread leads to a product
called howl [2], which is an open implementation of mDNS/redezvous/
zeroconf (take your pick). It provides 3 daemons (of which 2 should
be run) and some libraries.
Using this implementation all applications would (ideally) register
or discover services using the howl libraries. Apart from this, the
programs would communicate via OSC.
To me this seems like a lot of overhead for a relatively small gain.
OTOH it seems like a very flexible and future-proof solution.
It is overhead at connection establishment time - irrelevant to actual
performance. Rendezvous is the way to do these things, no question. It
will only get even more popular over time. An alternate
way I've been considering is an OSC-based service
discovery daemon. It would accept OSC messages to register and discover
services. The advantage of this is that it only uses 1 small daemon,
but more importantly that applications do not need to use any additional
libraries besides the OSC one (<insert liblo plug here> :). So far I
can see 6 input messages for such a daemon, with 4 response messages.
The disadvantage is that the daemon would still need an arbitrary port
number, and all applications would need to know it (at least for a while).
For intra-host discover the daemon could still interact with howl or
something like it if that is needed. But if this approach is successfull
we could request one dedicated port from IANA.
Question 2: Are there other better alternatives?
Question 3: Which alternative is better or do you prefer? (mDNS/OSC-daemon)
Actually, the solution myself and Steve Harris came to (on #lad) is a
combination of both. In order to accomplish user "patching" and relieve
the burden on clients, an OSC daemon will be required to maintain
information about what is patched to where, etc. However, rendezvous is
needed so things can discover each other (ie clients can discover the
patching daemon, and vice versa). The "patching server" (called that from
hereon for lack of a better
name) has simple commands like /set_destination
<url>, /remove_destination <url>, etc. You can imagine a GUI
jack-patch-bay like client for it.
I don't like the idea of yet-another-patch-bay for this. It just pushes
the problem out to the end users, most of which do not know (or want to)
what to connect where. Besides, the application developers know much better
which services their application want.
For example, the sooperlooper GUI is only wants to find sooperlooper
engines. It is not interested in whatever jack.osc offers.
Note I don't object to having a patch-bay for this, but I think it should
not be the main way to make connections. Rather just for viewing and maybe
adjusting later.
From the client
side, this will all be abstracted in liblo behind a
simple jack-like API (where the
client code doesn't know or care where
it's messages go). I think this is best, and in fitting with liblo's
general philosophy.
Implementation wise, the scheme goes something like this:
- client broadcasts it's existance via rendezvous
- patching server replies to client, so now both are aware of each
other's existance
- (any) client can now set destinations for client. in other words,
osc-patch-bay functionality now works When a destination is added/removed, the patching
server will notify the
client (via OSC), and the client will update it's list of destinations
appropriately (this will all be abstracted by liblo's API though).
And that's it. No more manual port specifying nonsense, and clients
connection code has been reduced to probably a single liblo function
call (and a special lo_address token that means "send to all my patch
bay destinations")
The nice thing about this system (thanks largely to Steve) is that it
will also work with non-liblo clients, and so could become an OSC
'standard' if it catches on. At the very least it will promote OSC to
the same level of modularity that MIDI and Jack have, as far as linux
audio systems are concerned. Plus, since everything is network
transparent, programs run on other machines on the network will
automatically register their (er) "ports", so could magically appear in
other machine's patch bays - very cool.
Yep, same here.
I'm planning on writing this thing really soon,
unless anyone has a
better idea. The actual server will be almost trivial, just the service
discovery and liblo abstraction will be slightly more annoying to
implement.
I'd recommend writing down the full spec first, and send that out for
review. That's what I'll be doing :)
--
Martin
4:32 p.m.
On Tue, Mar 01, 2005 at 02:58:08 +0000, Martin Habets wrote:
Yes, rendezvous is the general purpose answer to the problem. It will get
more used over time, and it is exactly that which may pose a problem.
But what happens when someone turns on the rendezvous-enabled washing
machine during your recording session? Or consider the M$ Windows machine
that publishes, retracts and queries like crazy. You'd have to create
a subnet for your audio studio to artificially limit the scope of
rendezvous.
Not at all, theres a protocol prefix for OSC, which washing machines are
unlikly to speak :) so washing machines will be ignored by OSC things.
Also, there is a field that you can use to descriminate between OSC
services that use particular schema.
I was thinking along the same lines here. But the point is that if you
use rendezvous only for daemon discovery, then the overhead costs more than
the benefit you gain (remember every application would need it).
No, the benefit is that the application can send to one or more
destinations without the author explicitly coding some discovery stuff,
and be changable dynamically. Thats not possible without
1) some discovery
2) a service (in the looses sense) that tells you where to send things
I thought so to, but Dave has some counter examples.
On Tue, Mar 01, 2005 at 01:27:38PM -0500, Dave
Robillard wrote:
I dont think thier actually the same, they just overlap to some extent.
Both of these things are needed, but one is allready defined (zeroconf+the
OSC specific stuff), and one needs some thinking.
Dave is trying to solve exactly the case where you *do* want to manually
connect applications. He has examples.
So basically my goals are to make OSC using liblo
as nice as audio using
jack, as far as "ports" and "connections" (in jack-ese) go, with as
little burden on clients as possible, and allowing user patching, etc.
It seems our goals are the same, although user patching should not be
needed IMO. To me this seems like a lot of overhead for a
relatively small gain.
OTOH it seems like a very flexible and future-proof solution.
It is overhead at connection establishment time - irrelevant to actual
performance. Rendezvous is the way to do these things, no question. It
will only get even more popular over time. At the moment rendezvous is a very open/liberal
system. I'm all for that
off course, but with growing popularity I think it will gain some security
features. That could be bad news for folks who just want to get together
and jam.
I really dont think so. It doesnt make sense to add seurity to redevous
itsself, if you want secure, discoverable services then use IPSec. Its a
different layer.
An alternate way I've been considering is an
OSC-based service
discovery daemon. It would accept OSC messages to register and discover
services. The advantage of this is that it only uses 1 small daemon,
but more importantly that applications do not need to use any additional
libraries besides the OSC one (<insert liblo plug here> :). So far I
can see 6 input messages for such a daemon, with 4 response messages.
The disadvantage is that the daemon would still need an arbitrary port
number, and all applications would need to know it (at least for a while).
For intra-host discover the daemon could still interact with howl or
something like it if that is needed. But if this approach is successfull
we could request one dedicated port from IANA.
Question 2: Are there other better alternatives?
Question 3: Which alternative is better or do you prefer? (mDNS/OSC-daemon)
Actually, the solution myself and Steve Harris came to (on #lad) is a
combination of both. In order to accomplish user "patching" and relieve
the burden on clients, an OSC daemon will be required to maintain
information about what is patched to where, etc. However, rendezvous is
needed so things can discover each other (ie clients can discover the
patching daemon, and vice versa). The
"patching server" (called that from hereon for lack of a better
name) has simple commands like /set_destination
<url>, /remove_destination <url>, etc. You can imagine a GUI
jack-patch-bay like client for it.
I don't like the idea of yet-another-patch-bay for this. It just pushes
the problem out to the end users, most of which do not know (or want to)
what to connect where. Besides, the application developers know much better
which services their application want. For example, the sooperlooper GUI is only wants to
find sooperlooper
engines. It is not interested in whatever jack.osc offers.
Right, but thats not true in all cases.
For the record I will not add support (or accept patches) to liblo for any
discovery mechanism that does not use an existing standard. I know just
enough about the area to know that there are subleties of the problem that
I dont get, and there are plenty of known-good standards in this area, of
which redevouz/zeroconf is probably the most appropriate.
- Steve
7:54 p.m.
On Tue, 2005-01-03 at 14:58 +0000, Martin Habets wrote:
Just as in jack, applications are free to make 'connections' as they
please - or even ignore the extistance of the service entirely.
Noone argues the benefit of jack's connection system, the benefits are
the same here. If you don't need it, don't use it. I'm working on more
interesting things than plain old "oh look, I found my one client, now
we can talk to each other" stuff. Something more flexible is needed,
just like what we have for audio and midi.
Feel free. I would suggest dropping your dislike of Rendezvous though.
The service discovery problem needs to be solved, and it can't be done
in OSC alone - OSC needs addresses to do anything at all. Rendezvous is
the thing that solves this problem. No arguments. :)
Personally though, I don't much care for publishing RFCs and debating on
mailing lists for 6 months - I need it to work, now. The general
outline of the system can't change that much - it can be modified to
suit a later agreed-upon standard easily enough. Change an OSC path
here and there, no big deal.
-DR-
On Tue, Mar 01, 2005 at 01:27:38PM -0500, Dave
Robillard wrote:
See previous sequencer example. It is definitely needed in some cases,
sequencing being the obvious one. Technically the discovery stuff is
seperate from the patching server thing, they're just bundled together
in my mind as solving the same problem (namely OSC connections being a
PITA)
So basically my goals are to make OSC using liblo
as nice as audio using
jack, as far as "ports" and "connections" (in jack-ese) go, with as
little burden on clients as possible, and allowing user patching, etc.
It seems our goals are the same, although user patching should not be
needed IMO. The
"patching server" (called that from hereon for lack of a better
name) has simple commands like /set_destination
<url>, /remove_destination <url>, etc. You can imagine a GUI
jack-patch-bay like client for it.
I don't like the idea of yet-another-patch-bay for this. It just pushes
the problem out to the end users, most of which do not know (or want to)
what to connect where. Besides, the application developers know much better
which services their application want.
For example, the sooperlooper GUI is only wants to find sooperlooper
engines. It is not interested in whatever jack.osc offers.
Note I don't object to having a patch-bay for this, but I think it should
not be the main way to make connections. Rather just for viewing and maybe
adjusting later. I'm
planning on writing this thing really soon, unless anyone has a
better idea. The actual server will be almost trivial, just the service
discovery and liblo abstraction will be slightly more annoying to
implement.
I'd recommend writing down the full spec first, and send that out for
review. That's what I'll be doing :)
2 Mar
2 Mar
1:27 p.m.
On Wed, Mar 02, 2005 at 10:47:31 -0500, Dave Robillard wrote:
Personally though, I don't much care for
publishing RFCs and debating on
mailing lists for 6 months - I need it to work, now. The general
outline of the system can't change that much - it can be modified to
suit a later agreed-upon standard easily enough. Change an OSC path
here and there, no big deal.
You cant publish an IETF RFC until you have 2 independent implementations ;)
- Steve
3 Mar
3 Mar
9:38 a.m.
On Wed, Mar 02, 2005 at 10:47:31AM -0500, Dave Robillard wrote:
Just as in jack, applications are free to make 'connections' as they
please - or even ignore the extistance of the service entirely.
Noone argues the benefit of jack's connection system, the benefits are
the same here. If you don't need it, don't use it. I'm working on more
interesting things than plain old "oh look, I found my one client, now
we can talk to each other" stuff. Something more flexible is needed,
just like what we have for audio and midi.
The jack and alsa connection systems aren't called patchbays for nothing:
they emulate the real/physical world. In that world there are no patchbays
for control streams: control information is either non-existing, or it
uses the existing audio/MIDI connections, or it has a proporietary connection
alongside the audio/MIDI cabling.
The takeaway from this is that the control cabling follows the other
cabling.
Back in computer-land this means that if an audio or MIDI connection is
made between X and Y, an OSC connection COULD follow automatically.
I say could here because the OSC connection is only usefull if both sides
can understand each other, i.e. they share an OSC namespace (message
specifications).
How would your sequencer example do in such an environment?
Feel free. I would suggest dropping your dislike of Rendezvous though.
The service discovery problem needs to be solved, and it can't be done
in OSC alone - OSC needs addresses to do anything at all. Rendezvous is
the thing that solves this problem. No arguments. :)
I do not dislike redezvous/zeroconf. I just think it is too big of a hammer
for the nail we're trying to hit.
Having said that, no-one so far has agreed with me on this and all votes
are for redezvous/zeroconf. That answers the 2nd quetion I asked originally.
And I would not have asked if I did not want to hear any answers!
The "patching server" (called that from
hereon for lack of a better
name) has simple commands like /set_destination
<url>, /remove_destination <url>, etc. You can imagine a GUI
jack-patch-bay like client for it.
I don't like the idea of yet-another-patch-bay for this. It just pushes
the problem out to the end users, most of which do not know (or want to)
what to connect where. Besides, the application developers know much better
which services their application want.
For example, the sooperlooper GUI is only wants to find sooperlooper
engines. It is not interested in whatever jack.osc offers.
Note I don't object to having a patch-bay for this, but I think it should
not be the main way to make connections. Rather just for viewing and maybe
adjusting later. I'm planning on writing this thing really soon,
unless anyone has a
better idea. The actual server will be almost trivial, just the service
discovery and liblo abstraction will be slightly more annoying to
implement.
I'd recommend writing down the full spec first, and send that out for
review. That's what I'll be doing :) Personally though, I don't much care for
publishing RFCs and debating on
mailing lists for 6 months - I need it to work, now. The general
outline of the system can't change that much - it can be modified to
suit a later agreed-upon standard easily enough. Change an OSC path
here and there, no big deal.
In my mind, an RFC can also follow implementations. A way to promote
convergence on a standard going forward.
The throw-it-out-there/works-for-me approach works as well. No problem
there. My hope is that the LAD community is small enough to converge
on an OSC namespace before final implementation.
Library encapulation is an obvious aspect of such an implementation.
--
Martin
10:23 p.m.
On Thu, 2005-03-03 at 13:38 +0000, Martin Habets wrote:
Feel free. I would suggest dropping your dislike of Rendezvous though.
The service discovery problem needs to be solved, and it can't be done
in OSC alone - OSC needs addresses to do anything at all. Rendezvous is
the thing that solves this problem. No arguments. :)
I do not dislike redezvous/zeroconf. I just think it is too big of a hammer
for the nail we're trying to hit.
Having said that, no-one so far has agreed with me on this and all votes
are for redezvous/zeroconf. That answers the 2nd quetion I asked originally.
And I would not have asked if I did not want to hear any answers!
Unless you want to manually specify port numbers, rendezvous is needed.
OSC just can't do what rendezvous does.
Well, like Steve said, technically they /have/ to follow an
implementation.
I (now) think tackling the rendezvous-service-discovery problem should
be done seperately from the patch bay thing. I'd like it nicely
abstracted in liblo, but on the technical level the two problems are
disjoint, except that one depends on the other to work nicely.
-DR-
On Wed, Mar 02, 2005 at 10:47:31AM -0500, Dave
Robillard wrote:
Just as in jack, applications are free to make 'connections' as they
please - or even ignore the extistance of the service entirely.
Noone argues the benefit of jack's connection system, the benefits are
the same here. If you don't need it, don't use it. I'm working on more
interesting things than plain old "oh look, I found my one client, now
we can talk to each other" stuff. Something more flexible is needed,
just like what we have for audio and midi.
The jack and alsa connection systems aren't called patchbays for nothing:
they emulate the real/physical world. In that world there are no patchbays
for control streams: control information is either non-existing, or it
uses the existing audio/MIDI connections, or it has a proporietary connection
alongside the audio/MIDI cabling.
The takeaway from this is that the control cabling follows the other
cabling.
Back in computer-land this means that if an audio or MIDI connection is
made between X and Y, an OSC connection COULD follow automatically.
I say could here because the OSC connection is only usefull if both sides
can understand each other, i.e. they share an OSC namespace (message
specifications).
How would your sequencer example do in such an environment?
I don't see why OSC should have to be a second class citizen, piggy
backing on audio or (certainly) MIDI. The trivial OSC sequencer
wouldn't have anything to do with audio or MIDI at all.
I look forward to the day my machine doesn't have any MIDI going on at
all (except as a hardware interface), to be honest. Death to MIDI!
The "patching server" (called that from
hereon for lack of a better
name) has simple commands like /set_destination
<url>, /remove_destination <url>, etc. You can imagine a GUI
jack-patch-bay like client for it.
I don't like the idea of yet-another-patch-bay for this. It just pushes
the problem out to the end users, most of which do not know (or want to)
what to connect where. Besides, the application developers know much better
which services their application want.
For example, the sooperlooper GUI is only wants to find sooperlooper
engines. It is not interested in whatever jack.osc offers.
Note I don't object to having a patch-bay for this, but I think it should
not be the main way to make connections. Rather just for viewing and maybe
adjusting later. I'm
planning on writing this thing really soon, unless anyone has a
better idea. The actual server will be almost trivial, just the service
discovery and liblo abstraction will be slightly more annoying to
implement.
I'd recommend writing down the full spec first, and send that out for
review. That's what I'll be doing :) Personally
though, I don't much care for publishing RFCs and debating on
mailing lists for 6 months - I need it to work, now. The general
outline of the system can't change that much - it can be modified to
suit a later agreed-upon standard easily enough. Change an OSC path
here and there, no big deal.
In my mind, an RFC can also follow implementations. A way to promote
convergence on a standard going forward.
The throw-it-out-there/works-for-me approach works as well. No problem
there. My hope is that the LAD community is small enough to converge
on an OSC namespace before final implementation.
Library encapulation is an obvious aspect of such an implementation.
7264
days inactive
7267
days old
linux-audio-dev@lists.linuxaudio.org
16 comments
5 participants
participants (5)
-
Alfons Adriaensen -
Dave Robillard -
Frank Barknecht -
Martin Habets -
Steve Harris