[LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!

[David Robillard]

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

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.

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 }

-dr