[LV2] LV2 State : (Partially) saving / restoring complex state

David Robillard d at drobilla.net
Mon Jan 5 13:38:44 PST 2015


On 2014-12-22 14:18, Harry van Haaren wrote:
> On Mon, Dec 22, 2014 at 6:31 PM, Michael R. Fisher 
> <mfisher31 at gmail.com> wrote:
>
>> I like the idea of saving a JSON file (by using map and make path 
>> features). However, I think it would be better if lv2 state had a 
>> mechanism for saving a "tree" data structure. 
>
> The docs on State say ( http://lv2plug.in/ns/ext/state [1] -
> Extensions to this Specification ) 
> "It is likely that other interfaces for working with plugin state
> will be developed as needed. This is encouraged, however everything
> SHOULD work within the state model defined here. That is, do not
> complicate the state model."
>
> I guess that doing this tree data structure is doing exactly that:
> its no longer a key:value pair (aka "property"), but is being
> complicated to an (Atom like?) traversable structure with nesting etc
> etc. 
>
> I'll experiment with the JSON solution, and if no strong
> counter-arguments arise and testing goes well, then that will become
> the solution. 
>
> "Workable" and "existing" come to mind: I'm trying to release Fabla2 
> soon :)

It is, in general, better to keep things "atomey", you can make values 
Object
atoms to do this.  If you have a super massive number of URI keys, 
though, that
is not so good.  If there's no way to work around that, saving state to 
a file
in whatever syntax is an acceptable way to go.  The downside is that 
it's a file
which brings in a lot of baggage, but if you need files anyway this 
isn't really
a big deal.

The nice thing about the atom stuff is you can use the same keys for 
realtime
control as you save in your state, so there is no need to define 
everything
twice.  This works wonderfully for some things, and not so much for 
others.

Just try not to shoot yourself in the foot with a shitty non-extensible 
format.

-- 
dr



More information about the Devel mailing list