Write and retrieve large number of programs in xml file by index or name


#1

Hi jucers,
I’m at the end of my vst plugin (a digital DSP emulator of an old rack DSP).
I have implemented the effects (thanks to C++ STK) and I have to set the 160 presets of that machine.
I need to store about 16 parameters per program.
But I’m completely new of this topic.
I know XML but I don’t know how to store in it an recall the preset programs…
Can anybody make me an example?


#2

You might want to use the ValueTree class internally and just export it to XML before writing the preset file (or simply write the binary ValueTree data if you don’t care about human readability.


#3

What about a separate class to handle the presets?
I’ve read a open source code for a chorus plugin (C++) and I’ve noticed that the parameters for each preset are stored in a an array…
This would make me get things more fast.


#4

Isn’t that exactly how the main audio plugin demo stores its state?


#5

I assume…but how can i build a XML so large?
(effectively I know HTML…)
can you send me a row ox XML and the methods that i have to use to retrieve them?


#6

A better solution is to use an AudioProcessorValueTreeState which enables automatic serialisation. The AudioProcessorValueTreeState tutorial shows you how to do this: https://www.juce.com/doc/tutorial_audio_processor_value_tree_state.


#7

Hello, I’ve set up the parameters with the AudioProcessorValueTreeState, but my GUI has not to be refreshed: it simulates a digital interface with a LCD monitor and a series of knobs that I will use for changing parameters, so I’ve not use any attachment.
Now how I store the presets?
And how I recall them?


#8

I’m afraid I don’t understand your last post. If you’re not refreshing your GUI, how are you going to change your knobs? And if your knobs change parameters why are you not using attachments?

Storing and recalling presets can be done in exactly the same way - save the state of your plug-in to XML, store it somewhere, then convert back to parameter values, GUI state and whatever else when required.


#9

The knobs are always rotating (auto stop parameter false).
I’m trying to emulate this:

http://it.audiofanzine.com/multi-effetto-per-chitarra-elettrica/rocktron/Intellifex-Ltd/medias/immagini/a.play,m.1413726.html

An old and famous DSP processor for guitar.
You should understand how it works: a display that contains the parameters the the user can change on the fly using the three knobs… so I don’t need to attach a value to the knobs, they rotate free till the user get in the display the value or parameter to change…
It’a a hard work effectively and I’m learning C++ on the way.
I think I’ll use objects to control the parameters in the display.
I have not clear idea of how I will but, as I said, I’m learning C++ on the way…
And with JUCE is a funny and cool way!

EDIT: It sounds with the ValueTree, only I need to store each state in a preset to be recalled even after the plugin is deallocated…


#10

Then you can simply save the XML to a file somewhere on disk, then load the file again to restore.

If you’re going to be changing parameter values via the GUI then I would strongly recommend using attachments. These deal with a lot of complicated synchronisation automatically and will save you a lot of pain. Add an attachment to every parameter and do setVisible (false) to hide the controls you don’t want and setVisible (true) to display the ones you want to see.


#11

No, we don’t understand… I need to have in place plugin presets that changes every serialized parameter (they are about 80). And need to recall them like the presets of cubase inner plugins but directly in the vet.
I think that the methods of AudioProcessor

int IntellifexAudioProcessor::getNumPrograms()
{
return 1; // NB: some hosts don’t cope very well if you tell them there are 0 programs,
// so this should be at least 1, even if you’re not really implementing programs.
}

int IntellifexAudioProcessor::getCurrentProgram()
{
return 0;
}

void IntellifexAudioProcessor::setCurrentProgram (int index)
{
}

const String IntellifexAudioProcessor::getProgramName (int index)
{
return String();
}

void IntellifexAudioProcessor::changeProgramName (int index, const String& newName)
{
}

are what I need…


#12

Is there any progress on this task? I’m now thinking of switching to using AudioProcessorValueTreeState or staying with the old (AudioProcessorParameter) approach with manual synchronization. But for a new way, I did not find an explicit demonstration of support for several presets / programs. I think I’ll have to abandon the idea of using the AudioProcessorValueTreeState if I need to maintain a list of presets by a vst/au-host.