Channel names for all widgets to array

[Samo]

Hi!

For my custom preset system it would be convenient if I could easily obtain an array of strings with channel names associated to all widgets. Something like an opcode (“getChannelNames”?) returning an Sarray[]. It would further be handy if one could provide an array of names to be excluded (filtered). Perhaps the presetIgnore() identifier could be reused for this purpose?
Reference: New presetIgnore() identifier

I don’t know how useful such an opcode would be for others or how difficult it would be to implement, but it would surely spare me some tedious manual bookkeeping in scenarios with many widgets. I’m also curious to hear your opinions or suggestions for alternative work flows.

[rorywalsh]

@Samo

Something like an opcode (“getChannelNames”?) returning an Sarray[].

Sounds like it could be useful. Although I think it would be better if it focused on widget channels, as there are a lot of reserved channels knocking about too. So maybe cabbageGetWidgetChannels might be more appropriate? Let me try some things. automatable() is another identifier that could be a useful filter. In fact, any identifier could potentially be used as a filter. For example:

SChannels[] cabbageGetWidgetChannels "bounds(10, 10, 10, 10)"

might return all widgets that have their bounds set like this? Just an idea, it would also give people the option of use custom identifiers, which in turn could lead to custom filters.

[rorywalsh]

I have this working now I think. I’ll push the changes through so you can test. Here’s the basic gist of it. In this example I’m using custom identifiers, but you can pass whatever you like to it. Cabbage will check for any widget with the same identifier set that way and add it to the output array.

Note, this is an i-time only opcode. Considering channels can not be modified, there is little need to have this run a k-rate.

[Samo]

Fantastic! Thanks!
I haven’t tried it yet but just a few comments/questions for now.

@rorywalsh

Although I think it would be better if it focused on widget channels

Yes, this is what I meant, makes perfect sense.

@rorywalsh

Note, this is an i-time only opcode. Considering channels can not be modified, there is little need to have this run a k-rate.

Agree.

@rorywalsh

I’m using custom identifiers, but you can pass whatever you like to it.

So can one add any string like e.g. “addMeToArray”?
Is there a special reason why you prepended with underscore (_customFilter(1))?

Another suggestion: I think for my use it would actually be quite convenient to have a part of the channel name (sub-string) as a filter. Then I could just name channels like e.g. X_channel1 etc. and use “X_” as a filter. Would something like this be easy enough to add or perhaps it’s a nuisance?

[rorywalsh]

@Samo

So can one add any string like e.g. “addMeToArray”?

Yes you can use whatever custom identifier you like, but it must have an underscore. This is what let’s Cabbage know that it’s a custom identifier. Otherwise one runs the risk of using a custom identifier that goes on to become a native one in Cabbage. The net result being that any instruments you have that used that identifier will now be broken. There was a short discussion at the time about the use of _ or all uppercase. I think _ won out.

@Samo

Another suggestion: I think for my use it would actually be quite convenient to have a part of the channel name (sub-string) as a filter. Then I could just name channels like e.g. X_channel1 etc. and use “X_” as a filter. Would something like this be easy enough to add or perhaps it’s a nuisance?

That certainly would not be that easy to add. But lucky for you can you just filter the channel names afterwards in Csound. You could easily write a UDO for this. To be honest, it would be easier to write a set of array manipulation opcodes for Csound rather than go messing with how Cabbage parses its identifiers.

My general approach to adding new things is this: if it can be done in Csound, then use Csound.

[Samo]

Nice! Thanks for explanations!
Right, doing filtering in Csound is perfectly fine.
As far as Cabbage can extract all the widget channels I’m more than happy!

[Samo]

Would it be possible to enable cabbageGetWidgetChannels outside of instruments?
While not critical, it would be good for consistency with custom opcodes and other functions like fillarray.

I’m determining the length of global function tables from the number of widget channels. I could do it all in an initialization instrument, but if possible, it would be more elegant and consistent having the ability of using cabbageGetWidgetChannels also outside of instruments.

[rorywalsh]

My initial instinct is that this won’t be possible, because widget’s aren’t initialized when instr 0 is run. So I think it will have to go into an instr 1 or higher.

[Samo]

I see. No problem! Thanks!