[linux-audio-dev] OSC, mDNS and LASH: a good combo?

Martin Habets errandir_news at mph.eclipse.co.uk
Thu Mar 3 13:38:28 UTC 2005

On Wed, Mar 02, 2005 at 10:47:31AM -0500, Dave Robillard wrote:
> > > 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.
> 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

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

How would your sequencer example do in such an environment?

> > > 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 :)
> 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!

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


More information about the Linux-audio-dev mailing list