Workflow for making GUI changes, recompiling, reloading

Adam · 14 February 2022 06:13

Loving PGM so far, thank you for creating this wonderful tool!

One thing I’m not catching though is how to have my GUI layout changes “stick” between compilation cycles.

I have saved my magic.xml file and added it as a resource to my Projuicer project, and have set FOLEYS_ENABLE_BINARY_DATA to ‘Enabled’. I have added the line magicState.setGuiValueTree(BinaryData::magic_xml, BinaryData::magic_xmlSize) to my AudioProcessor constructor, as well as FOLEYS_SET_SOURCE_PATH(FILE). Everything loads fine the first time, however I find that when I subsequently make changes to my GUI, quit the plugin host, recompile, and reload, my changes don’t stick. I have to manually do a ‘Load XML’ every time. I’m assuming I’m missing something important here but I can’t seem to figure out what it is.

jos · 14 February 2022 22:44

You also have to regenerate the BinaryData in your source by re-exporting your project from Projucer, which then remakes it from the modified XML. Kind of a pain I know…

Adam · 15 February 2022 21:53

Thanks for the reply. I did notice that, and am using that as a workaround, but I was expecting that once Xcode has the XML in its project as a resource that it would know to compile that in. I can see the XML (in the Xcode project) updating as I make GUI edits… It seems like the new XML changes should just get sucked in to the plugin binary once it’s included in the project. Hopefully Daniel will chime in.

daniel · 16 February 2022 10:56

Hi @Adam, it is indeed like described. The Projucer (or Cmake juceaide) are responsible to recreate the BinaryData sources and headers.
Since they will go into the sources, there is no way without recompiling.

There is an alternative, you can load the ValueTree from file as well, for instance in the FoleysSynth example I allow the user to place their own magic.xml into the bundle:

github.com

ffAudio/PluginGuiMagic/blob/main/examples/FoleysSynth/Source/PluginProcessor.cpp#L39


      
                                      .withOutput ("Output", juce::AudioChannelSet::stereo(), true)),
              treeState (*this, nullptr, ProjectInfo::projectName, createParameterLayout())
          {
              FOLEYS_SET_SOURCE_PATH (__FILE__);
          
              auto file = juce::File::getSpecialLocation (juce::File::currentApplicationFile)
                  .getChildFile ("Contents")
                  .getChildFile ("Resources")
                  .getChildFile ("magic.xml");
          
              if (file.existsAsFile())
                  magicState.setGuiValueTree (file);
              else
                  magicState.setGuiValueTree (BinaryData::magic_xml, BinaryData::magic_xmlSize);
          
              // MAGIC GUI: add a meter at the output
              outputMeter  = magicState.createAndAddObject<foleys::MagicLevelSource>("output");
              oscilloscope = magicState.createAndAddObject<foleys::MagicOscilloscope>("waveform");
          
              analyser     = magicState.createAndAddObject<foleys::MagicAnalyser>("analyser");
              magicState.addBackgroundProcessing (analyser);

But of course that would make deployment more fragile, so for the released plugin I would still recommend the BinaryData approach.

It might be that Cmake sets the dependency to the files inside the BinaryData and recreates the files automatically, but that would only work out of the box if the IDE evaluates the cmake file as well, e.g. CLion.

Adam · 16 February 2022 20:48

Thank you @daniel, that’s workable. I wrote up something as an enhancement request around this issue but deleted it because it’s not really that important.