AudioProcessorValueTreeState, setStateInformation and meta parameters


#1

I’m using APVTS for my parameters and it’s not restoring state exactly. I’m wondering if my meta-parameters are the culprit.

My meta-parameters set the value of 8 other normal parameters, but it’s possible that the user has modified any of them after setting the meta-parameter. And wouldn’t the order in which they are restored (in setStateInformation() in particular) then matter? Meaning, it would need to restore the meta-parameters first, then restore the individual parameters so they are overridden.

And I’m guessing that parameters.replaceState(newState) doesn’t account for that.

Has anyone else run into this situation? And how did you handle it?

I’m guessing that I’ll just have to restore them all manually in the order I think best.

Thoughts?


#2

Anyone out there using meta parameters with AudioProcessorValueTreeState?


#3

Our latest release is using APVTS from JUCE 4.x. so we’re doing some tricks in-order to keep things smooth.
So we haven’t used the newer replaceState.

But I’d suggest you’d add a flag before updating state so if you’ve got parameter listeners you’d wait until all is loaded / discard unwanted listeners to trigger.


#4

any feedback from the juce team regarding this?

should we have access to the valueTreeChanging CriticalSection in order to do that safely?


#5

So I ended up not using parameters.replaceState(newState) and instead rolled a loop that goes though the parameters one by one, in the order that makes sense for the meta parameters and all was well.

Until yesterday…

A beta tester told me that my Import Preset function (basically, read a preset file from anywhere on disk, set parameters and put it in my preset tree as a saveAs()) all of a sudden wasn’t working. After some ugly debugging, I realized that the underlying ValueTree wasn’t updated fast enough (I believe it’s updated on a timer) before I saved the preset. I ended up having to call flushParameterValuesToValueTree() after setting the parameters and before saving to disk. I also had to move flushParameterValuesToValueTree() to public to make it work.

It would be great if parameters.replaceState() knew how to deal with meta parameters better, but I’m not sure how it would know what to do.


#6

anything on the roadmap about that? how are you dealing with meta parameters at roli?