Dropdown Dropdown?

[AveAcsent]

Aah, alright. Does that mean UI is rendered with the gpu instead of cpu?

[rorywalsh]

In this instance no, but it is possible to offload to the GPU. For the simple widgets that Cabbage shows however there is very little gained in doing this. In my tests I saw no noticeable difference at all in performance.

[t_grey]

@rorywalsh - a couple questions on this:

Would numerical idicies work if:

#define $LPF items:1(“ButterLP”, “Tone”,“LPF 18”, “K35”, etc)
#define $HPF items:2(“ButterHP”, “Atone”, “K35”, etc)
#define $BPF items:3(“ButterBP”, etc)
#define $BRF items:4(“ButterBR”, etc) 

But you only used $BRF (text:4)? In other words, I assume it takes the index from the items declaration and not is location in the menu?

Similarly, if you used $HPF and then $LPF in that order, would they reorder numerically or appear in the order they were called? (just curious, not sure what I’d prefer on that honestly… will have to think about it)

@rorywalsh

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:

Would that problem be negated by the key pair idea, since each entry would have it’s final value paired and no “calculating” the index is needed? The more I think about it, the more I feel like this is the right direction to go for making a more complex submenu system…

But I need to keep thinking on it… it’s been a weird few days and I haven’t really had much focus on code.

[rorywalsh]

So I nearly have this implemented to use strings or numbers. In the end it doesn’t really matter what we use, because Cabbage will build the menu depending on where the text:…() appears in the declaration.

@t_grey

Would that problem be negated by the key pair idea, since each entry would have it’s final value paired and no “calculating” the index is needed? The more I think about it, the more I feel like this is the right direction to go for making a more complex submenu system…

I agree, but I think if we were to do this we would probably need to move away from the simple syntax of Cabbage and start using JSON/XML instead. It’s just too awkward with the current syntax. And I would rather not make it any more complex. In JSON things would be neater, but your Cabbage section would suddenly become 100s if not 1000s of lines long. But just for demo purposes, a simple multi-menu demo could be built doing something like this:

{
    "form": {
        "title": "example",
        "size": [400, 300]
    },
    "rslider" : {
        "bounds": [0, 0, 200, 200],
        "channel": "frequency"
        "range": [0, 1, 0, 1, .01] 
    },
    "combobox" : {
        "channel" : "newMenu",
        "items": {
            "Waves" : [[1, "Sine"], [2, "Square"], [3,"Tri"]]
            "Sounds" : [[10, "Awesome"], [11, "Mediocre"], [12, "Outstanding"]]
        }
    }
}

[t_grey]

@rorywalsh

So I nearly have this implemented to use strings or numbers. In the end it doesn’t really matter what we use, because Cabbage will build the menu depending on where the text:…() appears in the declaration.

That’s awesome! Do you think you’ll go the route of numbers, text, or either? I still prefer text because it allows the upper “index” to be descriptive and related to it’s contents. For example, with calling them, especially if the entries are defined as a macro in an included file, it’s much easier to remember items:lpf is the one i’m looking for vs items:3. I think either would work fine for me tho, just a loose preference.

@rorywalsh

I think if we were to do this we would probably need to move away from the simple syntax of Cabbage and start using JSON/XML instead. It’s just too awkward with the current syntax.

Ooof. No thanks on the JSON for the whole cabbage section. That looks like a major headache. The only way I could see that being realistic is if a new menu widget was created that uses/imports JSON files. Probably not gonna happen either, but just a thought.

So I guess now I just need to settle on a good way to convert the dynamic index place from the generated combobox into a correlated constant that matches everywhere in the code…

I’ll give it some more thought tomorrow… my brain is still on holiday for some reason.

[AveAcsent]

Hmm, the XML/JSON kinda reminds me of css. Maybe we could structure it like that?

Drop-down {
Bounds: 35, 32, 53, 30;
Items: item1, item2, item3; {
Item1: subitem 1, subitem 2;
Item3: subitem 1, subitem 2;
}
Colour: #3599db;
}

Edit: I’m on mobile so sorry for bad formatting. Maybe we could import code like that one adsr example?

[rorywalsh]

@AveAcsent

Maybe we could structure it like that?

My point about JSON/XML is that is gives much greater scope for complex configurations. But I wouldn’t add it for one widget. That would be a nightmare.

@t_grey

So I guess now I just need to settle on a good way to convert the dynamic index place from the generated combobox into a correlated constant that matches everywhere in the code…

I don’t follow. Can the indices not simply be assigned according to where the item:() identifiers appear in the combobox declaration? For me this is the simplest solution, and users can then use number or strings.

[t_grey]

@rorywalsh

I don’t follow. Can the indices not simply be assigned according to where the item:() identifiers appear in the combobox declaration?

What I meant was this:
items:lpf() on it’s own yields items starting at 1.

But in another instrument I might have items:hpf() before items:lpf(), so now lpf starts at something unknown, other than 1.

Like I said tho, it’s probably pretty trivial once my head’s wrapped around it… I’ve just been not having a good week or so when it comes to coding, my brain took an unexpected vacation without me.

[Retornz]

Also @AveAcsent keep in mind that JUCE Comboboxes “blinks” in LMMS when you try to click on them, that’s why I added some “handles” (just knobs links to the index of the Comboboxes) for LMMS user to be able to select waveforms, filters, etc… in ToneZ in LMMS

[rorywalsh]

I have this implemented now. The index of each item is determined by when it is added to the combobox.

[AveAcsent]

Wow… i dont even know what to say except thank you. its crazy that i only found cabbage in march, and some of my suggestions have already been put into cabbage… Thank you so much for adding this!

[rorywalsh]

It was a good suggestion It only works with numerical indices, which is Ok with me, because that’s what the host will get anyway in terms of parameter values.

[t_grey]

This looks awesome, can’t wait to try it out. Not quite sure how I’ll implement it yet… but it will definitely get used soon! I’m going to try overcomplicating it first… should really help clean up my ~40 entry menu for filters…

Is this available in the beta builds already?

[rorywalsh]

Should be in the latest beta build

[AveAcsent]

am i doing this right?

[rorywalsh]

What version of Cabbage is this? I merged some pull requests in the last week or so, perhaps my changes were lost. I’ll take a look later, your code looks fine to me.

[rorywalsh]

It’s working fine for me here? Can you try this build.

[AveAcsent]

according to the output console, im using 2.3.50. wtf. Im installing newest beta rn so ill let you know

[AveAcsent]

theres no windows installer

[rorywalsh]

Sorry, just trying new build now. The Windows build keeps getting stuck on something. Not sure what. It’s something to do with Azure.