Re: [LAD] LV2 Achievement of GMPI Requirements

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

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

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

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

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

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

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

Jeff McClintock

www.synthedit.com

Best Regards,
Jeff

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Aug 2 04:15:01 2012