Cabbage Logo
Back to Cabbage Site

Cabbage2lite pre-testing: 1

#1

Hey Rory, thanks for the first run of c2lite. It’s great having a new version of cabbage that first into my workflow, even if things aren’t perfect just yet.

This is just a first round of feedback. I didn’t get to do tons of extensive testing, mostly just noting when things went wrong or didn’t seem as expected. I can dig deeper with testing on any of this if you think it seems relevant.

I’ll start with the simple stuff:

  • cabbage plugin name doesn’t appear in window title bar, just shows “CabbageLite”
  • I can only have one C2 window open at a time (possibly due to how sublime hooks in for the console/debug output? didn’t test standalone yet), had no problems launching multiples from sublime with C1 tho.
  • single line groupbox with { } creates issue as mentioned before, even when not a plant or nested. I know it’s an easy fix on my end too, but as I update more of my old effects I really feel like this should behave the same between versions.
  • button size or font size is just barely different, a button that’s text displayed fine in c1 now shows “…”, very minor, but maybe worth knowing. example: button bounds(28, 55, 20, 18), text(“Inv”, “Inv”)
  • floating point digits displayed in popuptext when range sets step size to 1 (rslider)… popup shows 1.00, 2.00, 3.00 etc.
  • gentable doesn’t respond to identchannel for tablecolour changes? didn’t try other fields like bounds yet
  • new hrange tabs are too easy to “miss” (maybe even invisible pixels?) and grab the width instead of the limit
  • hrange suffers large amounts of lag when grabbing full range to move. This was found on an effect I just dug out of the “basement” tho, it’s possible the problem is something I did dumb.

And some more odds and ends:

  • An rslider with range(0,0,0,1,.01) doesn’t render properly… tho it also needs color settings set to be visible. It just shows up as a large box. I didn’t go crazy trying the same issue with different widgets or values, just stumbled into this on accident.

  • Defines with similar names now behave differently! For example,

#define RADIO_BUTTON_2 fontcolour:1(255, 255, 255, 255), fontcolour:0(160, 160, 160, 255), colour:0(30, 30, 30, 255), colour:1(255,0,0,255),
#define RADIO_BUTTON fontcolour:1(255, 255, 255, 255), fontcolour:0(160, 160, 160, 255), colour:0(30, 30, 30, 255), colour:1(0,255,0,255),
Works as expected in C1. If I reverse the order of the defines in C1, then all RADIO_BUTTON_2 would have already been replaced by the define for RADIO_BUTTON… BUT the opposite is true in C2, it’s almost like it’s being parsed backwards?!? I’ll probably end up working around this by renaming the first to RADIO_BUTTON_1, but if my suspicions are correct this presents a potentially big compatibility issue that might be really tough to diagnose if/when it surfaces for users randomly.

Lastly, purely aesthetic feedback… I feel like the new hrange tab style is really mismatched now when viewed next to hsliders.

#2

Fixed. It was changing the name when opening manually, but not from the command line.

OSX won’t let you launch 2 instances of a program unless you start them explicitly from the command line. This works. I just checked it. Not sure what kind of hoodoo you will need to use to sort this issue out. I’m also not sure why the same thing you did for C1 doesn’t work in this instance. There is very little different in the code.

Can you explain it again I couldn’t find the thread from earlier…we have a bad habit of going off topic!

It’s known. The graphics code was completely rewritten. Some of the old code was erroneous. After updating it certain things look slightly different, but the upshot is the C++ code is better written and easier to maintain. If these thing get to you, it might be time to look at using your own GUI elements in the form of PNGs or SVGs.

Fixed in git.[quote=“t_grey, post:1, topic:777”]
gentable doesn’t respond to identchannel for tablecolour changes? didn’t try other fields like bounds yet
[/quote]

You need to use tablecolour:N(), where N is the table number, starting at 0 for the first table. This was change to allow both colour names and RGBA values for tables.

I haven’t checked these in a while. I can’t even grab full range to move. I’ll take a look. Drawing the actually thumbs for these sliders is a pain. Juce doesn’t come with such sliders so I’ve had to throw together my own. Hence the issues!

