[Devel] Requiring hosts to pre-initialize outputs, and plugins to always write

David Robillard d at drobilla.net
Sat Feb 11 19:52:03 PST 2012


Hi all,

In polishing up the atom extension for release I have hit a bit of a
dilemma.  It applies to the replacement for event ports and impacts both
host and plugin authors.

= Background =

An "atom" is a chunk of data with the header:

typedef struct {
    uint32_t type;
    uint32_t size;
} LV2_Atom;

They will be used in many places, one of which is port buffers.

= Problem =

When using (variably-sized) atoms for output buffers: how does the
plugin know how much space is available for writing?

There are a few options:

1) All variable-sized atom types (like LV2_Atom_Sequence) must have a
separate 'capacity' field to handle cases like this where they are used
as outputs.  Pros: like the current code for event ports, no
initialization required, plugins can not write anything and data is
valid.  Cons: The actual data type has been bloated with a field that
only makes sense when that type is used for writing.

2) Specific rules: the host MUST set type to 0 and initialize size to
the capacity before calling run, and the plugin MUST always write a
complete atom to every output port, no matter what.  Pros: no wasted
space, rules are simple and cover all atoms.  Cons: host MUST initialize
buffers before every run, just a pointer to the atom does not give you
capacity once you're writing.  Type field can not be used for
"polymorphism" (i.e. requesting the plugin write a particular type) but
this is probably better done with a separate function anyway.

3) Special container type: connect ports to a struct { uint32_t
capacity, LV2_Atom* buffer } or similar.  Pros: logistics detached from
type. Cons: maybe a bit less friendly to work with, connecting ports
directly to whatever atom is kind of nice, utterly useless for inputs.
Perhaps there is other useful stuff to put in such a "meta-buffer" to
better justify it?

Basically trolling for opinions on what to do here.  Hopefully the issue
is clear.

-dr




More information about the Devel mailing list