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
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:
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?
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.