I’m rewriting a plugin I originally wrote using VST.NET/Syntage, and immediately ran into a potential problem…
My plugin has multiple generators, and each generator has their own individual set of controls for osc type, noise generation, amp envelope, and a 64-sample custom waveform editor. It also has a few LFOs and a mod matrix. Back in VST.NET, I could create a custom WPF UserControl, and layout all of the controls for an individual voice/assignment/whatever. Then I could just add one instance of this custom control for each repeated component, and bind them to the appropriate model object so the parameters all got assigned appropriately.
Ignoring all of the binding stuff, I’m trying to start simple. Just a reusable control with its own layout that I can create multiple instances of. I can’t find any way to do this, though. Even the paraEQ example, which would be a perfect opportunity for reusable controls given all of the control points, seems to have all of its UI manually defined for each control point.
The only way I can find to create reusable components is to… write them programmatically, in plain-old regular JUCE component code. But so much of my plugin’s UI is componentized, that this would completely defeat the purpose of using PGM.
The GUI views are highly reusable. In the Editor in Edit mode, you can use copy/paste and drag/drop. I find it most reliable to do this in the hierarchical view on the left. I also frequently edit the .xml file directly as a text file. It is easy to bring in complex widget assemblies from another project, for example, or copy/paste a view group repeatedly and edit the knob-numbers afterwards, etc. It’s all quite modular and easy to work with.
Yes, that is exactly how it is intended to be used.
PluginGuiMagic allows to wrap arbitrary Components into GuiItems like to be seen in the ExtendingExample.
But I totally agree with @Chami that creating panels now and wrap those would defeat the purpose.
For editing @jos described the workflow very well. It should be noted that you can also manipulate the ValueTree at runtime. So it would be perfectly possible to add an arbitrary amount of similar ValueTree nodes or subtrees and the GUI would adapt automatically thanks to the ValueTree::Listeners.
I was contemplating a system where you could supply a template tree and similar to jQuery/Ajax and multiple instances of that tree would appear connected to specific data, but I am not done with thinking how that should work. Especially how it would bind to different data is not yet clear how to make it useful and not creating a monster.
I am open for input…
P.S. and of course I should mention the createGuiValueTree callback. This will be called and can create a generic GUI from various information. A default implementation exists that will create a tree according to the ParameterGroups and a plot window with all PlotSources the user added to the MagicGuiState.