In debug mode this actually causes a JUCE assert. It’s not legal in JUCE to set up a slider this way. I think the fact that it doesn’t render properly is a good indication to the user that it’s a stupid idea? If you want a slider that doesn’t do anything set it to inactive?

I think I know what’s going on there. I’ll take a look.

See the note above. I can try to update the look a little, but these suckers aren’t easy to get right. The smaller the thumb is the harder it is to grab them, but the better it looks :rage: I’ll take another look…

New proposal for modular GUI, part 2
#3

Well, I do notice tons more output being generated by C2, so I was wondering if the level of output being captured or generated might have anything to do with it, or how it’s reporting back or hooked in to. Usually I see little if anything reported in the sublime window. Maybe C1 normally closes whatever named pipe etc once the program is launched rather than keeping it open for tons of debugging info? That’s just a wild stab in the dark tho. I am using the same exact method to launch them, I literally copy pasted the build target rules from C1 in sublime.

Sorry about that, I was trying not to be any longer than needed. Or go off-topic. :slight_smile: The single line groupbox issue was discussed here : Single line groupbox issue?
I know it’s not the smartest thing, but basically if there is an empty groupbox on a single line, it creates rendering issues. A simple line break between the brackets fixes it, so this sounded like a simple parsing issue… but maybe it’s something else.

That’s what I do… I drink and I know things. :wine_glass: :spy: Lol. Seriously tho, didn’t consider it a major issue, just reporting what I saw… who knows, maybe it was as simple as a wrong font size somewhere and no one’s pixels had lined up just right yet. And ironically, I was considering diving in to SVG/PNG gui elements, but probably not until cabbage includes and other such preprocessor “candy” is in. I want to make sure I do the SVGs in a way that will work best modularly too.

Interesting… IIRC in my testing setting the color statically with tablecolour(RGBA) works, just not when setting through an identchannel. My first quick test with tablecolour:0() didn’t work either, but that might be something I’m doing… I’ve rigged up quite a silly instrument for gui tests and choosing color schemes, so maybe I messed something up. I’ll test it some more and see if I can get this working as expected.

Just to be clear, the settings aren’t extended to their fullest, I just mean when I try to grab the range bar in the middle as compared to either end. Just in case you interpreted that differently. How is the “hitbox” for lack of better term for the thumb/tab determined? Is it masked in the tab’s image file with an alternate pixel color, or is it drawn geometrically around it? I don’t know, regardless of how it looks, it just feels like I can miss it far too easily now.

I’ll mostly agree, tho I found it by accident trying another probably stupid idea… I was trying to alter a widget’s range with input from another widget. Didn’t seem to work… but I tried a variety of different way, including a 0,0 widget. I’ll agree it’s not an important “bug”, just passing on what I found while experimenting.

Thanks for all of the work getting that stuff fixed so quickly and for taking a look at the rest. I know it was a pretty big dump of data, but I spent most of a day trying all sorts of silly things just to see what happened. At this point I think a lot of the problems I still see might be of my own creation, but after I spend some time I might have some more to report. I’m sure I’ll have tons of new ideas tho… I already have a few brewing, particularly with radiobuttons. :innocent:

#4

  • With regards the level of output nothing has changed. Perhaps you should use the “-m0d” flag in your CsOptions?

  • With regards to the brackets on the same line, it causes a problem because plants can’t be single line. That was never supported. The only change is Cabbage is not a little stickier when it comes to syntax because the parser was updated.

  • I get the point about the range sliders. I’m just surprised they are so funked up :joy:

Keep the bug reports coming. You won’t offend me!

Btw, i’m trying to find the post you made about radiobuttons. i recall reading it and not replying because I didn’t have time, but now I can’t find it. I wish discourse would allow users to make post and unread…

#5

Re: the output thing, it’s the same instruments with the same options, just switching between a c1 build and c2 build in sublime. In c2 the sublime build window (not the cabbage cs console!) is spammed with what looks like it may be debug messages. It almost looks like output related to setting or getting channels. I see raw values but no context.

