Oh thanks for testing, I’ll take a look!
Solution for user-made presets?
Thanks again for making these changes so quickly. I tested this with an instrument you can find here: https://gitlab.com/RZ-FZJ/rz-cabbage-recipes. It seems to work without any problems. I even don’t have the ‘blinking problem’.
Win10 64-bit. The blinking problem is with the custom solution that @Retornz provided, and not the “named snapshot” mode.
The snapshot mode works great, but @rorywalsh is it possible to remove presets from the snapshot mode without going into notepad and editing the .snaps file? I think the consumer expects a simple way of removing presets, which was why I was leaning towards the custom solution.
I can take a look. Maybe a right-click on the preset to delete? I was working of the simplified zip that @Retornz posted. I didn’t try his more involved custom preset manager system.
Yeah that works, but maybe with a confirmation window so the user doesn’t accidently remove a preset?
I was also using the simplified one.
@hdale94, I got this sorted now, the flickering that is. I just have to look into another bug before I return to the removing presets ideas
I’m just looking into this now. It seems that I can’t access a right-click in a combo box without some serious reconstruction of the combobox widget. This leaves the option of modifying a filebutton to add a remove preset mode? It’s just about the only thing that will work for this?
Using a filebutton to remove presets is a nice way to do it yeah
I’ve just started a new build that will allow users to remove the currently selected preset by setting the mode() of a file button to ‘remove preset’. Here’s an example:
<Cabbage>
form caption("Presets") size(370, 280), colour(58, 110, 182), pluginid("MPre")
keyboard bounds(10, 90, 345, 95)
rslider bounds(12, 8, 85, 79), channel("att"), range(0, 1, 0.01), text("Att.")
rslider bounds(98, 8, 85, 79), channel("dec"), range(0, 1, 0.4), text("Dec.")
rslider bounds(184, 8, 85, 79), channel("sus"), range(0, 1, 0.7), text("Sus.")
rslider bounds(270, 8, 85, 79), channel("rel"), range(0, 1, 0.8), text("Rel.")
combobox bounds(74, 190, 100, 25), populate("*.snaps"), channeltype("string")
filebutton bounds(12, 190, 60, 25), text("Save"), populate("*.snaps", "test"), mode("named snapshot")
filebutton bounds(12, 220, 60, 25), text("Remove"), populate("*.snaps"), mode("remove preset")
</Cabbage>
Check it out and let me know if there are any issues. I also fixed that earlier bug.
When I export as a .vst, it doesn’t export the presets it seems like. Other than that it works nicely
Only thing I’m thinking of is perhaps the delete confirmation window visuals could match the save window for consistency, and maybe having a singular button for “no” or “cancel” as they kind of do the same thing yeah?
To have it export the presets use the bundle() identifier. I’ll update those other things when I get a chance. I’m not a fan of the popup boxes, and I think giving users the option to remove presets is a little dangerous, but the community has spoken on this one. I’ll take a back seat
I think it’s nice to be able to clean up the preset combobox when working on your own presets. If someone is working on a preset, he/she could be making some backup presets along the way. So then in the end you might want to remove the presets that now are unnecessary, and keep the final one
Very nice! Works perfectly
I think this will be very useful for a lot of people, and the fact that you can add this with only 3 lines in cabbage makes it so easy to integrate. Well done!
Sorry for disappearing on this… I’ve been busy working on some other stuff lately, often dual booted where I don’t have most of my tools (yet)
This looks fantastic! I can’t wait to try it out… great work Rory!
Thanks a lot! The named save and remove are working perfectly.
But you know, users are insatiable… What about a reset button which reverses all edits and returns to the preset as it was last saved. It is not too incovenient to load the current preset again from the combobox. But it would be a ‘nice to have’.
I tried to realise this from the csound code by having a combination of:
combobox bounds(74, 190, 100, 25), channel("pres"), populate("*.snaps"), channeltype("string")
and (for a first test just to return to a fixed preset “test”)
chnset "test", "pres"
But that just sets the combobox to “test” but does not effectively change to the preset named “test”.
You’re opening a pandora’s box there! Having a reset option would be a lot of work as it would involve keeping track of all edits. I’m not sure.
A preset combobox can’t be updated this way IIRC. I can test it myself, but I think I removed this because it would cause the plugin to enter into a state of endless recursion whereby the preset would be causing the combobox to update, which would also cause the plugin preset to be called, which would call the plugin combobox, etc
I will look at the code again and see if this is now possible. It might be, the preset code seems to be constantly changing!
Maybe there is a misunderstanding. I don’t propose to have undoing (which indeed would need keeping track of changes). What actually happens to me quite often is that I do several changes on a preset and don’t like the result. Rather I would like to start again from the preset as it was last written to file. What I have to do now is: Got to the combobox, chose some other preset just to force it loading, and then select the preset i was working on again to reload that. (If I just select the preset I loaded last it will not load again because it is already ‘check-marked’.) What I propose is to have the effect of this sequence on a button. (I think the RetornZ plugin has this feature.)
I see what you mean. This is tricky as the JUCE combobox widget doesn’t have a callback for selecting the same item. The callback only gets selected when you change items. I’ll have a think about it. it is kind of annoying though…