[LV2] messages and URIs (was: lv2:relation)

David Robillard d at drobilla.net
Fri Mar 2 21:39:11 PST 2012

On Fri, 2012-03-02 at 12:31 +0100, Stefan Kersten wrote:
> On 3/1/12 8:21 PM, David Robillard wrote:
> > On Thu, 2012-03-01 at 12:38 +0100, Stefan Kersten wrote:
> [...]
> >> i have a related problem (i'm not very fluid yet with RDF): for control
> >> of my audio engine i am thinking about moving from OSC to something more
> >> structured and flexible such as LV2 atoms and messages.
> >
> > Me too.  OSC hasn't really cut it.  I think I might drop all the
> > protocols from Ingen and just implement LV2 atom control, then implement
> > separate bridges for various protocols.  That way, everybody gets the
> > benefit.  I am not sure if a 100% mapping to/from OSC is possible,
> > though pipes/ringbuffers/http/truly-awful-midi-sysex/etc will work.
> i think it would be good to have an architecture independent binary wire 
> specification for LV2 atoms in order to be able to compare 
> expressiveness and performance to OSC.

This could be done for the standard types anyway (but you couldn't
guarantee it for all atoms in general).  It should be relatively
straightforward to write a function that scans an atom recursively and
switches the endianness of all the numbers to network order and back.

Personally, I hadn't planned to care about that, because usually you
have one of two situations: control from user interfaces and the like,
where text is plenty fast enough, or IPC on a single machine for actual
processing, where endianness doesn't matter.  Is there even a reasonable
use case for an architecture-independent binary wire protocol?

>  currently it's difficult to 
> represent nested structures in OSC, which might improve with the next 
> protocol major version (see [1]). if it's important to retain fast 
> integer-based dispatch for LV2 atoms across machines, it would be 
> necessary to implement a protocol for global URID mapping (see also 
> [2]), complicating things a little ...

Yeah, that's a tricky part.  You can cheat and sent a local mini-map
along with messages though, if the client doesn't already know a
host-mapped URI.

> >> let's say my engine maintains a tree of nodes where the leaf nodes
> >> correspond to instances of LV2 plugins. nodes are created and
> >> manipulated by a client via asynchronous messages and identified via
> >> unique integer ids.
> which datatype would i use if i didn't want to use a mapped URID but a 
> URI string? there is a string type but apparently no URI type.

There is atom:URID for mapped URIs and atom:URI for string URIs.  The
latter is mainly for relative URIs since you can't map those, or
situations where you don't want to be hammering the map for one-off

> > Why do you need the myEngine:NodeId?  What other namespaces do you have
> > for numeric IDs?  Another option could be to reserve the last few
> > characters for a type so you can still distinguish type with a single
> > numeric ID.
> there are at currently four id namespaces, for nodes, control and audio 
> buses and buffers.
> i could use different base URIs, e.g.
> urn:myengine/node#12345
> urn:myengine/audioBus#12345
> urn:myengine/controlBus#12345
> urn:myengine/buffer#12345
> but this seems wasteful in terms of bandwidth and memory allocator 
> pressure (mainly for nodes, the other resources are generally more 
> persistent). i think the most efficient option would be to encode the 
> type in the id, but it seems like a hack ... now that i think of it, the 
> type doesn't really need to be transported; if every resource knows how 
> to handle a message, i just need one big map of URI/URID to resource.

Yeah, I think you really want to make all these things use a single
namespace, regardless of whether its numeric or string.  Your problem
isn't really LV2 atom specific, it's that you don't have proper IDs for
things you want to talk about.  That never ends well.

If your performance needs are that high, I don't see any real
alternative to a single number.  The blank node description in your
original email is over 30 bytes in binary format, those headers add up.

> another option i thought about would be using UUIDs for resources; then 
> a resource id would be unique (within certain confidence bounds) among 
> several clients and could be generated locally without a central 
> registry. would it be possible for the atom extension to support a 128 
> bit UUID type?

Not a fan.  128 bits does not a globally unique identifier make.  Since
you're inherently talking about things in a central audio engine, I
don't see how a central registry is a problem, just make the engine
generate IDs.

Every primitive type is another case that needs to be handled in all the
code that deals with atoms.  I'd rather not add a dubious one like that
unless it's *really* needed, particularly since UUIDs don't really fit
in with the model here.  If you want to spend 16 bytes or so on an ID,
might as well just use a string.


More information about the Devel mailing list