Version 1.3.3 out

Yesterday I pushed out version 1.3.3 which includes many bugfixes.

The loading was broken in the previous version.

Removing the BinaryData switch broke the loading of images, so I had to bring back the config define FOLEYS_ENABLE_BINARY_DATA to activate the images from the Projucer BinaryData.

The examples are now built on github actions using cmake. That means you are free now to choose either the Projucer generated jucer files or the cmake of JUCE.

A new feature is, that there is a callback createGuiValueTree() you can override. The original version in MagicProcessor will populate with the generated version from the parameter tree and the MagicPlotSources it finds in the magicState.
Overriding this method allows you to come up with your own strategies to automatically generate a GUI procedurally or change only certain aspects like the stylesheet, colours or add your branding.

Also new is the possibility to use film strips for sliders:

An update is highly recommended.

Please let me know if there are any hickups.

1 Like

Thanks Daniel for that update, and especially for the filmsrip… I’m looking at the code rn, but can’t find how you actually declare an element in your project to be made available as a filmstrip in the dropdown menu of the gui builder ? I see some method to apply a filmstrip to a slider, but I think that’s internal stuff from PGM, not things I’m supposed to call directly ?

Thanks !

Glad you like it.
You add the Filmstrip images to the BinaryData via Projucer.
And remember to switch the FOLEYS_ENABLE_BINARY_DATA macro to enabled.

Once you resaved and recompiled the Filmstrip is available. In the Slider you can now select the image and you need to tell how many images there are in the Filmstrib image.
The example in the image above was made with knobman.

Hope that helps.

Perfect, thanks, apparently knobs should be vertical by default, is there a way to add a dropdown so as to select orientation as I already have made quite a bunch in that mode with knobman as well :wink: ? For now I’m reexporting in vertical some of them, no big deal :smiley:

Also I always have a (probably newbie) issue, with my layout not being saved, I have to save it as a file each time, and load it at startup ? The software is indicating it’s loading it from the binarydata, but that’s maybe not saved when I close the sw ?

Thanks !

I’m going to switch to the main branch!
Thank you @daniel <3

The drawing code is already in, I just didn’t add a config option yet.
I have to say there is a technical reason to prefer vertical strips, because each “frame” is close together in the memory. In horizontal, because the image is row based, each row is far away from the next row, so drawing a subset of a horizontal strip will be slower (probably not a problem in practice).

Previously the GUI was stored in the plugin state. But it was lost when you created a new instance. So it was easy to either test the wrong version or lose the work.

You can cose the editor without losing your changes, but if you close the standalone or remove the plugin from the DAW you will lose your changes.

An autosave in case disaster strikes is on my list to add soon.

To load your GUI tree override the callback createGuiValueTree(). But adding it in the constructor will continue to work.

Hope that helps