3 Mar
2005
3 Mar
'05
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.