[LV2] messages and URIs

[David Robillard]

On Tue, 2012-03-06 at 14:46 +0100, Stefan Kersten wrote:
> On 03.03.12 06:39, David Robillard wrote:
> > On Fri, 2012-03-02 at 12:31 +0100, Stefan Kersten wrote:
> >> 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.
> 
> maybe it could be encoded in the stream so only the receiver needs to byteswap
> (if at all)?

Probably a good idea; always switching to big endian for network would
be pointless overhead 99% of the time.

> > 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?
> 
> well, ipc between multiple machines ;) i admit it's a special case, though,
> outside the scope of LV2.

Perhaps, but this stuff isn't really LV2 plugin specific.  It could be
useful in general, particularly for audio software in general.

> > 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.
> 
> the ids are quite proper

By "proper" I mean given an ID, you can resolve it to the thing.  You
don't have this.  That is the problem here.

(Well, you sort of do, but it's a complex compound ID.  I have been down
this exact path before with the same occasional hints of "hm, maybe I
want all of this stuff in the same map".  Yep, you do.)

We could simply add a 'context' property along-side the 'subject'
property, I suppose.  It would avoid the blank node ID, which is a bit
friendlier, though semantically the blank node ID makes more sense.

> , they just don't fit into the message extension's
> notion of "every object has the same interface". i'll need to redesign a little.

I am not sure what you mean by this.  Same interface how?  Obviously
*any* interface is going to have to use IDs in a similar way.

The message extension is for property-based things.  Manipulating
properties is a very elegant way of controlling things for a whole slew
of reasons.  If it's not property-based, or doesn't fit well, it's not
really appropriate.  There's logistically no reason you have to use the
message extension, they're just atoms at the end of the day.  It should
probably have a different name, but I couldn't come up with a short name
for "control via manipulating properties".  Perhaps just "patch"?

-dr