Cabbage Logo
Back to Cabbage Site

Presets...once again

#1

@hdale94, @Gerbo The current preset system is hanging on by a thread :rofl: 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!

#2

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

#3

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.

#4

presets
presets733×333 59.9 KB

These tests are being done without the channelType (“string”)

#5

@Gerbo

I exported from Cabbage v. 2.5.36. Is this also the one your on? What do you mean the parameters are altered? The numbers in the .snaps file?

#6

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!

#7

In the .snaps file, the names must be identical for its correct operation. For example:
PresetName = “Guitar 1” CurrentPresetName = “Guitar 1” PluginPresetCombBox = “Guitar 1”

Do the test.

#8

Ah yes I notice it now.

SnapsPresets

#9

Thanks to you as always.

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?

#10

Yes, that’s a good idea.

#11

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.

2021-04-20 15.10.42
2021-04-20 15.10.42873×597 276 KB

  • 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.

#12

Great job and placing the .snaps file in another folder on macOS is a great addition. I will test it later today :+1:

#13

Congratulations because this is looking great :wink:

  • 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.

That’s all for now

#14

Cabbage seems to crash when I run the plugin .csd in Windows. Also when I run the preset example it also crashes.

#15

Thanks guys. I really appreciate you both taking the time to test these. I’m be working on them again tomorrow. :+1:

#16

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.

#17

protectedItems (3), behaves as expected. A good idea to protect non-user presets :+1:

I am testing some of the modes:
(file, save, directory), but the answer for now is not favorable.

#18

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. :grimacing:

#19

This should be fixed now. I had forgotten to remove from #ifdef WINDOWS things.

#20

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…