[LAD] LV2 realtime safe memory pool extension

[Lars Luthman]

On Tue, 2007-11-13 at 15:52 +0000, Krzysztof Foltman wrote:
> One more thing - is there any way to communicate lack of data on an
> audio port? For example, a synth with no note plugin could communicate
> the fact that it produced a buffer full of zeros to the following
> plugins, so they don't process those zeros unnecessarily?

No. It sounds very similar to the input-parameter-has-changed thing -
maybe both could be solved by defining a new port class whose buffer
pointer points to a bitmask large enough to hold one bit for each plugin
port, and using that to indicate when something has "happened" at a port
(where the definition of a "happening" depends on the port class) ?

There also are extensions in development (I think) that only call plugin
callbacks if there actually is relevant input, but I think that was more
for message passing and things like that.


> Sure, it's not trivial to set that flag correctly in plugins that deal
> with any kind of internal state (especially complex one like in reverb),
> but it worked very well for Buzz. The end result was the ability to use
> very complex processing networks - as long as not all instruments
> produced sound all the time.

This definitely sounds very useful.


> > There is a GTK+ GUI extension, although not stable. The GUIs are loaded
> > from shared modules listed in the RDF files, just as plugins, so it can
> > be up to the host whether they are loaded in the same process as the
> > plugins or in another IPC/RPC-controlled one.
> 
> That's nice. The only missing part is stability, then?

Yes, API stability, which will obviously have to wait until after LV2 is released.


> > Well, IEEE754 doubles have 52 fraction bits so they can be at least as
> > sample accurate as 32 bit integers. I agree that most hosts and plugins
> > will not use sub-sample precision, but one cast per event isn't that
> > expensive.
> 
> I've proposed my modifications to the MIDI Port spec - and perhaps could
> provide a library to translate between old and new buffers. I definitely
> think the change is worth it, because it seems to be simpler, cleaner
> and doesn't cause misaligned memory access (which can cause SIGBUS on
> SPARC machines and performance penalty on x86).

Fixed size MIDI events means no SysEx messages though. Obviously there
are better mechanisms than SysEx for common things like sample dumps,
but it may still be nice to be able to send small chunks of arbitrary
data over MIDI without having to translate it to something else when
passing it to an LV2 plugin.


> Can a plugin or GUI send MIDI data back to host?

Yes and no. Since extensions to the core LV2 spec can define new port
classes that may need new ways of reading and writing data the GUI <->
plugin communication API needs to be extendable as well. The GUI has a
generic port_event(uint32_t index, void* data) function, and the host
provides a write_port(uint32_t index, void* data) function. The way it
works is that the GUI specifies which plugin ports it wants to receive
data from, and requires "Features" for the port classes of those ports
and those that it is planning to write to. These Features work like
normal lv2:Features - if the host does not support a required Feature it
is not allowed to load the GUI - and specify when and how the host
should call port_event() and what it should do with data passed to
write_port(). The only port class that a GUI host must know how to deal
with is control ports, for which it should call port_event() when the
port value changes, change the port value when write_port() is called,
and interpret the data pointer as a pointer to a single float containing
the new value. There is an unpublished Feature like this for MIDI as
well, which is implemented in Ingen and my experimental host.

> > I want dynamic note names too, so if no one else does that extension I
> > might (at some unspecified time in the far future). Not sure if the
> > plugin needs to be aware of dynamic CC mappings though, that can be
> > handled completely by the host - the plugin just needs to provide
> > defaults.
> 
> I thought of a situation where CC binding is defined on a per-preset
> basis, or for things like something-to-LV2 adapters.

That they are defined on a per-preset basis doesn't mean that the host
can't handle them, if it also handles the presets. After all, if the
host already knows how to save and restore the state of a plugin (which
it should to enable session saving) it pretty much knows everything
needed for presets. The plugin can define some standard presets in it's
data files, but it doesn't have to actually manage them itself. This is
how I do it in my experimental host and plugins.


--ll