[Devel] Fwd: [RFC] URID extension

David Robillard d at drobilla.net
Fri Jul 22 12:14:21 PDT 2011

On a related note:

The real sticking point here is the event extension.  URI map doesn't
actually *have* to go, but might as well do it cleanly to eliminate
confusion (at the cost of temporary hassle).

My vision for this is basically the existing "atom" extension with a few
minor additions to make it take on the former job of the event extension
as well:

 * An "event" is simply an atom with a timestamp prepended to it

 * A frame-timestamped buffer format ("EventBuffer")

 * An EventBufferPort type which covers the current use case of the
event extension (handling events in the process thread)

 * An AtomPort type which takes only a single Atom/Event and is mostly
(but not exclusively) intended for ports on other non-realtime contexts
that process one event per run invocation.  This can also be used for
polymorphism (ports that accept many types of data).

The reference counting and blob stuff will be reserved (type 0), but not
actually specified, since this was premature.  Nobody actually uses it
to my knowledge.

Simple silly question: any opinions on the name for this?  Is "atom"
good?  "Object" would seem natural as well, but it clashes with RDF
"object".  "Blob" implies complete untypedness which is undesirable.

Other thoughts on this general vision most welcome.  For an example of
the practical use (and high priority) of this: this is what I see as the
solution to e.g. UIs sending "load this file" messages to the plugin.
Similarly, many are interested in killing control ports, the same idea
applies there.

The idea is to have a flexible system for communicating any type of data
(be it simple integers, structures, FFT data, data structures, etc.) in
the LV2 ecosystem, without restricting at all the actual format or use
of that data.



More information about the Devel mailing list