[LV2] self automating plugins - RFC

[Robin Gareus]

Hi Hanspeter

Thanks for the comments. That's very appreciated.

On 02/21/2016 11:32 AM, Hanspeter Portner wrote:
> On 20.02.2016 12:44, Robin Gareus wrote:
>> 0) user initiates analysis mode (either via a standard control or a
>> dedicated plugin specific GUI)
>>
>> 1) The plugin tells the host that it entered analysis mode by sending:
>>
>>   atom:Object a auto:setup;
>>
>> 2) the first time a plugin "touches" a parameter it sends
>>
>>   atom:Object a auto:start; auto:parameter <int> ;
>>
>> This is to allow the host to add guard-points. it's like to a user
>> touching a control-knob on a touch-sensitive control-surface.
>>
>> 3) plugin sends a sequence of
>>
>>   a auto:event; auto:parameter <int> ; auto:value <float> ;
>>
>> 4) The plugin releases touch on a parameter by sending
>>
>>   atom:Object a auto:end; auto:parameter <int> ;
>>
>> 5) the plugin may go back to step 2 anytime or tell the host to complete
>> the process (usually user initiated) by sending
>>
>>   atom:Object a auto:finalize;
> 
> Thanks, I too have an application in mind that could profit from such a flow, e.g. training neural nets on events and/or
> audio.
> 
> * Points 0, 5 make sense to me.
> * Are points 2, 4 really necessary? Can't the host figure this out by itself as it knowns to have entered analysis mode?

The analysis may never write any points, but the plugin in question may
still want to force it to a fixed constant value.

In the console world this is like touching a fader but not moving it.
The plugin has no information about past and future automation points
which exist already, nor does it know how the host interpolates automation.

Many plugins do not need this kind of control, but since this protocol
emulates a control surface and not specifying "touch" wold be a major flaw.

> * Point 3 is only needed because you seem to base your RFC on lv2:ControlPort|lv2:InputPort which are write-only by host
> and read-only by plugin.
> 
> Why not use lv2:Parameter in the first place? 

I'm not set on the actual URIs. For now I kept them in the same
namespace for simplicity.

http://lv2plug.in/ns/lv2core/#Parameter "defines the meaning of a
control (not the method of conveying its value)" so that's not it.

>From existing URs, lv2:index is currently closest.

This is however a weak part. Ideally one can send generic automation,
not only to control ports, but e.g. Property changes or also reference
external controls.

I don't yet know a good solution for this. It's the host that needs to
do the eventual mapping.

One idea I've been toying with: The host acknowledges "#setup" and sends
a list of automatable parameters and properties to the plugin. but that
can get complex quickly only to handle a few edge cases.

> They are read-write by both host and plugin (via patch:Get and patch:Set
> messages). There would be no need for additional message types apart from the already existing patch:Set.

I thought the same initially. However Patch:Get/Set is to modify Plugin
properties. Automation modifies Host properties (automation data is not
owned by the plugin).

The SelfAutomation Patch Changes would need to be special cased from
other Patch Changes: We'd need to reserve a sub-namespace of Patch
Properties that plugins can no longer use freely, because they now have
fixed meaning to the Host.

In Ardour, where I prototype this, Patch Changes are directly linked to
Plugin PropertyChanged (drobilla wrote that code). Re-using it for
automation - which in turn can generate Patch Changes - seemed
conceptually wrong.

Furthermore I'm not clear if one can nest Patch Changes: eg. send a
Patch change to queue an automated Patch change.

keep it coming,
robin