Cabbage Logo
Back to Cabbage Site

Custom identifiers

#1

I just wanted to discuss the new custom identifiers idea. With the new widget opcodes it is possible to retrieve the value of any identifier assigned to a Cabbage widget. It’s also possible to create custom identifiers, but we need to decide on a convention for their use. We don’t want a situation whereby a user has been using custom identifiers that suddenly become an official Cabbage identifier as it will break the users code. As it stands now, I have a restriction in place that custom identifiers must be prefixed by an underscore, but I’m open to suggestions. For example:

button bounds(144, 94, 80, 40), channel("Button"), text("0", "1"), _textInfo("this is some test")

Does this seem Ok? We could also UPPERCASE identifiers:

button bounds(144, 94, 80, 40), channel("Button"), text("0", "1"), TEXT_INFO("this is some text")

What do you think? Does anyone have any other suggestions? I’m not a big fan of UPPER CASE labels so I’m currently leaning towards the underscore. And I can’t ever imagine a time when Cabbage identifiers will ever use them. I would love to make all identifier camelCase as I find them a little difficult to read as all lower case, but that’s a different discussion!

Set multiple identifiers with one cabbageSet?
#2

In my opinion the use of the underscore for a custom identifier is ok. The upper case I would only use for macros.

And I’m all in on the camel Case. :grin:

#3

We might need a poll!

#4

Ooops, did I miss the elections? :sleeping:

Seriously tho, I agree with underscore, and that all caps seems more appropriate for macro use.

CamelCase I wasn’t quite as on board with, but that ship already sailed. At least there’s a great conversion utility! :+1:

I’m curious tho, what would be a good use case example for these custom identifiers? I’m not all up on the new cabbage functions (yet), so perhaps my imagination isn’t primed to come up with a good idea for how to use this.

#5

They let you create class members of sorts. If you think of your widget as a class that is. You can define any kind of data you want and modify it in the orchestra using cabbageGet/cabbageSet. The possibilities are vast. One recent use for them popped up in this discussion.

It uses the cabbageGetWidgetChannel opcode to grab a set of widgets from the GUI. There was no way to do this in the past, it was all or nothing.

#6

That’s the discussion that led me here. I wasn’t quite sure what I was looking at in the example yet… Honestly, I’m still not… I’ll read over it again some and see if I can make better sense of what I’m seeing.

Sorry, I’m RATHER behind on the times with csound and cabbage… so everything’s been a little bit of an uphill battle. At the very least, I’ve got my old code running on new builds!

#7

Let’s say you have 20 widgets, and in one go you want to make 10 of them invisible. In the past you would create an array with 10 channels, and then in a loop iterate over them call cabbageSet... "visible(0)". Now you can just mark those sliders when you create them:

rslider bounds(), _group(1)

Now you don’t have to manage an array for these sliders, you can simply call cabbageGetWidegetChannels to retrieve them all in one go. In other examples I’ve seen users set custom popup text as a custom identifier. It’s useful for creating identifiers that don’t already exist.

#8

Ok, I think I’m 99% of the way there now… I was thinking “_group(xxx)” was something new I didn’t fully understand, and wasn’t putting it together with the separate message a little later that said “add _group(xxx) to each” that this was the custom identifier being added.

I was also rather confused by cabbageGetWidgetChannels, but I just read the doc page on that. Wow, that looks SUPER powerful and useful!

#9

Yeah group wasn’t the best example because we already have a group feature. :rofl: But, yeah, it opens up a whole new way of passing data back and forth between the UI and Csound. It could easily replace your macro system :wink:

#10

I’m sure it could… and more than likely eventually will!

But for now all of my stuff is still running the old school way, and is too complex for me to learn the newCabbageStyle while converting. So it looks like I need to take some time working with simpler examples and wrapping my head around working this way before I fully dive in with my actual code.

First thing that jumped out at me while just working through ideas in my head, how would initializing widgets that create themselves with z-layering and/or parent containers work? For example, say I have a hard-coded groupbox, and want my code to create it’s own widgets within that container space? Or if I have two different sets of self generating widgets, how to choose which renders over which?

Sorry if these are already answered somewhere… I’ve been trying my best to play catch up, but it seems the past 6 months have been rather eventful! Looks like I’ll have a TON to experiment with in the near future…

#11

Cabbage to ya covered :wink:

You can parent() and moveBehind(). Both of which are designed to be used exclusively from the orchestra. :+1:

You know that this new set of opcodes and way of working with the UI/orc also makes the custom plant system more or less redundant. I really feel for you, as I know you invested much time in that, as did I. All I can say is, this updated system was borne from the fruits of our labour. With the new system, everything can be defined in a UDO, completely self contained. I think it’s clearer, and it’s definitely way easier to maintain.

#12

Great to see it’s already been thought of, apparently I have a TON of reading to do… I don’t even have the first clue what I’d be passing to parent() to make any sense. Hopefully I can get up to speed and move everything out of custom plants without too much of a problem tho.

It’ll probably be a very long process, wish me luck! And sorry in advance for the inevitable billion questions you’ve probably heard 3-6 months ago but I haven’t stumbled across yet :wink:

1 Like
#13 
$ find . | grep xml | wc -l
  44

oof.