Re: [LAD] LV2 realtime safe memory pool extension

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?

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.

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

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

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

- 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

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

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

- 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

- 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

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

- 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

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

- dynamic parameters (Nedko is already working on these)

- 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 hope everything is clear, as it refers to things existing in digital
audio world for ages. And those are extensions I dream of :), not
something that should go into core specs (maybe bpm could be retrofitted
into the core, but that's a political decision with potentially negative
results at this stage).

And as for coding for fun - unfortunately doing really good things
(comparable to, say, Native Instruments software) involves not just fun
stuff, but also some tedious crap - so some external motivation seems to
be beneficial.

Krzysztof

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Nov 13 16:15:02 2007