Cabbage Logo
Back to Cabbage Site

Idea: interactive(BOOL) setting for widgets

#1

Now that we’re able to design fancy UI’s in interactive ways (totally awesome!), I think there’s a value for a new “interactive(BOOL)” setting for widgets. Currently consider that all widgets have interactive enabled. Disabling it would prevent the user from interacting with the widget, making it more of a display than an input.

Currently I’m using a checkbox as an “led”, but the user can turn on or off the led regardless of whether it should be on. Disabling the interactive mode on the widget would make it respond only to channel values and identchannel changes. Similarly an rslider or vslider and maybe others might be used only for displaying data in a certain way, but not meant to be interacted with.

#2

You could just build the LED yourself using an image? But I see the point you’re making. I did explore something of that nature before, but it turned into the visible() identifier. I will take a look. If it’s straightforward to do this I can add a new identifier called active() that gets passed a 0 or a 1. I’m not a fan of interactive(bool) as half of the widgets are non-interactive by nature. Having an interactive() identifier might give some people the wrong idea :slight_smile:

#3

You can try this version. It now features a new identifiers called active() that accepts a 0 or a 1. It will disable the controls and show them them as disabled. The GUI toolkit I use made this quite simple to implement, but changing how the widgets look when not active is not easy.

https://dl.dropboxusercontent.com/u/11301894/CabbageOSX.zip

#4

Awesome, thanks! I’ll give this version a try tonight. I hadn’t thought of using images, I haven’t really used those much at all.

Whether it’s called active() or interactive() doesn’t matter too much to me, it’s the functionality that’s important.

#5

Ok… tried this version and so far active() appears to be working like a charm for my checkbox LEDs. I also tried an rslider, I like the greyed out level indicator!

That version made one of my instruments fail with a UDO error, apparently passing a constant to xout where it expects a krate variable is now an issue? I seem to have that fixed with wrapping k() around the constant, just thought that was unexpected.

#6

The version of Csound bundled with that binary is the very latest, in fact, it’s not even released yet! So there may be something in this release that forces you to be more explicit about what you return from UDOs. Glad it works Ok for you.

#7

Is it not possible to toggle the active() setting of a gentable widget? I can manually set the active() at runtime, but can’t seem to set it with the identchannel.

Also, I think I found a bug with gentable… when you’re manually dragging points around, dragging one negative never updates it’s Y value on the graph below 0. The point will appear lower, but the graph will not reflect it.

Here’s a screenshot:

#8

Thanks for the report. I’ll take a look. Can you send me the code you used to create that table? It could be because of the way you set up the table.

#9

Well, it was generated by a pretty convoluted instrument that would make it difficult to diagnose heads or tails of what’s happening… but it started as a simple gen 07 triangle wave, length 1024… so basically 0 256 1 512 -1 256 0. The table appeared fine at first, but when I clicked on the -1 point to drag it, this was the result.

Oddly, I tried to recreate a simpler example instrument to demonstrate this behavior… but for some bizarre reason I can’t get my gentable widget to respond as active in the new example. I’ll keep poking at it tho.

edit: and if it matters, the widget was: gentable bounds(120, 50, 230, 160), tablenumber(1), amprange(-1, 1, 1), tablecolour(“green”), identchannel(“graph1”), visible(1), active(1)

#10

I can recreate the problem now. gentable doesn’t seem to like editable tables that move into the negative side of things. That’s typical of Cabbage. Always focusing on the positives! I’ll let you know when I have a fix.

#11

It looks like vsliders don’t get greyed out the way that rsliders do. Probably just an oversight, figured I’d mention it here rather than start another slug thread for it :smiley:

#12

Thanks, I hadn’t noticed that. Can’t think why but I’ll add it to the list.

…Btw, I have fixed the issues with the table. It seems to work fine now. I’ll try to get you a build in the next day or so.

