[LAD] LV2 realtime safe memory pool extension

Nedko Arnaudov nedko at arnaudov.name
Tue Nov 13 13:39:40 UTC 2007


Krzysztof Foltman <wdev at foltman.com> writes:

> 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.

AFAIK ATM there is support only for port proprties. enums should be
probably in the core spec (as with other "primitive" port
types for parameters). logarithmic and user rendered should be probably
extensions.

> 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 http://ll-plugins.nongnu.org/lv2/ext/gtk2gui/ and i think
drobilla and larsl came with something improved (not gtk specific
maybe). ATM I use it through slv2 (with some limitations).

glade extension could be cool.

> - 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)

it works for me :)

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

extension for this that would be cool!

> - 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

Uhm, as we talked earlier, I'd prefer several levels. Including
not-instant change.

> - 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 ;)

I think this can be described in the RDF file

> - 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)

This looks like new port type to me (another extension). I'll soon need
to have this port type for lv2zynadd (low update frequency however).

> - 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

That can be useful, however I personally prefer simple plugins with host
providing most of features. Is this feature inteded for custom GUIs,
generic ones or both?

> - 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

I think it is this way already with existing GUI (GTK?) extension.

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

Can be useful, no use for apps I work on.

> - 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

I think this is host responsibility. I personally avoid untyped
(including blobs) communication between host and plugins.

> - 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)

This can be useful. I'd like CC to be bound to
parameters. I.e. suggested CC for this parameter is "portamento".

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

Yup :)

> - 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)

Pretty useful, some IIRC other ppl in #lad wanted this extension too.

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20071113/2f4b1aea/attachment.pgp>


More information about the Linux-audio-dev mailing list