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

Dave Robillard drobilla at connect.carleton.ca
Tue Jul 25 16:36:58 UTC 2006


On Tue, 2006-07-25 at 10:27 +1000, Loki Davison wrote:
> 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.

It's on my TODO list.

... It's a big list. :)

-DR-




More information about the Linux-audio-dev mailing list