So i was creating the mod matrix, and since there are so many paramaters that need modulation
the combobox just becomes a mess. Is there some way to make dropdown menus whithin combo boxes like in the mod matrix in plugins like serum, and spire?
sort of like this. Would this require a custom widget to be made?
There is no way of doing it at the moment, but I could look at extending the combobox widget to allow for this. I’m just thinking of how it might look in terms of syntax 
hmm, yeah. I tmight be a loittle long but im imagining something like this
combobox bounds(0, 0, 100, 40) text(“item1”, “item 2”, “item 3”, “item 4”) dropdown:1(“sub item 1”, “subitem 2”, subitem 3")
and that would result in a combobox with 4 items, with item 2 dropping down and containing 3 sub items. the colon an then the number wouold identify the item you want the dropdown to be on, and since computers start counting from 0, 1 would identify item 2
Yeah, that might work, but I would think the following might be simpler:
combobox bounds() text:1("Title1", "Item1", "Item2", "Item3"), text:2("Title2", "Item1", "Item2", "Item3")
Each item would still be given an integer ID, assigned through the order of their declaration. So Item2 of Title2 above would be 5.
The other option would be to create a new widget called menu.
Hmm yeah. that seems to make mrore sense. with this new system, if i were to just want a plain combobox i would do
combobox bounds() text:0(“item 1”) text:1(“item 2”) text:3(“item 3”) text:4(“item 4”)
if so that seems like it would make more sense. It might be a little bit longer, but the widget would be more flexible
Actually for a regular combobox the syntax would remain the same as now:
combobox text("Item1", "Item2", etc)
That way we don’t break all the other instruments out there using comboboxes.
Isn’t items() the current norm for combobox?
Yeah sorry, items(), but text also works 
I really like this idea… but you know me, I’d like to see if it could be a little more “portable” for macros or otherwise.
For example, I’d like to be able to have a few premade submenus that are somehow “number agnostic”, so perhaps that text:x the numerical part is possibly replaced by another text string instead?
Like:
#define $LPF text:lpf(“ButterLP”, “Tone”,“LPF 18”, “K35”, etc)
#define $HPF text:hpf(“ButterHP”, “Atone”, “K35”, etc)
And then when I make a combobox I could use either or, or both depending on the particular use case… so then when using it would look like:
combobox bounds() channel(“filter”) $LPF $HPF
Hopefully that makes sense, but I think that could make for some flexible and powerful additions!
Or you know, items:lpf() and items:hpf(), either way
hmm, i think that could be good. Would that be saving them as strings? because if i think about this, i think the data put out in the channel through numbers would probably be messy. like the string would be “hpf:k35” or something, of the likes. Im not sure about numbers though maybe something like 2:4? im not sure
I’ll be honest, this was a half baked idea I had before even finishing my “morning” coffee… so I hadn’t thought it out that far ahead. Comboboxes can pass strings, but yeah… since they might have spaces or special characters, that could get really messy to parse in the actual logic part.
Just spitballing on the idea, what if instead of extending comboboxes, this were a new menu/submenu widget that acted differently? If it had index/name value pairs similar to Blue’s dropdowns you could do something like this:
#define $LPF text:lpf(“Butter LP”, 1, “Tone”, 2, “LPF 18”, 3, “K35”, 4, etc)
#define $HPF text:hpf(“Butter HP”, 5, “Atone”, 6, “K35”, 7, etc)
I think that would probably end up being more portable and allows human readable names without having the headache of parsing the text into a value? Plus there’s no worry of messing up existing comboboxes. In the end combobox stays as a simple widget for just straightforward dropdown values, but the new one could be considered a much more extensive “menu system” designed with some of these problems in mind?
I was thinking of using numbers so that it’s easier to identify the index of corresponding items. item:lfp() could appear anywhere in a list and you’ll have to count identifiers to figure out which submenu index to use. For example, try to figure out the index of item3 in lpf:hzx() in this line:
combobox bounds() channel(“filter”) text:hpa(“ButterHP”, “Atone”, “K35”), text:hpp(“ButterHP”, “Atone”, “K35”), text:hpn(“ButterHP”, “Atone”, “K35”), text:hpd(“ButterHP”, “Atone”, “K35”), text:hpe(“ButterHP”, “Atone”, “K35”), text:hpf(“ButterHP”, “Atone”, “K35”), text:hpg(“ButterHP”, “Atone”, “K35”), text:hpx(“ButterHP”, “Atone”, “K35”), text:hpf(“ButterHP”, “Atone”, “K35”)
With numbers you need only multiply the number of items by the index of the submenu.
Something like this would be a bit of work to implement, although I agree that some kind of value-string pair would be nice.
I’ll take a look and see if the combobox can be tweaked, if not I’ll create a new menu widget.
I took a look at the JUCE code base now and it looks like it shouldn’t be tricky to add sub menus to comboboxes.
I had implemented a larger menu type system before that never made public release. It worked Ok, but I think it’s too much for a framework like this. If you want to have a native style menubar for your apps, I think you are better off writing your apps in C++ from the ground up. Cabbage will never be able to compete with a proper GUI framework like JUCE or QT.
i mean, yeah, its pretty obvious that cabbage won’t be able to come close to those gui’s, but with what we have now, it isnt as bad as most of the gui’s made in stuff like synthedit or reaktor. I feel like maybe just some specific widgets would make cabbage feel more professinal. like maybe a sub-menu widget like we were talking about, and maybe some other stuff that would make workflow cleaner (Drag/drop modulations?) but cabbage is already great in of itself. Gui’s are something that are really preferencial. With enough work, you can get the gui you want.
edit: Would it be possible to USE a rendering engine with Csound?
What do you mean exactly when you say rendering engine?
Like a piece of software that i can use to generate the ui rather than using it built-in to the editor? i was just curious like Qt is to JUCE
You can use Photoshop to create your UI?
Yeah, i can create the ui in editing software, i was just wandering if a UI rendering engine was a thing for Csound
Cabbage renders its UI using the operating system’s graphics engine. I looked at adding support for OpenGL but then Apple announced it was dropping it so I didn’t feel like supporting a feature on only one system.