…h/slider issues fixed too. But it brings up another issue. Should controls turn grey when disabled? I’m thinking that they shouldn’t change colour at all. If you wish them to change colour it can easily be done from Csound.

;disable and change colour
chnset "colour(20, 20, 20)", active(0)"

I just know it won’t be long before people want to disable controls, but NOT have them change colour. I’m leaning strongly toward not having them change colour.

#13

That makes sense, I agree… tho that raises a related question I had a few days ago but forgot to ask (the forum said I was talking too much!)… is there a trick to using preprocessor commands like define and ifdef if the cabbage section of the instrument? Resetting colors form the code makes me want to be able to define these colors to strings so that they’re easier to reset on the fly. I had also wanted to use ifdef a few days ago to have certain test widgets only display if a variable was set.

Speaking of setting variables from the csound code tho, I haven’t played with popuptext yet, but it seems like changing that in csound with every value updated could add a lot of unnecessary overhead, especially if you’re doing it on a more complex instrument with a lot of widgets. So I think I changed my mind and would rather the value just always be visible after whatever you set the popup text to. What are your thoughts on it?

#14

There is no preprocessor. But you can always define the strings in Csound code and pass them on startup. The driving ethos behind this project is to keep the entire Cabbage section definition as simple and lightweight as possible. If something can be done in Csound I’m reluctant to duplicate the functionality in the Cabbage syntax. The Cabbage section is only read once at startup so commenting the widgets you don’t want to appear would be more or less the same as using an ifdef /Csound combo.

The overhead can be controlled. You should always control the rate of GUI update yourself. In my tests I see little performance hit when this is done at a reasonable rate, so I would prefer to keep the more versatile system that’s in place now.

#15

Yes, the ifdef for widgets can be easily worked around… like you said, I’ll have the widgets be visible(0) by default, and then have the csound instrument ifdef and set them visible(1). That’s not really cumbersome at all and should work easily enough.

I still think being able to define would be a huge benefit tho, but I also understand that the cabbage parser is limited. It would be so nice to be able to define all of my colors at the top, and know it’s uniform on all widgets throughout… can’t blame a man for dreaming, right?

edit: and btw, in my ideal world a #define in the cabbage section would still carry over to the csound section too!

#16

But hang on,. have you seen the macro/#define mechanism for the Cabbage section? If you are just looking for a standard define that’ll do the trick.

#define SLIDER1 colour("red"), fontcolour("yellow"), outlinecolour("red"), range(0, 1000, 500)
(...)
rslider bounds(39, 12, 50, 50), channel("rslider"), $SLIDER1

It has been there for a while but remains a little untested. I should have thought of this yesterday but I was assuming it was a more dynamic system you were looking for.

#17

It was a more dynamic systen I was looking for, but the ifdefchnset workaround is doing the trick for now.

Ah! There’s a different define for the cabbage section… ok, this might help. I’m guessing these definitions don’t carry over into the csound code tho, do they? I’d love to be able to define the color once, and use it both in the cabbage setup, and in the csound chnsets.

But still, two sets of defines is better than having colors set all over the place in my code!

#18

Let me take a look. I might be able to work a way for the #define string in the Cabbage section to be read in the Csound code. It might be useful indeed. But it might also break other peoples code if they used the macro system. Then again, who reads the docs these days. There is a good chance no one has actually used the macro system yet! Leave it with me. It’s time for breakfast here!

#19

It might be a crazy idea, but could you make your own new “preprocessor directive” like #bothdef meaning it will define a value for both locations, leaving the others alone and (hopefully) maintaining backwards compatibility?

#20

No need for that. You can just add a channel() identifier to the macro definition just before you define the name of the macro ala:

#define channel("defaultSliderStyle"), SLIDER_STYLE colour("red"), text("Hello")

You can then access the string as usual with a chnget:

SMessage chnget "defaultSliderStyle"
prints SMessage

I’ll update the docs and push this to git.