Will definitely work with comboboxes. The reason I’ve been trying to avoid using them is because if you end up with several comboboxes, the user will have to click double the amount of times to change them, which I suspect may change/worsen the user experience (if that makes sense?). Obviously, for a big list of items a combobox is better suited, but a 3-state button I think definitely is nice and feels encouraging to click.
“optionbutton” is nice yeah!
Okey so it works nicely, but I have a question. If I change the channelname of a widget, how will this affect the .snaps presets?
Don’t ever change the channel name of a widget. That’s tied to the host and fixed in stone. Or wait, you don’t mean dynamically? Ok, if you change it in the .csd file you will need to update the .snaps file. It’s just xml text. It should be pretty clear what you have to change.
Yes, I’ve looked inside the .snaps file. I’m talking about the channel identifier: channel(“Test1”). If I make a preset with a widget using channel: “Test1”, but then I want to change the identifier inside Cabbage to “Gain” instead. I also need to change the presets inside the .snaps file for it to be compatible correct?
Not talking about dynamically no, just the predefined channel identifier.
Correct. A quick search and replace in a code code editor should do the trick 
I’ve added an optionbutton. You can take it for a twirl when you get the chance. You can create one much in the same way you would a combobox:
optionbutton bounds(10, 10, 100, 40), text("One", "Two", "Three"), value(0), channel("options")
I’ve tested channel communcation and it’s working fine, both with chnset, and chnget. I haven’t put it into a preset example yet. I’ll let you look into that. Let me know if it passes your tests. I’ve pushed the change to Azure. The build should be ready in a bit.
Nice!!! Will test it when it’s on Azure
There seems to have occured a staging error or something?
Something I noticed (unrelated to the button), I can’t run PresetsNamed.csd example anymore, and (not sure about this) I think it’s because it’s looking for a .snaps file. Same thing happened with my plugin when I moved the .snaps file into another folder, it just crashed Cabbage.
Also something else I noticed, which I don’t know if it has any effect on anything. If you f. example create a preset “Test1”, a preset “Test2”, and then overwrite “Test1” with the information in “Test2”, it will cause this to happen to the the preset “Test1” inside the .snaps file:
PresetName="Test1" cabbageJSONData="" combochan="Test2"
Thanks, I’ll take a look
Of course. I forgot to update the plugins projects with the new optionsbutton widget 
Sorry, I’ll do that now.
I wouldn’t pay too much attention to the combochan as it’s ignored by the host. I just tried this myself, and while it successfully overwrote my earlier preset, the combobox didn’t jump to the most recently written preset. That should happen. Let me take a look…
You should be good to try the latest build now when you get a chance. I sorted those other issues too. I’m not sure we’re out of the woods yet in terms of the latest features, but we’re getting closer all the time!
Works perfectly! All I had to do was change the combobox with optionbutton, change the if-statements to check from index 0 and up instead of 1 and up, change the button-value inside the .snaps file to 1 less, and then export to .vst again. Very seamless implementation Rory . It also works as expected with the preset system, so I’m very happy 
That’s good to hear. If you get a chance, can you check how it behaves with host automation? I didn’t try automating that widget from within a host yet. Would be good to know it behaves well there…
Ok then right?
Yep, it changes back to the first state before reaching max-value in FL, but it definitely works fine, both visually and functionality-wise
I think it’s just the way it get mapped in the host. I think comboboxes behave the same 
