Re: [LAD] LV2 Achievement of GMPI Requirement

On Wed, 2012-08-08 at 09:28 +1200, Jeff McClintock wrote:
> > > 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".

The plugin indicating it's bindings is the *only* thing to do here.
Otherwise, the host can just bind however it wants.

It is a simple idea much older than that thread, just nobody has done it
yet. Doing it statically is trivial: just set properties on ports to
indicate their binding.

Static is not so useful though, and control ports suck for a slew of
other reasons anyway, so this has not been established. To do it right,
and dynamically, the things mentioned in my previous reply need doing
first.

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

Indeed. *Global* "bloat" is, by far, the most important consideration.
If there is a One True Software Quality Metric, it is certainly lack of
duplication.

That said, I don't think there would be any considerable bloat of any
variety related to the issues under discussion.

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

I think reality is being slightly misrepresented here: to be clear, it
is not common in LV2 land for plugins to support parameters via MIDI CC
in this way, for all the obvious reasons you have mentioned several
times. Apparently that is common in the VST world, which is why you
want to "argue" for it, but I find that quite strange. Clearly mystery
MIDI parameters in plugins is crap.

Which is to say: Yes, that is stupid; and no, that is not common LV2
practice, nor will it ever be. Preaching to the choir, Jeff :)

LV2 synthesizers typically use MIDI *for notes* for lack of a better
standard at the moment, but not for parameters.

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

This will be an issue to consider if people want a graceful migration
path to events, i.e. events can be used to control the same parameter as
a control port (which is essentially exactly the same issue, except not
MIDI).

Personally I think it's not worth the effort (and don't really think
backwards compatibility gunk belongs in plugins whatsoever).

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev