[LV2] Idea for extension to handle Midi CC controls

[Jeremy Salwen]

On Fri, Jun 8, 2012 at 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 may have been unclear, but i certainly didn't mean that MIDI would become
the standard for event-based controls.  I was suggesting that it could work
*similarly* to a more full-featured event-based control mechanism.  I think
there is a problem with midi CC controls, and I was just pointing out that
the solution to *that* problem is similar to the solution for midi
controls.  The problem is this:

Suppose I am a synth plugin writer, and I want to make *really *sure that
A) a user that connects my plugin to their MIDI keyboard and starts playing
notes can tweak a knob on their keyboard and have the corresponding
parameter of the synth changed, regardless of the host.
B) a user that doesn't have a MIDI keyboard can still modify the
parameters, regardless of the host.

If I just expose the parameter as a port, a host which thinks MIDI CC
binding is too complicated/a waste of time/whatever will fail to uphold
requirement A, and if I just process the midi CC controls internally, any
host will fail to uphold requirement B.

Which is why I am suggesting an "event binding" extension that can work
with precise, interpolated controls (like you suggest) and *also* with midi
CC controls (as I did).

For example (please ignore the syntax, it's just too much work for me to
make something that looks like valid turtle), you could have a plugin like:

[
port 1;
 name "midi in";
 type midi;
],[
 port 2;
 name "interpolated_controls_in"; //this port could be hidden, as it just
transfers events for virtual ports
 type atom_sequence;
],[
 port 3;
 name "pitch bend";
 type virtual [
           port 1;
           channel 11;
          ];
],[
 port 4;
  name "resonance";
  type virtual [
          port 2;
          channel 23;
          ];
  ];


If it's not clear, the idea is that port 3 is just a reference to a
specific channel in port 1, and port 4 is just a reference to a specific
channel in port 2.  So port 3 will be translated to midi CC events, and
port 4 will be translated to precise interpolated atom events (of the sort
you were discussing).  So in both cases if the host doesn't care about
sample-accuracy, it can just blindly treat those ports like normal control
ports, and lilv will do the minor amount of work required to translate the
controls.  On the other hand, in both cases, if the host cared to, it could
access the additional level of control offered.  (i.e. in the midi case it
could remap CC numbers, update the GUI, or enable/disable touch, and in the
event-based control ports, it could provide the information for sample
accurate interpolation).

On Fri, Jun 8, 2012 at 9:23 PM, David Robillard <d at drobilla.net> wrote:

> On Fri, 2012-06-08 at 20:53 -0400, Paul Giblock wrote:
> > Yes. I was thinking the same thing. The plugin "touch myself" feature
> > would solve this as well as my "import external preset" usecase.
> [Chop ruined thread]
>
> Please do not top post on this list.
>
> I forgot about that, this indeed adds the ability for plugins to
> modulate their own parameters.
>


This actually seems like a simpler solution. The only downside I can think
of is that the plugin could end up fighting the host for control of a
port.  Then what happens?  Depending on *what *inside the plugin wants the
port changed, the answer could be different.

Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20120609/b2b08699/attachment-0001.htm>