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

Dave Robillard drobilla at connect.carleton.ca
Wed Mar 2 15:47:31 UTC 2005

On Tue, 2005-01-03 at 14:58 +0000, Martin Habets wrote:
> On Tue, Mar 01, 2005 at 01:27:38PM -0500, Dave Robillard wrote:
> > 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.

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

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

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

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.


More information about the Linux-audio-dev mailing list