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

Dave Robillard drobilla at connect.carleton.ca
Fri Mar 4 18:16:02 UTC 2005


On Thu, 2005-03-03 at 13:38 +0000, Martin Habets wrote:
> 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
> 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!

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

Unless you want to manually specify port numbers, rendezvous is needed.
OSC just can't do what rendezvous does.

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

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-




More information about the Linux-audio-dev mailing list