Using AudioProcessorValueTreeState class to create synth presets?

General JUCE discussion
1

I was was wondering whether the AudioProcessorValueTreeState class could be used to create a bank of synth presets? I figured it might provide a convenient route to coding up a bank of preset patches for a synthesizer.

2

Bump! I would also like to know how this is done. Or is there any existing tutorial how to properly add presets when compiling (let’s say a separate function with createMyPresets())

I have a reverb plugin and I’d like to add some presets for different instruments. Easiest way would be to create these with my DAW but I can’t really find any information regarding this. Reaper.rpp, when opened with texteditor gives my plugin this kind of saved state information:

<VST “VST3: VerbName (yourcompany)” VerbName.vst3 0 “” 2078240123{ABCDEF019182FAEB4D616E75556E6E38}
e23fe+5e7f4CAAAAAQAAAAAAAAACAAAAAAAAAAIAAAABAAAAAAAAAAIAAAAAAAAAUwIAAAEAAAD//xAA
QwIAAAEAAABWQzIh/gEAADxQQVJBTUVURVJTPjxQQVJBTSBpZD0icmV2Q0ZCX2lkIiB2YWx1ZT0iLTYuMDAwMDAwMDAwMDAwMDAwMDAwMDAiLz48UEFSQU0gaWQ9InJl
dl9kaXN0YW5jZV9pZCIgdmFsdWU9IjEuMTQ5OTk5OTc2MTU4MTQyMDg5ODQiLz48UEFSQU0gaWQ9InJldl9mYmZpbHRlcl9oaWN1dF9pZCIgdmFsdWU9IjIwLjAwMDAw
MDAwMDAwMDAwMDAwMDAwIi8+PFBBUkFNIGlkPSJyZXZfZmJmaWx0ZXJfbG93Y3V0X2lkIiB2YWx1ZT0iNDAwMC4wMDAwMDAwMDAwMDAwMDAwMDAwMCIvPjxQQVJBTSBp
ZD0icmV2ZWJfZGVsYXkyX2lkIiB2YWx1ZT0iMC4wMDAwMDAwMDAwMDAwMDAwMDAwMCIvPjxQQVJBTSBpZD0icmV2ZWJfZGVsYXlfaWQiIHZhbHVlPSIxMjUuMDAwMDA3
NjI5Mzk0NTMxMjUwMDAiLz48UEFSQU0gaWQ9InJldmVyYnRpbWVfaWQiIHZhbHVlPSIwLjUwMDAwMDAwMDAwMDAwMDAwMDAwIi8+PFBBUkFNIGlkPSJyZXZtaXhfaWQi
IHZhbHVlPSIwLjUwMDAwMDAwMDAwMDAwMDAwMDAwIi8+PC9QQVJBTUVURVJTPgAAAAAAAAAAAEpVQ0VQcml2YXRlRGF0YQABAUJ5cGFzcwABAQMAHQAAAAAAAABKVUNF
UHJpdmF0ZURhdGEAAAAAAAAAAA==
AAAQAAAA
>

3

hi there @shossa3 , the AudioProcessorValueTreeState backbone is a ValueTree, which in the words of the JUCE powers that be can be thought about as a “Living XML”. Every time a parameter changes the ValueTree representation changes and all the listeners get to know about the change.

So getting the XML string representation of that ValueTree means to “freeze the living XML”, and saving it somewhere is actually the act of saving a preset.

Here’s something you can do :

Phase I : you save one to memory and get it back next time you open the plugin. That’s the nice feature that makes all yer knobs and sliders be at the same position you left them in your plugin when you closed the DAW…

// header definition: AudioProcessorValueTreeState pluginState;
void AudioProcessor::getStateInformation(MemoryBlock &destData)
{
ScopedPointer<XmlElement> xml(pluginState.state.createXml()); // .state is the ValueTree
copyXmlToBinary (*xml, destData);
}

void AudioProcessor::setStateInformation( const void *data, int sizeInBytes)
{
ScopedPointer<XmlElement> xmlState (getXmlFromBinary (data, sizeInBytes));
if (xmlState != nullptr )
{
pluginState.state = ValueTree::fromXml(*xmlState);
}
}

Phase II: you save one to disk.

that ScopedPointer<XmlElement> xml(pluginState.state.createXml()); gets saved to a file instead
You also create a cross platform path and save your XMLs with the plugin preset extension of your choice, make a nice menu with submenus following the subfolders etc etc

Phase III: you keep in memory a second version of the ValueTree XML

That’s that magical A/B-ing presets of the big guns VST devs
Every time you to A/B you switch the background XML into the “living XML” and vice versa

Phase IV: world domination …one of the many forms of it : before pushing an XML snapshot into the “living XML” you set up a class that goes through the params and blocks some from changing (the famous “Mix Lock”)

That’s all I can think of ATM - I’m sure there’s a lot more you can do preset-wise starting from the AudioProcessorValueTreeState…

4

For example the Reaper base64 encoded plugin state data isn’t officially documented and supported for 3rd parties to deal with. It contains other data besides the plugin state itself. So you shouldn’t really use that as a starting point.

Maybe you could add a feature in your plugin that is only active in debug builds that allows you to dump your state data into some form you could for example paste into your source code…?

5

Thanks. This seems the most reasonable solution. I’ll try it when I have the time.

6

Keep in mind we’ve been talking of two different things in this thread.
Presets saved using the xml representation of ValueTree are 100% “proprietary” (which is what a lot of vendors do anyway)
Presets saved using the DAW features are “somewhat proprietary”, since they are probably a mix of the original “vst preset” and “vstbank” preset spec (I am totally ignorant of the .AU counterpart but there’s probably one)
… mixed with some additional DAW specific stuff as @Xenakios mentioned above for reaper.

7

EDIT!!: Okay a stupid mistake. Apparently Windows path “” should be replaced with “/”. Now I have the xml file created when calling the function from setStateInformation.

Hello. Yea it seems I’m a bit lost on this one. (Last time I actually used write/read streams was in a basic C course about 6 years ago. I’m now debugging with Reaper to trigger the :setStateInformation() function. I’ve tried to use the “XmlElement::writeToFile” property, and even while it returns “true”, no file is created to described location.

void myPlugin::setStateInformation (const void* data, int sizeInBytes)
{
// You should use this method to restore your parameters from this memory block,
// whose contents will have been created by the getStateInformation() call.
std::unique_ptr savedParams(getXmlFromBinary(data, sizeInBytes));
std::unique_ptr savedParams2(getXmlFromBinary(data, sizeInBytes));
const::juce::File saveFile(“D:\JUCE\projects\myProject\preset1.xml”);

if (savedParams != nullptr)
{
	if (savedParams->hasTagName(tree.state.getType()));
	{
		tree.state = ValueTree::fromXml(*savedParams);
		bool saved = savedParams2->writeToFile(saveFile,String(),"UTF-8",60);
		//String myPreset = savedParams2->createDocument(String());
		
	}
}

}

8

In the code in your post you’re saving the state to file inside the setStateInformation method. Watch out that it’s the host and only the host to decide when to call that method, so if you want to have your own presets saved at will you need to trigger that save to file operation in a dedicated method. The trigger might then be your “pluginEditor->presetToolbar->SavePresetButton->OnClick()”.

9

Any advice about when exactly to do that preset switch (e.g. when user loads another one) regarding the APVTS? Intuitively, I don’t feel like the editor should be able to trigger an instant change to the processor (the processBlock() method could possibly be ran at the same time, right?). I’m more thinking of a way for the editor to put the new APVTS from the new preset on hold, and notify the processor to switch it. Would at the very beginning of the processBlock() method be a good choice?