13 Nov
2007
13 Nov
'07
2:07 p.m.
On Tue, 2007-11-13 at 15:52 +0000, Krzysztof Foltman wrote:
Yes, API stability, which will obviously have to wait until after LV2 is released.
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.
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
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? 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). 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.