<div dir="ltr">Hi Robin,<br><br>I'm just saw the following section<br>
<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">For cases like this, it'd be great if the plugin would have a mode to<br>
 - first, analyze the data<br>
 - write its internal values to an automation track [of the plugin host]<br>
 - the user can modify the data (here: manually open the gate or the<br>
fixes note/pitch)<br>
 - later, the plugin processes data using the [user modified] analysis<br>
results</blockquote><div><br>and wanted to comment that the <a href="https://code.google.com/archive/p/talentledhack/" target="_blank">talentedhack</a> can do this with MIDI input/output.<br><br></div><div>Jeremy<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 20, 2016 at 6:44 AM, Robin Gareus <span dir="ltr"><<a href="mailto:robin@gareus.org" target="_blank">robin@gareus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Here's an idea that has been floating around for quite some time.<br>
<br>
Many plugins only expose indirect controls.<br>
<br>
Prime example is a Gate. You configure: threshold, attack, decay and<br>
maybe a hysteresis parameter. The plugin does its thing and gates e.g. a<br>
kick-drum. Except in the bridge of the song, it misses a kick...<br>
<br>
Another example is automatic pitch correction.<br>
<br>
<br>
For cases like this, it'd be great if the plugin would have a mode to<br>
 - first, analyze the data<br>
 - write its internal values to an automation track [of the plugin host]<br>
 - the user can modify the data (here: manually open the gate or the<br>
fixes note/pitch)<br>
 - later, the plugin processes data using the [user modified] analysis<br>
results<br>
<br>
There are two ways this can be accomplished: online and offline.<br>
<br>
The offline mechanism has the benefit that a plugin could analyze the<br>
complete file (or region), do random seeks and take future data into<br>
account (read-ahed, no latency).<br>
<br>
Online analysis on the other is a lot more simple and very easy to<br>
integrate into existing projects. A plugin is already analyzing the data<br>
to process it live.  Also reporting those values to the host is in most<br>
cases trivial, as is bypassing the internal analyzer and using<br>
host-provided data instead.<br>
<br>
<br>
Enter LV2,<br>
<br>
Doing online analysis with LV2 is staggeringly easy! A plugin just sends<br>
an Atom message sequence to the host in the form of<br>
<br>
<br>
@prefix auto <some URI prefix><br>
<br>
<timestamp atom:Object><br>
 a auto:event;  auto:parameter <int> ; auto:value <float> ;<br>
<br>
<br>
  <int> is the lv2:index of the parameter.<br>
<br>
<br>
To complete the picture I propose the following protocol where all Atom<br>
Objects are timestamped, sent in an Atom Sequence.<br>
<br>
<br>
0) user initiates analysis mode (either via a standard control or a<br>
dedicated plugin specific GUI)<br>
<br>
1) The plugin tells the host that it entered analysis mode by sending:<br>
<br>
  atom:Object a auto:setup;<br>
<br>
2) the first time a plugin "touches" a parameter it sends<br>
<br>
  atom:Object a auto:start; auto:parameter <int> ;<br>
<br>
This is to allow the host to add guard-points. it's like to a user<br>
touching a control-knob on a touch-sensitive control-surface.<br>
<br>
3) plugin sends a sequence of<br>
<br>
  a auto:event; auto:parameter <int> ; auto:value <float> ;<br>
<br>
4) The plugin releases touch on a parameter by sending<br>
<br>
  atom:Object a auto:end; auto:parameter <int> ;<br>
<br>
5) the plugin may go back to step 2 anytime or tell the host to complete<br>
the process (usually user initiated) by sending<br>
<br>
  atom:Object a auto:finalize;<br>
<br>
<br>
All in all this is very much like a midi control surface sending<br>
control-data to a plugin host.<br>
<br>
<br>
Plugins which support this flow must have<br>
<br>
   lv2:optionalFeature auto:canWriteAutomatation;<br>
<br>
lv2:AtomPort, lv2:OutputPort that send messages must have<br>
<br>
  atom:bufferType atom:Sequence ;<br>
  atom:supports auto:automationControl;<br>
<br>
and lv2:InputPort, lv2:ControlPort which can be self-automated:<br>
<br>
  lv2:portProperty auto:automationControlled ;<br>
<br>
<br>
<br>
Any thoughts, comments so far?<br>
<br>
<br>
A slight variation would replace  "auto:parameter <int>" with a mapped<br>
URI. That would allow plugins to automate e.g host parameters or<br>
parameters of other plugins  and needs a more complex setup sequence.<br>
I'm not sure if this is useful or desirable.<br>
<br>
<br>
Cheers!<br>
robin<br>
<br>
<br>
PS. I'll address offline analysis in a separate proposal.<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.lv2plug.in">Devel@lists.lv2plug.in</a><br>
<a href="http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in" rel="noreferrer" target="_blank">http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in</a><br>
</blockquote></div><br></div>