LV2 Saving in a DAW

[baconpaul]

With the excitement today, @jpcima, I was trying to figure out how LV2 saves its state

Notably, src/lv2 doesn't call saveRaw anywhere

Right now Surge saves its state as a binary patch which is a serialization of the parameters plus the binaries of its wavetables. That's what saveRaw/loadRaw do

The lv2 doesn't call these; and I do notice that if I save a session in carla, my settings get lost.

So somehow we need to make sure the LV2 interacts properly with this serialization code. Surge's state is more than just the parameters (the wavetables are not a parameter for instance).

How exactly is it working now?

[jpcima]

You raise a good point regarding this.

Regarding how LV2 works, it's by saving two things:

• a set of the values of parameters
• a key-value dictionary, where keys are string and values are of any type

The parameters are core LV2 and needs nothing special, the extra data is by requiring the "state" extension feature.

It's no problem to add this raw saving feature, except not storing parameters in the blob.
Hosts store parameters themselves according to their preferred format.

[baconpaul]

Right. So just the parameters isn’t enough - we need those wavetables.

So I think the solution is to take the output of saveRaw and put it into the kv table, and when the kv table is presented to us, take that value and put it on loadRaw

Otherwise you’ll set up a session with a wavetable, save it, and won’t get the same sound when you restore.

(The XML also contains more than the parameters in some cases; so I think saving and restoring that, even though some of it is redundant, is the way I would go. Since the synth will be in a consistent state when you stream it doesn’t really matter which one you stream on first.)

[jpcima]

Agreed on the solution, I'll give it an implementation as quick as possible.

The only thing worrying me, it's I'm not sure how safe it is to access into the active editor in there.

LV2 has preference for a purely separated DSP/UI model (which we explicitly bypass by instance-access extension, to follow the model how Surge operates).
I'm not sure, even under the instance-access, I can always count on editor not being destroyed while I access it to save.

[baconpaul]

The load and save methods are all outside the editor; it’s all in src/common in SurgeSynthesizer, SurgeStorage, and SurgePatch. I use the same methods in the Rack version of the code without problem.

So while I also am unhappy with how closely the editor is coupled in memory, in this case I think we will be fine.

[baconpaul]

Oh also I put this one is as a 1.6.2 blocker issue. No particular rush (I think we are still 10 days from shipping the release) but we should fix this before we ship.

[baconpaul]

PR #1141 closes this issue. Thanks @jpcima !

[baconpaul]

Re-opening this issue while @jpcima applies some more fixes.

[baconpaul]

After applying CrystalMath's diff last night I'm going to close this issue.

@falkTX @jpcima as I mentioned on #lad if there are blockers which mean you are not comfy with this LV2 being released, please open a GitHub issue this week tagging me and I'll postpone. Right now I think Friday evening is my release target.