13 Nov
2007
13 Nov
'07
9:40 a.m.
Krzysztof Foltman <wdev(a)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>