[LV2] messages and URIs
d at drobilla.net
Tue Mar 6 11:03:00 PST 2012
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"?
More information about the Devel