[LV2] lv2 state#Dirty

[Robin Gareus]

On 10/15/2016 02:08 PM, David Robillard wrote:
> On Thu, 2016-10-13 at 22:19 +0200, Robin Gareus wrote:
>> On 10/13/2016 09:33 PM, Hanspeter Portner wrote:
>>> How does this event look like?
>>> Is it a new atom type or set via the patch extension?
>>>
>>> e.g.
>>>
>>> []
>>>   a patch:Set ;
>>>   patch:property <http://lvplug.in/ns/ext/state#Dirty> ;
>>>   patch:value true .
>>
>> It is not a property of the plugin. Hence I envisage just a message:
>>
>> As jalv -d puts it these days:
>>
>> ## Plugin => UI (8 bytes) ##
>> <http://lv2plug.in/ns/ext/atom#Object>
>> 	a <http://lvplug.in/ns/ext/state#Dirty> .
> 
> I kind of prefer the property way, mainly for two reasons:
>
> 1) It allows setting dirty to false, which is useful for example if
> plugins have undo or some other mechanism to revert to the previous
> "clean" state

That pushes complexity into the plugin.

IMO, the plugin should only notify the host that something has changed,
and the host can use lilv_state_equals() if it is interested.
That is easy (both plugin & host side) and uses existing APIs.


If dirty was a boolean property, the host would need to keep track of
each plugin's "dirty" flag, also control-ports may have been changed, so
while the plugin's internal state might change to "clean" again (after
plugin internal undo), the complete state may not be.

The plugin could report "dirty", even though it's not:
eg. sample-player: load sample A, load sample B, load sample A.
lilv_state_equals() will be true.
So a host cannot rely on "dirty = true/false" from the plugin and will
have to check the state.

The plugin would need to keep track of its past state(s) to correctly
set "dirty = false". Also meanwhile the host may have saved the state.
lilv_state_save() may or may not imply "clean". So the host would also
need to tell the plugin explicitly if the most recently queried state
was flushed to disk with the session (e.g. save track-template or
snapshots in Ardour saves the plugin's state, but not with the current
session). Then factor in host-side undo and initial session load
state-restore and add overhead to inform the plugin about dirty/clean
asynchronously (state load/save worker).

The complexity of this on both the host and plugin side would be enormous.


Yet there's still a simple lilv_state_equals() which returns the
canonical answer.

> 2) Having a property defined is useful if you want to store dirtiness in
> a typical LV2-ey dictionary, and I imagine we'll be seeing more of these
> "announce a property about this plugin instance" sorts of things in the
> future, so a mechanism a host could implement with a generic "do I care
> about this property change, and if so, do something about it" pattern
> seems nice. 

If "dirty" describes the state of hidden properties, does that make it a
property?

"dirty" is not a property. It is a state or condition. It is not a
quantitative attribute.

Properties are usually part of the interface. But "state-dirty" should
not end up on the GUI. it'll have to be special cased, either way.

Subscribe to "property change" opens a can of worms: The host would need
to reset it in the plugin when the state is saved. Otherwise the
property won't be set to clean and never change to dirty again and no
new change event will be emitted.

The spec of a simple boolean here will need to cover a lot of semantics!
and for what benefit?

> The useful scope of an inherently ephemeral event is much
> smaller.

What useful scope for a value, is there?

Realistically I don't see any plugins or host making use of the boolean
property value for issues mentioned above.

I'll vote for a simple event.

best,
robin