Cabbage Logo
Back to Cabbage Site

Presets...once again

Thanks for the info @rorywalsh :+1:
After compiling this dev tip, I have made a summary of the last tests with guiMode (“queue”):

  • Resize:
    AU, VST, VST3, open, close, plugin and session, everything is memorized and without the need to play audio, Ok!

  • Presets:
    Now on Mac, the external folder is recognized correctly. Developer name no longer contains spaces.
    Also now, you can save all the parameters without the need to be playing audio.

I don’t know if I forget something with Mac. Windows is next… :face_with_monocle:

1 Like

@rorywalsh. Before I start looking into this, is there an ignore tag for certain widgets for saving presets?
If you point me to where the xml parser for presets is in cabbage I can experiment with adding this feature as I assume it would just look for a tag in a widget and then not write / delete the data for that entry.

Not with the current system, but it would be easy to add. btw, you’re late to the party. We’re using JSON for presets now, as of about a week ago! I got so sick of XML. What should we call the identifier? presetIgnore(val) where it’s set to 0 by default, and a 1 will cause it to be skipped. Is this something that we should also use for when a host is saving a session, or is that bit much?

Great, JSON is much better than XML in my opinion. presetIgnore sounds great as a name. I think it would be most intuitive for the flag to block any sort of preset storage at least using cabbage. It would also make sense in a DAW, but that as you said may be a bit much.

I can add this tomorrow. Yeah, I think people might somehow get frustrated if they see parameters are not being saved on the DAW side? Sounds like a lot of calls to customer support wondering what the hell is going on with slider x :rofl:

I’ve added this now.

1 Like

I have observed in this last 2.5.38 dev tip, that when you go to delete a preset, and you say no, it deletes it anyway.

Thanks @gerbo. I’ll fix that now!

Actually, I can’t recreate this? I’m testing in the editor. I’ll try in plugin mode and see if I can recreate the issue there…

Well, it happens to me in the IDE, however, a moment ago I tried it in pluin and it works fine.
One thing … How good that now there is no problem that user presets scale the list of those that are protected. It was something I wanted to tell you, but I see that it is already solved. A 10! :+1:

Yes, @hdale94 and I saw this was going to be an issue earlier on today! We beat you to it!

I think I see the issue now. Let me dig a little deeper…

…yes, when the plugin first loads and you try to delete the default preset, even though it is protected, Cabbage asks are you sure you want to delete it. If you hit Ok it doesn’t actually delete it, but it looks like it does. Of course it should give you the option to even think you can delete it. I’ll fix that now.

Yes, exactly. The first time it asks as if it were an unprotected preset. The following times he already acts normally.

Fixed now in git :+1:

The tests for me give a correct result. A sensational job :+1:

One last thing to check, @hdale94 reports an issue with the resizing features and the presets in his latest creation. I’m just checking this now, but we’re certainly close!

[edit] Indeed there was a strange issue with the plugin resizer settings being saved in presets. This is fixed now in git.

I do not understand…
You mean that the resize was not saved in the preset?
I am in a project with all this and I have not detected anything strange with the resizing and the presets.
For now I’m only with Mac.

I think it might have been particular to an older preset file. But it’s all good now. We don’t want the plugin size to be saved as part of a preset. I think this is something only the host should save.

Right now I have finished this last test, and on Mac everything OK!
If there is already a bank of presets made with the previous version, which have saved the size change, they can be recovered by deleting from the JSON file, the line corresponding to the resize parameter.

Tomorrow we will test on Windows …
Thanks @rorywalsh :wink:

1 Like

Hello @rorywalsh,
I have observed that VST and VST3, when you move any control with the audio in motion and save the session, when reopening, the list of presets returns to the beginning (It happens in all hosts)

Studio One:

  • VST, write and save internal host presets

  • VST3, does not write and does not save (this worked fine in 2.5.38)

  • AU, for now it is not giving problems and works fine on all hosts.

Thanks @Gerbo. I’ve noticed some other small issues with VST3 in the past week or so. Looks like I need to spend some time there…