This still happens with a non-plant groupbox. The easiest answer is to just delete the brackets, and if you’re ok with that I don’t really care… but it’s raised my eyebrows a few times when I dig old work out. Plants end up rendered off the screen, and I waste time trying to track down why they’re visible(0) not reailzing it’s just the bounds issue :dizzy_face:

I don’t recall where, but I had requested a way to make buttons in a radiogroup able to be turned off. Currently you have to add an extra button that represents off, rather than allowing a second push (like a latched button) to turn it back off. Perhaps the easy and obvious answer is the use “latched” for this behavior?

I also had an idea for a specific “radiobutton” widget. This would work kind of like a cross between a button and a combobox. They would be grouped by channel, so only one widget per channel could ever be on. This allows you to read in a single channel in the instrument, rather than having to composite a bunch of channels together (I might be up to almost 20 buttons in a group in one proof-of-concept sort of experiment, it’s a bit cumbersome)… anyways, for example:

radiobutton channel(“myradio”), value(1)
radiobutton channel(“myradio”), value(2)
radiobutton channel(“radio2”), value(“One”), channeltype(“string”)
radiobutton channel(“radio2”), value(“Two”), channeltype(“string”)

#6

But then they wouldn’t be radiobuttons :joy: What you propose would be easy enough to code in Csound wouldn’t it? Or would it?

#7

I might not have done a good job explaining… or maybe I did and you still think it’s a bad idea, which is fine… but I’ll try again just in case.

The idea behind current radio buttons is that each controls an on|off value for a discrete channel, and only one channel can be on at a time.

I’m proposing a type that all of this new button type transmit on the same channel, but only send an on value, but again only one button can be on at a time. So instead of:

kchan1 chnget "button1"
kchan2 chnget "button2"
kchan3 chnget "button3"
kchan4 chnget "button4"

if(kchan1==1) then
  kmode=1
elseif(kchan2==1) then
  kmode=2
elseif(kchan3==1) then
  kmode=3
elseif(kchan4==1) then
  kmode=444
endif

you could literally just have:

kmode chnget "mode"

where the values are set in the widget declaration. But to be clear, yes… working around this is by no means difficult, it just seems like a logical way to work with the radio style buttons and channels, especially once you start to reach an obnoxious number of buttons that work in conjunction with each other.

Another good use case example would be feeding a number of buttons that control a freq into an osc. It would seem much more direct (at least to me) to just set the freqs at the button where the matching widget text is set rather than have to make a block of csound code that parses and deals with it.

#8

Just like a combo box :joy: i get what you’re saying. Let me have a think about it.

#9

In Csound/Cabbage code it’s quite simple to create something like this:

<Cabbage>
form caption("RadioThings") size(840, 280), colour(58, 110, 210)
button bounds(10, 40, 30, 30) channel("button1") radiogroup(99), text(""), colour:1("red")
button bounds(40, 40, 30, 30) channel("button2") radiogroup(99), text(""), colour:1("red")
button bounds(70, 40, 30, 30) channel("button3") radiogroup(99), text(""), colour:1("red")
button bounds(100, 40, 30, 30) channel("button4") radiogroup(99), text(""), colour:1("red"), value(1)
</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 -m0d --midi-key-cps=4 --midi-velocity-amp=5
</CsOptions>
<CsInstruments>
; Initialize the global variables. 
sr = 44100
ksmps = 32
nchnls = 2
0dbfs = 1

;instrument will be triggered by keyboard widget

instr 1
    kValue init 0
    kIndex = 1
    kTrig changed, chnget:k("button1"), chnget:k("button2"), chnget:k("button3"), chnget:k("button4")
    if kTrig == 1 then
        while kIndex<5 do
        SChannel sprintfk "button%d", kIndex
        kValue = (chnget:k(SChannel)==1 ? kIndex : kValue)
        kIndex+=1
        od
    endif

    printks2 "Current Value of group is: %d\n", kValue
endin

