[LV2] lv2 state#Dirty
d at drobilla.net
Sat Oct 15 15:22:21 PDT 2016
On Sat, 2016-10-15 at 17:14 +0200, Robin Gareus wrote:
> 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
> "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.
Announcing it as a property does not somehow imply that all this
complexity you've pulled out of thin air needs to be dealt with, any
more or less than it does for a special event.
That said, I really don't care that much. Most of the semantic
arguments above are nonsense, but somewhere in there is an argument that
a "something has changed" event makes sense and a
property/state/condition/whatever (all of which are equivalent in this
model) does not, which is more compelling.
... but having a property defined is still more useful
More information about the Devel