<br><br><div class="gmail_quote">On Fri, Jun 8, 2012 at 8:27 PM, David Robillard <span dir="ltr"><<a href="mailto:d@drobilla.net" target="_blank">d@drobilla.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Fri, 2012-06-08 at 09:45 +0000, Jeremy Salwen wrote:<br>
> Currently, a plugin writer is in a bit of a sticky situation: if the<br>
> plugin supports MIDI CC events, then the internal parameters are<br>
> hidden from the host. You can do something where you have a switch<br>
> which toggles between MIDI CC control, and Control Port control, but<br>
> this is not a fun thing to do, and I think it is additionally<br>
> confusing for the user.<br>
><br>
> I was thinking about the ideal behavior from the user's point of view,<br>
> and a realize that a knob which sends midi CC events to the plugin<br>
> would be ideal. It would be bonus if this knob listened to the MIDI<br>
> stream and adjusted its value to match. If there were an extension<br>
> which specifies "virtual ports" in the .ttl which are actually just<br>
> refences to a midi port + a CC index, and the host just displays a<br>
> knob which generates events for the MIDI port, then the plugin would<br>
> be relieved of the duty of having "duplicate" inputs. I think this is<br>
> simple enough that it could be easily be transparently implemented in<br>
> lilv or whatever successor library.<br>
><br>
> On top of the nice behavior for CC controls, this sort of extension<br>
> could easily use the atom:sequence extension to allow control ports<br>
> which are event based (again transparent to the host application if<br>
> desired). I know some people on the mailing list consider such a<br>
> mechanism superior, and this could be a stepping stone towards<br>
> widespread LV2 support for this sort of control (with plugins getting<br>
> parameter changes before they happen, etc), while still providing<br>
> perfect backwards compatibility for hosts who don't want that fine<br>
> level of control.<br>
><br>
> As always, I may be far off track, so let me know where I'm wrong.<br>
> I'm happy to help with code, etc, and I'm currently working on a host<br>
> and synthesizer in tandem, so they could easily become a<br>
> proof-of-concept for this sort of extension.<br>
<br>
</div></div>We definitely need a dynamic event-based control mechanism, but I don't<br>
think I'd base it on MIDI. MIDI sucks, and 127 steps really just<br>
doesn't cut it.<br></blockquote><div><br>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 <i>similarly</i> 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 <i>that</i> problem is similar to the solution for midi controls. The problem is this:<br>
<br>Suppose I am a synth plugin writer, and I want to make <i>really </i>sure that <br>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.<br>
B) a user that doesn't have a MIDI keyboard can still modify the parameters, regardless of the host.<br><br>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.<br>
<br>Which is why I am suggesting an "event binding" extension that can work with precise, interpolated controls (like you suggest) and <i>also</i> with midi CC controls (as I did).<br><br>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:<br>
<br>[<br>port 1;<br> name "midi in";<br> type midi;<br>],[<br> port 2; <br> name "interpolated_controls_in"; //this port could be hidden, as it just transfers events for virtual ports<br> type atom_sequence;<br>
],[<br> port 3;<br> name "pitch bend";<br> type virtual [<br> port 1;<br> channel 11;<br> ];<br>],[<br> port 4;<br> name "resonance";<br> type virtual [<br> port 2;<br>
channel 23;<br> ];<br> ];<br><br><br>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).<br>
<br><div class="gmail_quote">On Fri, Jun 8, 2012 at 9:23 PM, David Robillard <span dir="ltr"><<a href="mailto:d@drobilla.net" target="_blank">d@drobilla.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, 2012-06-08 at 20:53 -0400, Paul Giblock wrote:<br>
> Yes. I was thinking the same thing. The plugin "touch myself" feature<br>
> would solve this as well as my "import external preset" usecase.<br>
</div>[Chop ruined thread]<br>
<br>
Please do not top post on this list.<br>
<br>
I forgot about that, this indeed adds the ability for plugins to<br>
modulate their own parameters.<br></blockquote><div> </div></div><br>
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 <i>what </i>inside the plugin wants the port changed, the answer could be different.<br>
<br>Jeremy<br></div></div>