</CsInstruments>
<CsScore>
;causes Csound to run for about 7000 years...
i1 0 z
</CsScore>

Rather than create new widgets for these specialised tasks, I would much prefer to develop a way of abstracting user defined widgets. I’m just not sure of the best way to do it because things have to be split between the Cabbage and Csound code. I guess it goes back to our earlier discussion about GUI development.

#10

Btw, one thing you may have seen me mention in the past is that the JUCE developers are trying to discourage people from setting up VST parameters with the same names/IDs. In Cabbage each channel is a parameter ID. When I run instruments with duplicate channel names with my debug build of Cabbage I get an assert. It’s a bit annoying, but I see the validity of their thinking on the issue. I hope it stays a debug mode assert and never makes it into the release mode builds!

#11

Your example assumes the values are sequential, there’s a reason my earlier example had one set out of sequence :stuck_out_tongue: But either way, if you end up deciding to go with the idea, great… I think it’s logical in many cases, but in some cases I would still rely on the original method. If not, no worries. I’m up to I think 19 radiobuttons in a group, and at that scale it just seems to be begging for a better solution.

I also wonder how it would work to allow a button to be a member of multiple radiogroups. The idea that made me think of this (tho not relevant, and you’ll see why) was having two groups split as such: radiogroup1: bold, normal. radiogroup2:normal, italic. That would allow normal to turn off both, and either to turn off normal… but they don’t turn off each other. But in cabbage, it’s not really relevant since “bold-italic” is it’s own style… but it still hatched the idea in my head.

Here’s a few more things I’ve noticed that I’m pretty sure aren’t my doing.

  • It looks like fontcolour isn’t updating for numberboxes. Same test works fine for numberboxes in c1.

  • Disabled checkboxes still allow checking (at least visually, didn’t check channel status).

  • Still no luck getting a graph’s tablecolour:N to set dynamically. I guess I can try one more, super simple example to prove myself wrong… but this ridiculous 19 radiobutton instr is dynamically changing every other widget type without a problem… LOL.

If you get different results, let me know… I don’t mind packing up fresh examples (assuming this code all runs under 6.10 without changes)

#12

Sorry, I totally forgot about the tablecolour identchannel issue. I’ll look into that now…

#13

Wait… so does that mean having an rslider and a numberbox on the same channel is going to be discouraged? I really like that method of giving two styles of input control.

#14

I do too. I will do my best to accommodate it.

A single line of code can change this:

kFreqs[] fillarray 100, 200, 400, 500

and then modify the print statement:

printks2 "Current Value of group is: %d\n", kFreqs[kValue-1]

My goal for Cabbage was never to have hundreds of widgets, but instead provide people with means of creating their own custom interfaces. This makes everything easier to maintain on my end. I’m already regretting add the range sliders, but that’s on me. They could have been implemented using just Cabbage and Csound, but it would be a little tricky to implement the hit tests. Not impossible, just tricky. So instead of me developing new widgets, I would rather the user had a way of doing it natively with Cabbage and Csound. It just needs some thought.

#15

It looks like recent changes to tables have messed up a few identchannel identifiers. I’m just looking into it now…

#16

I’ve fixed the table issues. No to take a look at the range sliders…

#17

I get that, and I agree with the concept totally… but I see it as a fundamentally different style of widget, even if they serve a similar purpose. I’ll admit, your workaround is more elegant than mine, and I imagine for someone with less experience it might look even worse. That’s why I felt like it warranted consideration.

Awesome! Did that have anything to do with the numberboxes (fontcolour) too?

#18

I’m afraid not. That’s a deeper issue and looks like something that was introduced in a recent version of JUCE. It seems to affect all sliders. :rage:

#19

I think you’re mixing up which I was asking about in context. It does suck that the range sliders are borked, but I was wondering if the gentable’s identchannel issues may have been related to numberbox’s issues too. :wink:

#20

No, I was replying that I’m afraid not because if the fontcolour issues were related to the gentable they’d be fixed now. Oh, the gentable stuff is fixed now. The fontcolour stuff not… still digged into that one.