[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