> > 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 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. P.S. 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'. Best Regards, Jeff _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev