[LV2] self automating plugins - RFC

[Hanspeter Portner]

On 21.02.2016 13:10, Robin Gareus wrote:
>> * 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.

Ah, I thought after the auto:start, any previous host automation data for all control ports/plugin properties would be
silenced and overwritten by the plugin self-automation. But if you want to drive the plugin with previously existing
automation data and at the same time selectively merge new plugin self-automation data, the "touch" makes sense.

>> * 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.

That's actually what I was referring to, e.g. using properties only for this (which are defined as lv2:Parameter in the
*.ttl) and not support control ports at all, to be able to reuse already existing message types (patch:Set). If you also
want to support control ports you may well need a separate message type.

> 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.

I see, you want a much more fine grained control than I initially thought. I thought the plugin would just send self
automation for ALL its properties/control ports and the host would store them all as new automation.

>> 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).

I think of patch:Get/Set as messages to synchronize plugin state and the hosts (or UIs) representation of the latter.

During normal operation, plugin state is synchronized (or forced) to reflect host automation
  e.g. automation (part of host) -> patch:Set -> plugin state

During self-automation, host automation would be synchronized to plugin state instead.
  e.g. plugin state -> patch:Set -> automation (part of host)

This is no different from a plugin updating its UI, or is it?
  e.g. plugin state -> patch:Set -> UI state (part of host)

So during self-automation, the plugin *would* actually own (or better modify) host automation. That is at least what I
thought you're trying to accomplish.

Maybe I've gotten the whole idea totally wrong...

> 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.

Could http://lv2plug.in/ns/ext/patch/#destination be of help here?

  a patch:Set ;
  patch:destination auto:host ;
  patch:property <urid> ;
  patch:value <...> .

I'm not sure whether patch:destination is allowed inside patch:Set, though.

> 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.

I don't know really. I was just wondering if one could reuse already existent infrastructure...