Cabbage Logo
Back to Cabbage Site

Presets...once again

#42

Hello,
I see that there is a lot of homework ahead and you want to make me sweat :sweat_smile:

I’m updating a project with the new guiMode (“queue”) mode, to test as reliably as possible.

v2.5.37 (1ce6df5)

  • protectedItems (3), should be activated after saving user presets. If it is activated from the beginning, and you want to memorize any preset, the plugin or the Cabbage IDE closes.

  • VST2 and VST3, have trouble recognizing the external presets folder because the developer’s name appears as:
    “CabbageAudio te” (until reaching “te” there are 4 spaces) If this defect is emulated, the external presets are recognized.

  • filmsStrip has now changed to filmstrip

  • Now Logic and Cubase memorize presets without moving audio :+1:

I think this watercolor is being precious :wink:

#43

I knew you’d find an issue if there was one!

That’s obviously not right, although activating them after you create them is a good idea. I will sort the bug and prevent any crashes.

That’s odd. I’m not seeing that issue here? Maybe you need to do a clean build? Or are you testing from the beta version in Azure?

#44

This is what I get on Reaper Mac.
reaper-fx
That’s why when I create the presets folder in the user library, emulating what appears on the screen, I can read them.

In AU, there is no such problem. Only in VST2 and 3.

#45

Thanks @gerbo, can you confirm this is not with your own build but with the latest beta from Azure?

#46

This was with my own Git build.
This new test is already with azure and something similar happens because the distance that remains when closing parentheses is also 4 spaces.
reaper-azure
I have to do the same in Library / CabbageAudio , leave those 4 spaces, so that the list of presets appears in the plugin.

#47

I know what’s happening there now. The Projucer fields have extra white space in them. I’ll fix that tomorrow. Thanks again for checking.

#48

When I override CabbageEffectNam and replace them with the plugin name, everything works fine in VST and without spaces. Now the external presets are recognized correctly.

Thanks to you Rory :+1:

#49

Thanks @Gerbo. That confirms the problem. I need to removing those trailing spaces. When Cabbage exports, it searches the binary for this string and replaces it. It’s obviously only finding part of it at the moment, which is causing those weird problems.

#50

This is fixed now in GIT.
Screen Shot 2021-04-23 at 10.46.05

Note there is still some extra whitespaces after the plugin name. Cabbage changes the plugin name each time it exports. To do this it must search through the plugin binary for a 16 char long generic name. When it finds it, it replaces it with the desired plugin name. If the plugin name is shorter than 16 chars I replace the rest of the 16 char memory location with white spaces. If the plugin name is longer than 16 chars it will be truncated. There is no other way to do this without compiling a new version of Cabbage for every plugin.

#51

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
#52

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

#53

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?

#54

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.

#55

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:

#56

I’ve added this now.

1 Like
#57

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.

#58

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…

#59

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:

#60

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

#61

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.