[LAD] OSC vs LV2 atoms (was: [ANN] Qtractor 0.5.4 - Echo Victor shouts out!)

[Stefan Kersten]

On 05.03.12 21:50, David Robillard wrote:
> On Mon, 2012-03-05 at 12:13 +0100, Stefan Kersten wrote:
>> On 3/5/12 2:16 AM, David Robillard wrote:
>>> I think a very simple stand-alone API to deal with OSC message would go
>>> a long way towards making OSC more feasible for plugins or Jack apps.
>>
>> there are at least two options: a header library i've been using in a 
>> couple of projects [1] and oscpack [2]. both c++ though ...
> 
> OSCPack uses the stream-style << abuse syntax, arguably (though not
> really) the most awful thing about C++.

it's probably an attempt to provide a nicer syntax for packet creation and i
can't say i dislike it - if c++ had first class functions it probably wouldn't
be necessary. anyway, it's only syntax, and as far as i can tell packet creation
and parsing is  realtime safe in oscpack.

> OSCPP looks pretty good though.  Basically a C++ey version of what I was
> talking about.  Thanks for the pointers.
> 
> The "require a size before constructing a message" thing sucks for
> certain cases of generic construction, however this might only be really
> much of an issue for bundles which don't have that problem, so maybe
> it's not such a big deal.
>
> I have been idly wondering if a round-trip OSC<=>Atom bridge would be
> possible.  Atoms are essentially primitives (int, float, string, etc)
> with a few simple collections, all POD (vector, dictionary).  You can
> think of it as sort of a JSONish approach, but low-level rather than
> text.

it seems to be rather similar to bson [1] actually.

> I wonder how one would express a dictionary in OSC?
> 
> Assuming for the moment embracing and extending types is fine, there is
> one easy cop-out solution, make a type-tagged-blob type, the same as the
> normal one except it starts with a type int, but that's pretty opaque.
> Maybe something like [] for arrays? {kvkv...}, e.g.
> 
> /foo/adict {sssi} "name" "David" "id" 42
> 
> =
> 
> { "name": "David"
>   "id":    42 }

without the need for new types you could also "abuse" the bundle system, by
interpreting bundles within the top-level bundle as dictionaries with messages
as key/value pairs; this changed semantics would need to be explicitly supported
by other applications, of course.

there's some talk about this in a thread on OSC 2.0 [2], but i couldn't find a
draft document of the new protocol revision.

<sk>

[1] http://en.wikipedia.org/wiki/BSON
[2] http://lists.create.ucsb.edu/pipermail/osc_dev/2011-November/thread.html#1964