[LAD] LV2 realtime safe memory pool extension

[Lars Luthman]

On Tue, 2007-11-13 at 13:08 +0000, Krzysztof Foltman wrote:
> Lars Luthman wrote:
> 
> > That may be a good idea for the future, but for now it's more important
> > that the core spec is released. After that anyone can define extension
> > sets or compatibility levels. The core spec has taken too long already,
> > if it has to wait for more extensions and other additonal structure it
> > will never ever be finished.
> 
> It doesn't have to wait for compatibility levels. It's something you may
> keep in mind for the future, but doing compatibility levels exactly at
> this moment is pointless, because the extension APIs aren't stable yet.
> It's a sort of potential long-term goal.
> 
> What is the current intended set of "hard" requirements for the core
> spec? What are the roadblocks?

Not sure if there are any. I think it's mostly about getting everything
together and writing some docs.


> I've read the specification, and it looks very reasonable, some things
> may be missing (I would suggest "logarithmic", "enum" and "userRendered"
> PortProperties), but it's a definite improvement from LADSPA. I don't
> know how you're dealing with backwards compatibility between different
> versions of the same plugin - is there any mechanism in place.

Not really. If a new version of a plugin is completely compatible with
the old one (e.g. just bugfixes or a nicer GUI) it should have the same
URI, and the hosts will treat it as an identical plugin. If not, it
should have a different URI and the hosts will treat it as a completely
different plugin. There is no way to specify that a plugin is backwards
compatible with another one and maybe can use presets for it or be used
as a drop-in replacement with suitable port mappings. Maybe an extension
could be defined for that if a pressing need arises.


> However, in order for it to be successful, a good set of extensions
> should follow, some ideas (not mine, and I have probably mentioned them
> before):
> 
> - a stable GTK+ GUI API is a must! (we could dream of the ability to use
> it in outside process for non-GTK+ hosts, but simple goals are better
> for start); least of all, the ability for the host to use GLADE XML
> provided by a plugin + call some callbacks on value changes

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. There is no generic loader
for them though, that might be useful.


> - so is the ability to deliver MIDI or MIDI-like events with sample
> accuracy. But that may be added later (I'm looking at your MIDI Port
> extension, it looks perfect except for double values for timestamp - I
> think int32 and sample accuracy would be simpler/faster and equally useful)

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.


> - the way to communicate current bpm from host to the plugin (bpm-synced
> delays, flangers etc were a standard in 2000 or so :) )

Agreed. This would be a trivial extension, you could just define a port
hint that said that a certain control input port should be fed the
current BPM value. A complete transport sync mechanism would be more
complex but also more useful - think loopers, record/playback plugins,
automatic arpeggiators.


> - the ability to flag parameters as non-automatable (because they
> involve heavy calculations or audio clicks on each change) - I think VST
> has this feature, and it had its practical uses

There are a couple of different extensions in development for sending
non-RT-safe commands to plugins. Don't know if there's anything stable
yet.


> - plugin icon (BEAST/BSE has that, so does Buzz), for modular synths,
> effect icons in mixers and the like... it could bring some life to
> boring GTK+ interfaces ;)

There's nothing published anywhere, but I've been bundling SVG 1.0 icons
with some plugins and pointing to them with a triple in the RDF data
files. The SVN version of Ingen shows them in the plugin menu and on the
canvas modules.


> - the ability to paint on plugin icon in realtime (so that we may make
> oscilloscope plugins or display current frequency response plots in
> filter plugins)

Wouldn't full-blown GUIs be more suitable for this? I've been using them
for things like meters and fancy controls:
http://ll-plugins.sourceforge.net/ogg/bling.ogg (the blue thing is a GUI
for an LV2 port of Gordon Pearce's Nekobee)


> - the ability for the plugin to provide its own text or graphical
> representation for parameter values (so that it can use weird parameter
> scaling and not depend on host) - both VST and Buzz use that; the
> possible extension is to allow custom string-to-value conversion so that
> values can be entered by hand

There is a Units extension that can be used to define units for ports
(linked from the spec page, I think) and the core spec has scalePoints,
which allows plugins to define labeled port values (e.g. "0 dB" for the
multiplier value 1.0 on a simple gain plugin).


> - the ability to have GUI .so for a plugin separate from audio .so (but
> with its name exposed by audio .so), so that a plugin can work with or
> without GTK+ available

See above.


> - optimization of parameter handling by telling the plugin which
> parameters have changed (using a bitmask) - which is a must for a
> 200-parameter synthesizer :)

I don't think there's anything for this yet, but it shouldn't be hard to
do in an extension - there are well-defined mechanisms for adding host
and plugin callbacks using "Features". Or maybe it could be done as an
input port class.

It isn't strictly necessary though, e.g. WhySynth works OK as a DSSI
without it and it has lots and lots of control ports. But yeah, it might
be nice.


> - the ability for the plugin to store "memory dumps" inside songs
> (basically, the loaded sf2's for fluidsynth) - so that songs contain all
> the data they should - VST and Buzz have that, LADSPA doesn't

Yes, session management will be crucial, especially when we allow
arbitrary extensions that may change the plugin state in all sorts of
weird ways. I don't think there's anything that does this in a generic
way at the moment.

LADSPA doesn't really need it since its only I/O method is the ports.
Sure, a plugin can theoretically change it's internal state during a
session to something that is completely different from what you get if
you re-initialise it with the same control input values, but I don't
think there are (m)any LADSPA plugins like that at the moment.


> - ability for the plugin to expose things like note names, control
> changes (your MIDI map extension is a good "version 1.0", but it might
> be later expanded with ability to define CC dynamically and with the
> ability to provide names/drum counterparts for the individual notes, for
> drum synths and the like)

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.


> - dynamic parameters (Nedko is already working on these)

Haven't looked much at this yet.


> - dynamic ports, so that a mixer plugin can have new inputs/auxes added
> on the fly (very low priority in my opinion, and nobody seems to be
> working on it)

I agree that there probably isn't a pressing need for it, but it would
be nice to have. It could also be used for dynamic polyphony in synth
plugins, with host access to the individual voices.


--ll
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20071113/395129c8/attachment.pgp>