[LAD] LV2 Achievement of GMPI Requirements

David Robillard d at drobilla.net
Thu Aug 2 15:38:31 UTC 2012


On Thu, 2012-08-02 at 10:59 +1200, Jeff McClintock wrote:
> > I have adapted the GMPI requirements final draft document to a
> > comparison with the current state of LV2: http://lv2plug.in/gmpi.html
> 
> For historical interest. I did complete the GMPI prototype.
>  Now running on Windows (GUI + DSP support) and Mac/Linux (DSP support). We
> have over 1000 plugins available on Windows, mostly related to modular
> synthesis (because that's my interest).
>  This year I ported the SDK and several plugins to Mac, and will also be
> ensuring they run on Linux (Waves Plugins Ltd have a high-end Linux-powered
> mixing desk that runs plugins. It handles mixing and effects for large
> consoles and runs at a rock-solid 1 ms latency).

Interesting.  I didn't think anyone had done any actual work here in
ages, if ever.  I stand corrected.

I don't suppose the code for those modular synthesis plugins is
available? :)

> .SEM Comparison with GMPI...
> 
> http://www.synthedit.com/software-development-kit/sdk-version-3-documentatio
> n/specifications/
> 
> SEMs main differences with LV2:
> * Sample-accurate parameter updates via time-stamped events.
> * Provides a performance optimization mechanism for handling silent audio
> streams.
> * Supports fractional pitch numbers.
> * Provides the ability for an instrument to define an arbitrary set of
> parameters that applies to each voice
> 
> Comments on LV2.....
> 
> >53 Disagree - Achievable entirely with metadata.
> 
> If a feature is achievable with metadata, then you DID MEET that requirement
> (in a cool manner). The spec doesn't say HOW to meet the requirement.
> Update your table to say 'Met' on these requirements.

Well, the requirements I made this comment for say the plugin must
provide a method.  Taken literally, this is not met, and I do not think
it *should* be met, hence I disagree (they clearly derive from mistakes
in VST).  I guess I can interpret "method" more abstractly and consider
them met.

>  The SEM DSP Plugin API has a total of four functions { open(), setBuffer(),
> process(), receiveMessageFromGui() }, the remainder of the spec is covered
> by metadata.  

Did you consciously decide to use a setBuffer method for some reason?  I
consider that (connect_port in LADSPA/LV2) a mistake and efficiency
problem.  Passing an array to process is better.

> >61 ...It is unclear what "patches" means here.
> 
> It means presets. Or more generally save/restore the plugin's state. It
> doesn't mean the plugin *cares* about presets (like VST2), presets can be
> concept the host entirely takes care of.

I see.  "With patches" should have been omitted.  Thanks.

> >73 "GMPI must define a simple in-process custom UI mechanism. " Disagree -
> It is unclear what this requirement means.
> 
> It means the SDK should support GUIs, for example VST provides for opening a
> OS 'Window', what and how you draw inside that window is not specified. More
> importantly the API has a mechanism for tweaking the plugins parameters from
> the GUI. The crux is not that the API supports graphics or drawing, but that
> it supports communicating with the plugin from an abstact 'control surface'
> potentially running in a separate thread or even a separate process space.
>  i.e in SEM the API supports a 'GUI' class getting/setting any of the
> plugin's parameters in a thread-safe manner.

Redundant with 71.  I'll consider it met, then, thanks.

A requirement specifically about a strong and sensible plugin/UI
separation would have been a good one.  By far the worst thing about
porting VSTs with GUIs.  A free for all for UIs to screw with DSP code
is insane.

> >101 "GMPI should allow for copy-protected plugins" Disagree - LV2 is not
> and should not be encumbered with specific "copy protection" mechanisms.
> 
> I would say LV2 MEETS that requirement. This point is simply that you should
> not actively *disallow* copy protection, and that you can check for example
> that the plugin is GPL *without* instantiating it, (because a host might
> want to check the license before unintentionally breaking that license by
> linking to the plugin).

Fair enough, I guess I will just list this as met.  I felt compelled to
at least hint that LV2 is not the sort of project that would ever
consider including evil software crippling garbage as a requirement ;)

