[LAD] LV2 Achievement of GMPI Requirement
jef at synthedit.com
Tue Aug 7 21:28:39 UTC 2012
> > My concept with GMPI (not everyone agreed) was that MIDI was not
> > required *in* the plugin.
> > I decided the *host* should provide that routine (mapping MIDI to port
value). Written once,
> > available to every plugin developer.
> This is almost exactly what I proposed as an LV2 extension in this
> previous thread - " In practice, however, there are a few border cases
where the plugin
> would want to indicate its default MIDI bindings".
Cool, I like it. I disagree that synthesisers are 'border cases' though ;)
> The only real worry is that hosts will be unhappy of the "bloat" added
> to the library they are using.
Yeah, Host developers want the 'bloat' in the plugins, plugin developers
want the 'bloat' in the host.
I think I good experiment is to imagine you have to write both an LV2 host
and 100 LV2 plugins, and you have to write MIDI-binding code. Do you put it
in the plugin OR the host?
-If a feature consumes 100 kB RAM and disk space, and it's implemented on
the host side - that's 100 kB.
-If it's implemented on the plugins side, that's 100,000 kB.
Which choice is more 'bloated'?
A very real scenario is you write this MIDI-binding support, ship 50
plugins, then 6 months later discover a bug. Now if that feature is in the
host - that's one fix and everyone is happy. If that bug is in the 50
plugins, already shipped to 1000 customers. Then you have a much bigger
It's not a question of 'bloat' YES/NO. The code has to go *somewhere*, there
is only a tradeoff - HOST vs PLUGIN.
My choice was to have very lightweight plugins, and a more sophisticated
The one other reason you want the host handling the MIDI Binding...
> On Fri, 2012-06-08 at 09:45 +0000, Jeremy Salwen wrote:
> > Currently, a plugin writer is in a bit of a sticky situation: if the
> > plugin supports MIDI CC events, then the internal parameters are
> > hidden from the host. You can do something where you have a switch
> > which toggles between MIDI CC control, and Control Port control, but
> > this is not a fun thing to do, and I think it is additionally
> > confusing for the user.
True, a plugin's parameters can be set by many sources:
* pre-recorded automation.
* The user tweaking the GUI.
* MIDI messages.
What if they all happen at once? Only the host is in a position to mediate.
For example if you click-down on a plugins GUI slider - you don't expect
that slider to continue jumping arround in response to MIDI automation. The
human is in control until the mouse-up happens, then automation resumes
control. This is a host feature, it can only be implemented of the MIDI
message is decoded by the host, the plugin can't be changing it's own
parameters 'in secret'.
More information about the Linux-audio-dev