@hdale94, @Gerbo The current preset system is hanging on by a thread I think it’s high time I rewrote it. In the meantime, i just pushed through some changes that should ensure they work fine for now. But you must make sure that you don’t set channelType("string") This is creating havoc with them at the minute, so best leave that out for now.
In my tests with the code I just pushed I can:
add presets in the usual way, be they named or generic presets
close and reopen the plugin windows without anything changing - both preset combo, and parameters are in the same position
save and reopen the entire session with the correct settings
open a session, don’t move the preset combo, make a change and then reopen with the same combobox position - before today’s fix, this would always cause the combo to return to the first item.
If any of these steps fails for you please let me know. In the mean time I need to plan a complete redesign of this system. It’s not in great shape!
So I tried it now. It stored the correct values when saving a project, closing the DAW (FL Studio), and then reopening. However the name of the preset combobox changed back to the first on the list (init for me)
I did a export from the newest beta-version of Cabbage
I observe that the parameters of the presets are altered and what they save is not real.
I have corrected all the presets except (5555) and it is observed that it includes the numbering of the previous preset. When corrected manually, they behave correctly.
Thanks for testing this guys. I think I will just have to bite the bullet and rewrite this code. This will take a day or two at the least. It’s long overdue. The preset code is quite old, and I’ve been adding things to sticky tape to it for quite some time.
Don’t worry, I don’t plan to change how it functions, I just want to make sure it actually functions like it is supposed to!
In the .snaps file, the names must be identical for its correct operation. For example:
PresetName = “Guitar 1” CurrentPresetName = “Guitar 1” PluginPresetCombBox = “Guitar 1”
Could it be implemented on Mac, that the presets could be in an external folder? For example, when the user saves them within the plugin, they are lost when an update is installed.
Would it be possible?
Ok, I think I have this working now. Of course I’ll need your help in testing!
Here’s the current state of things:
All preset comboboxes have their channelType() set to “string” - Cabbage does this automatically, adn will override another else you might add. The channel assigned can be used to query which preset is currently selected - but this cannot be dynamically update via a chnset.
Cabbage will always search for preset files in the following locations, in order of precedence (replace CabbageAudio with company name if using pro version of Cabbage): Windows:
C:/User/AppData/Roaming/CabbageAudio/PluginName/ (read and write access)
C:/ProgramData/CabbageAudio/PluginName/ (likely to be read only access)
The same folder as the .csd file. (write permissions will depend on the location)
MacOS:
~/Library/CabbageAudio/PluginName/ (read and write access)
The same folder as the .csd, most likely inside the plugin bundle. Presets in this location typically have read and write access
There is a new identifier protectedItems() that can be used to prevent users from overwriting or removing certain presets. It takes an index. Anything above this index can be removed. For example protectedItems(3) will protect the first 3 presets.
When a session is saved in a DAW, the current preset name will be saved to the session file. When the session is reopened, the preset name will be set, but it will not trigger any controls to change. Doing so would override the saved session state and make saving plugin states with presets completely useless.
These changes are now in GIT and will be available in Azure shortly. Please give them a test and let me know.
The presets within the plugin package work perfectly, but it has not been possible to read them in the external folder. I assumed that you could select the directory to house the presets there.
The plugin doesn’t look at the default directory: ~ / Library / CabbageAudio / PluginName / (I’m not in pro for now)
I forgot that in Reaper, in these latest versions it appears as a developer (CabbageAudio te), as if it were a small piece of code.
In Logic and Cubase, the audio has to be running for the entire preset to be saved. With the audio stopped, the preset name is written, but the parameters are not saved.
This is happening when you read the old format of a “snaps” file. The safest thing is that when you delete the file “snaps” it will work again.
Take the test, because on Mac it usually happens too.
I neglected to mention that old preset files are not compatible with the new format. However, it still shouldn’t crash. One of the biggest pains about the old system was that it used XML. The new system uses JSON which means that old presets will need to be updated to the new system.
Sorry about this, but I regretted using XML from day one and I’m very happy to get rid of it.
I’m having some difficulty in recreate this. Take a look at this, I’m I missing something? It seems that when I save a new preset (test 5), the sliders positions are saved, along with the preset name. I then saved that session, reopened and found everything where it should be. I will try with Logic now.
[edit] I see the problem in Logic. Looking into it now…
I think it’s high time I rewrote it. In the meantime, i just pushed through some changes that should ensure they work fine for now. But you must make sure that you don’t set 
