[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