Little GUI widget slugs and wishes

Cabbage Stew
61

Does this also work:

SPathToCsd chnget "CSD_PATH"
SDefaultPresetName strcatk SPathToCsd, "/preset.txt"

Strings in Csound are a nightmare as they are technically i-rate, but can be modified at k-rate using opcodes. But this could also be something I’ve done to screw things up :grimacing:

62

It doesn’t work :frowning: something else must be screwing this.
These two line are actually not enough (tested in a simple csd). When they cause trouble, I have them in an UDO, could that be different?

63

I guess it depends on what the rate of the UDO. Many of Cabbage’s string channels are assigned at k-rate, so if you try assigning them at i-rate you might hit issues :thinking:

64

This causes no issues: SDefaultPresetName1 strcat SPathToCsd, "/preset.txt"

65

But why would it work with strcpy then? Is there any alternatives I could try? Any other clue? Maybe moving all my code out of the UDO?
[edit] just tested, moving it out of UDO doesn’t resolve the issue

66

I’ve no idea. PM me the .csd file and I can test it here :+1:

67

Another little one, which you might already know :wink:
In edit mode, widgets can now only move in big steps (8 points) :frowning:

68

Do you mean when you drag them around? Or when you select one and use the arrow keys? For me they move in jumps of 2 pixels either with the mouse, or the arrow buttons. 8 pixels per jump does seem excessive?

[edit] On Windows it is 2 pixels per jump, but MacOS it is 8. Thanks, I’ll look into this and see if we can’t reduce that :wink:

69

Yes it seems you figured it right - arrow keys. Sorry for my sloppy description.

70

Just pushed a fix for this. And also the issue of the custom identifiers being lost in GUI edit mode :+1:

71

Thanks! The custom identifiers issue seems to be still there though.

72

Seems it worked in but a single case, which just happened to be the one I was tested :laughing: You couldn’t make this up :rofl: I’ll push a fix later. Sorry about that.

73

The custom identifiers don’t get erased now. Thanks!

However, if I change widgets identified by custom identifiers, e.g. cabbageSet SParNames[ind], "outlineColour", 200, 150, 60, 200, the changed attribute (like outlineColour) gets updated on the widget after clicking it. I guess this works similar to updating code by the automatically assigned channel names (e.g. on image) and there is a general mechanism that updates widgets after clicking.

This may be annoying in some cases, like in my example of the outlineColour. I might just want to change custom identifiers to do a bunch of widget modifications based on widget groups marked with corresponding identifiers. This would be a nuisance if, in my example, I’d change the identifier and then update only some property other than outlineColour for that group of widgets, and I’d need to clean up the automatically changed outlineColour for example. Another reason for not updating the widget code would be readability. Consider also the example of image channel name, which I might never need. In cases when I need it, I intentionally give them meaningful channel names.

I generally find it annoying when code (csd file content) changes automatically under the hood (without my intention/knowledge). More specifically, this seems to be common place when clicking on widgets in edit mode. I’m wondering if it would be possible or would it make sense to never update the widget related code in the csd file? Again, I just mean the explicit user code (text in csd), not referring to any housekeeping IDE code (like taking care of channel names for example).

74

I’m struggling to follow this one…

Are you saying that the last known values used in runtime are then use during edit mode the next time you enter and click a widget?

75

Example:
original widget code:
rslider bounds(412, 92, 32, 32) range(0.001, 2, 0.1, 0.23, 1e-06) channel("PitchMODSpeed") _toSL(1)

Add outlineColour during the initialization pass using cabbageSet, enter edit mode and click the slider. The widget code changes to:
rslider bounds(412, 92, 32, 32) range(0.001, 2, 0.1, 0.23, 1e-06) channel("PitchMODSpeed") _toSL(1) outlineColour(200, 150, 60, 200)

No click - no change of code. Possible to avoid this changing of code triggered by clicking widgets? I see no benefit having it, just nuisance. Or?

76

Oh I see. I will try to resolve that. It’s kind of a bug and a feature all at the same time. In reality it’s just a side effect of how the widget data is passed between Csound and Cabbage. Leave it with me :+1:

77

Yeah, this is a tricky one. When we stop a performance in the Cabbage IDE, we don’t delete the plugin, we simply stop it from performing. Therefore all the changes that are dynamically made to the GUI are still present when we enter edit mode. Hmm. I’m thinking :thinking:

78

I just pushed a ‘fix’ for this. I had zero time to test, would you mind?

79

The edit mode seems to work nice in ver. 2.8.37. Tested with custom identifiers, images and labels. Clicking on widgets does no longer trigger automatic code updates. :relieved:
Not sure if it is completely general though?

I like this change very much! It is a little quality of life improvement. Thank you!
Stressless clicking ahead :slight_smile:

1 Like
80

After the change you made in ver. 2.8.37 to address the edit mode, Cabbage seems to be crashing sporadically when I stop my instrument.

I’d like to help debug by running in XCode. How shall I update the code?
I run: git pull origin cmake.
Do I then need to re-build with:
python build.py --config=Release
and/or with:
python build.py --project=Cabbage --build=False --config=Debug?
Sorry for my lack of knowledge! I’m trying …to get familiar :slight_smile:

For now I got one crash (with ver. 2.8.24):

JUCE Assertion failure in juce_LookAndFeel.cpp:73
Program ended with exit code: 9