[LV2] Idea for extension to handle Midi CC controls

[Paul Giblock]

Yes. I was thinking the same thing. The plugin "touch myself" feature would
solve this as well as my "import external preset" usecase.
On Jun 8, 2012 8:27 PM, "David Robillard" <d at drobilla.net> wrote:

> 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
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.lv2plug.in
> http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20120608/d9a0b950/attachment-0002.htm>