[linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]

Loki Davison loki.davison at gmail.com
Tue Jul 25 00:27:34 UTC 2006

On 7/25/06, Dave Robillard <drobilla at connect.carleton.ca> wrote:
> On Mon, 2006-07-24 at 13:59 -0700, lazzaro wrote:
> > On Jul 24, 2006, at 1:39 PM, linux-audio-dev-
> > request at music.columbia.edu wrote:
> >
> > > what about applying the journal data to an OSC-over-UDP stream. the
> > > journal data could be encapsulated in OSC. sounds like a paper and
> > > liblo patch waiting to happen ;)
> >
> >
> > Personally, my suggestion is that the community starts by
> > defining OSC profiles for specific classes of gestural input
> > and synthesis methods that are widely used in the community.
> > These profiles should standardize syntax and semantics.  If
> > you are working on a music project that is doing something
> > that fits a profile, use the profile.  Otherwise, do as you do today.
> >
> > If OSC goes down this route, one can imagine developing a
> > recovery-journal system with recovery semantics for all the
> > standard profiles.  Part of developing a new OSC profile would
> > be defining the recovery journal for the profile.
> >
> > The least of the benefits of a design like this would be
> > network resiliency. The big win is by defining OSC profiles
> > with semantics, it starts to make sense to create a hardware
> > or software synth that "understands OSC profile X" out of
> > the box, in the same way a synth understands MIDI.  And
> > you can also create mass-market controller hardware that
> > "puts out OSC data using profile X".  And so, you can
> > connect the two boxes up and get plug and play -- just
> > like MIDI.
> But you don't "just get plug and play" with MIDI.  It's all about
> learning with MIDI.
> At the very least with OSC you need to have a (dynamically changeable)
> path prefix for everything (eg such a defined "profile" would definitely
> have to allow for an undefined prefix portion), so no matter how you
> slice it you end up needing some sort of "learn"-ish system anyway.  So
> even with such profiles the real problem to be solved is still service
> discovery and namespace enumeration (eg back to square one).
> -DR-

speaking of which, liboscqs anyone? I'm doing bugger all coding lad
stuff at the moment as I code at work, and play my lovely new semi
hollow guitar at home, but a bit of momentum in all the OSC using
things with liboscqs would be very nice. If there is one fully working
example of actual use in an app it would be easy to then port it to
others apps. It looks really handy.


More information about the Linux-audio-dev mailing list