Yes, @hdale94 and I saw this was going to be an issue earlier on today! We beat you to it!
Presets...once again
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 
The tests for me give a correct result. A sensational job
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 
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…
How do you spot these things 
You have the eyes of a hawk 
This is fixed in GIT now. I’ll move on to the other issues now…
Is this particular to Studio One? I first tried running a VST3 in Reaper and I a warning message in the debugger about the channel configurations. So I added a condition for VST3. After this, the VST3 plugins seemed to work fine. I testing in Studio One and sessions and presets are being saved as expected. I’ll run off a new build now.
Ok, I’ll do the tests again, to be able to confirm
This is what I was referring to, by pinning the presets in Studio One.
- VST, write presets
- VST3, no.
The plugin presets work correctly.
And counting that my eyesight is exhausted 
and age does not forgive 
Hmm, that’s an interesting one. This is not something I’ve ever tested. Does this work ok in other hosts? I know reaper let’s you save presets from the plugin window but I’ve never tried it…
I just tested here now with the PresetNamed.csd example and I’m not able to recreate your issues?
I wonder is there I might be doing that is different to you? I also tested with the preset save in Reaper and it works fine there too.
This version 2.5.41 with which I am doing the tests, they are with the git files.
I need the same version, already built by you. In OneDrive I only have the version for Mac. It would be the public version for Windows with which you are doing your tests,
I am also doing them with PresetNamed.csd.
Now I have realized it when I saw the apple in your video.
On Mac it works fine, it is on Studio One Windows where the problem arises.