> All in all very good to see GMPI requirements used as a benchmark.  A lot of
> smart people put many months into GMPI.  I think it was considered 'too
> radical' at the time (the utter crap VST2 was considered ideal by many, and
> still is).

Yes, I thought it would be a useful comparison.  If there is any more
useful information in an easily digestible requirements-based format,
let me know.

>  My suggestion that it didn't need MIDI at all (MIDI being too
> limited and crufty) resurfaced in VST3 Note-expression.  What we see now
> with LV2, SEM and VST3 is a vindication of GMPI actually being ahead of its
> time.

Anything but events with an arbitrary type tag and a POD body of
*whatever* is a mistake, period.

"Including" MIDI is not a burden, it is a trivial consequence of having
a sane event mechanism.  You just need a type tag, and fill your payload
with some MIDI bytes.  Not allowing for MIDI is completely unrealistic,
and would mean plugins can't work with by far the most common format of
musical control data, and porting existing code to work as a plugin
become dramatically more difficult.  Clearly a loss.  All you get trying
to do things that way is endless mailing list fights about whether to
mandate MIDI, or OSC, or the new Ultimate Control Structure, or whatever
- a waste of everyone's time.

I am ranting a bit here about specification philosophy, but: plugins can
use whatever events they want.  The organic reality of software
development is... well, reality, and good.  The silly idea that The Holy
Specification having written something down means every host magically
supports it is not reality, it is a fantasy.

("Profiles" sound to me symptomatic of this same wrong thinking.
Fine-grained features that precisely describe specific functionality is
the proper way to deal with varying platform and host support, trying to
classify the entire world up front is delusional)

MIDI sucks.  But MIDI is what plugins are using, and MIDI is what hosts
are using, MIDI is what tons of existing code uses, MIDI is everywhere.
It is not LV2's place, and it is not my place, to make some fascist
mandate that you may not use MIDI, which would do nothing but cripple
LV2 and reduce support and power.  That said, something better is indeed
needed, but 

(Sidenote: Similarly, Jack royally screwed up by mandating MIDI only,
despite being presented with a patch by myself to trivially make the
event system generic, and that is why you can't sequence precise
per-note pitch bends and parameters in Ardour and control a Jack Synth
via OSC or whatever else today, a common source complaint on IRC these
days.  That is what you get when you don't let developers freely
develop)

That said, sure, MIDI sucks.  Something better is needed, but certainly
not some One Ultimate Control Structure to the exclusion of everything
else.  Extensibility is the way.  Anyway, the actual details are the
same.  With LV2 I have been thinking a lot about this, but there are 3
main options for controllers:

1) Use atom "objects".  These are essentially POD dictionaries, and thus
extensible.  By far the most flexible, automatically serialisable, but
with a bit of conceptual and syntactic overhead to actually using them

2) Use OSC.  Frankly atoms are better, but OSC is 'standard'.

3) Use a special struct.  This is the knee-jerk C programmer thing to
do, and simple and fast, but it worries me because if something is
omitted from that struct - oops, now everyone has to switch to an
entirely new one.  I guess an extensible struct with a size field would
be a good compromise, we should have made *all* the structs like that
anyway.

I have been generally going by the philosophy that custom structs are
bad, since there is an existing serialisation mechanism in place that
works with standard atom types that is used e.g. for cross-process
communication between UI and plugin as well as state saving and so on.
It saves to/from the same format as LV2 data files, meaning describing
things there for whatever reason is also natural.  This might be an
exception for performance reasons, however.  It might be best for me to
just forcefully drag people into using atoms for everything, though,
since that is also what you need to use to get higher level control like
"load this sample", and it means progress is not held up by explicit
host support for every little thing... perhaps I need to spend some more
effort making working with dictionaries really clear and obvious, it is
the best solution on paper, it's just confusing to people who don't get
the big picture.  I very much like the idea of completely open ended
communication between plugins and UI, as well as between plugins (and/or
plugins and hosts), where everything is fast, numeric, and POD, yet
serialisable to the standard LV2 data syntax.  It seems worth it.
Liberating, but you have to 'get it' first.

Anyway, I've gone on a digression.  Thanks for the input, document
updated as suggested.

-dr

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


More information about the Linux-audio-dev mailing list