[LV2] Idea for extension to handle Midi CC controls

[David Robillard]

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.
> 
> I was thinking about the ideal behavior from the user's point of view,
> and a realize that a knob which sends midi CC events to the plugin
> would be ideal.  It would be bonus if this knob listened to the MIDI
> stream and adjusted its value to match.  If there were an extension
> which specifies "virtual ports" in the .ttl which are actually just
> refences to a midi port + a CC index, and the host just displays a
> knob which generates events for the MIDI port, then the plugin would
> be relieved of the duty of having "duplicate" inputs.  I think this is
> simple enough that it could be easily be transparently implemented in
> lilv or whatever successor library.
> 
> On top of the nice behavior for CC controls, this sort of extension
> could easily use the atom:sequence extension to allow control ports
> which are event based (again transparent to the host application if
> desired).  I know some people on the mailing list consider such a
> mechanism superior, and this could be a stepping stone towards
> widespread LV2 support for this sort of control (with plugins getting
> parameter changes before they happen, etc), while still providing
> perfect backwards compatibility for hosts who don't want that fine
> level of control.
> 
> As always, I may be far off track, so let me know where I'm wrong.
> I'm happy to help with code, etc, and I'm currently working on a host
> and synthesizer in tandem, so they could easily become a
> proof-of-concept for this sort of extension.

We definitely need a dynamic event-based control mechanism, but I don't
think I'd base it on MIDI.  MIDI sucks, and 127 steps really just
doesn't cut it.

I think we need a modern control event, with facilities for announcing
controls and such, and binding to MIDI would be the host's job.

There was some discussion vaguely about this recently.  I was thinking
of making dynamic parameters much like ports in that they're identified
by symbol and index, in the same namespace as ports, so a change event
would look something like:

/* This is event payload so the time stamp is in the header */
struct LV2_Control_Change_Event {
    uint32_t param;  ///< Parameter ID
    float    value;  ///< New value
    uint32_t next_offset;  ///< Time to next (optional, for interp)
    float    next_value;  ///< Next value (optional, for interp)
};

Probably with generic values instead of float, but you get the idea.
The big question here is how to announce and configure such things.
Globally, doing this via ports as well is by far the most flexible
solution, but it might be a bit odd to implement vs API for this.  I
don't know, but if it's possible to cleanly do things via ports, it's
always better to do so.

For just static parameters like this, they can be listed in the ttl
easily.  Perhaps we should just start with this and leave dynamic along
for now?

Cheers,

-dr