Widgets should not share channels names

[rorywalsh]

For as long as Cabbage has been around it has been possible (although never recommended), to use the same channel names with multiple widgets. We all did it right It starts off with a little duplicate here, then another one, next you know 20 different widgets are connected to each other by a single channel and a team of Cabbage coloured unicorns start singing Palestrina motets in your ears.

Well I’m pulling the plug on it! No more unicorns, and no more duplicate channels!

Why? A channel name becomes a parameter name in the DAW. And many DAWs will simply refuse to create a second parameter if there is already one created with that name. To be honest, I’m surprised they worked this long without problems

I’ve added a check on compilation for duplicate channels. You can ignore the warning, but do so at your own risk

[iainmccurdy]

Spoilsport. Seriously though, you might want to watch that Cabbage doesn’t become a nag, bombarding the user with popups saying “don’t do this”, "don’t do that, when opening an older csd.

[rorywalsh]

I know. I was thinking of this. Maybe it would be better to just print this information to the Csound output console, or add a “Cabbage Warnings” console? That would certainly make things easier to ignore. I’m open to ideas. I just want to help people avoid some common mistakes that might lead to some potential problems down the line.

[rorywalsh]

@iainmccurdy How about this, complete with numbers of offending lines

I just have to add a few more warnings like “Don’t use purple, that’s a horrible colour” and “Your .csd file use tabs instead of space. Please try again”.

[iainmccurdy]

That’s much more polite looking!

[rorywalsh]

As some of you have noticed, whenever you add a widget to an instrument using the GUI editor, it will create a unique channel name for that widgets in the form of slider00001. You can obviously rename the channels to anything you like, but remember each and every widget should have a unique channel name, otherwise you will get the dreading yellow warnings

[JonNelson]

OK I am getting the following error messages:
The following channel names are used across multiple widgets: “image-9” (Line:1),“label-9” (Line:1),“filebutton-9” (Line:1),“filebutton-9” (Line:1)

Must all image and filebutton widgets have a channel name? For that matter, must every widget have a channel name (even if we are not using the channels within the Csound code)?

Thanks for your feedback when you have the chance,
Jon

[rorywalsh]

They are just warnings. But yes, all widgets should have unique channel identifiers. Especially those that can be controlled by the host. The line numbering is a little off but as a long time Csound user I’m used to that If you don’t set unique channel names you will see these warnings, but they can be ignored.

[JonNelson]

[Retornz]

I am wondering the same, when I search in the code these “image-9” nothing pops us… So I don’t see how to fix it…
Thanks in advance for the help @rorywalsh !

[rorywalsh]

Every widgets must¹ have a unique channel assigned to it now. To get rid of those warning, just give the identifier a valid channel.

¹ They don’t really have to, but if you don’t give each one a unique name you will get these warning.

[Samo]

The warning messages apparently consider comments as code. If possible, I’d like to exclude comments from the warning inspection. Perhaps there is a flag that I could include or it might be more convenient to simply ignore all comments by default?

[rorywalsh]

Yeah, good point. I’ll sort that.

[edit] I’ve added this now, although it’s pretty crude. If it finds a ‘;’ it will treat the line as a comment. regardless of where the comment appears.

[Samo]

Thanks!!!
It is still complaining about the identChannels() with guiMode("queue") though.

[Samo]

There are channels “forced” on labels - labels seem to automatically get channels associated to them. Is this necessary? Isn’t this a waste of resources? There are possibly unnecessary (and annoying) warning messages associated to missing channels for labels. If they are not needed, it would be good to have an option to not force the channels on labels and display the warnings.

[rorywalsh]

@Samo

It is still complaining about the identChannels() with guiMode("queue") though.

That’s the idea. identChannels should not be used in guiMode("queue")

@Samo

Is this necessary? Isn’t this a waste of resources?

It’s not a waste of resources at all, considering all widgets are assigned channels regardless of whether or not you actually assign one in your code. If you like I can add an ignoreChannel() identifier, but that’s probably more typing than actually declaring a unique channel name

[Samo]

OK, I see, thanks!
If I’m not changing a label, I think it would still be convenient to have its channel name assigned automatically just in the background as it used to be - if possible?
I got in a (perhaps bad?) habit of adding labels because of position flexibility compared to slider text. Is it cheaper to have slides with text instead of separate labels?

[rorywalsh]

@Samo

Is it cheaper to have slides with text instead of separate labels?

I don’t think it makes any difference. They won’t be constantly drawn so it shouldn’t incur any overhead.

@Samo

If I’m not changing a label, I think it would still be convenient to have its channel name assigned automatically just in the background as it used to be - if possible?

Channels name are automatically assigned if you drop them in via the GUI editor. The real issue of course is when parameters share channel names. So what I can do is ignore any widget that has automatable() set to 0, which are most of the layout type widgets. That would immediately remove all warnings for labels, groupboxes, images, etc.

[Samo]

Yes I noticed that as soon as I “touch” a widget all sorts of funky things may happen, also annoying things like changing mode of filebutton or populating text(""), bound hight from 8 to 10… I don’t remember now but I had several surprises that way… And I am often “touching” widgets just to find the associate text to modify.

Channels could still be used and interfere within Csound even when automatable(0), right? And labels cannot be automatable, right?

I don’t want to complicate with this, but most of the time I find it annoying when things change automatically. Maybe having some options in Cabbage to toggle (different types of) warnings and “auto correct” could be useful.

[rorywalsh]

@Samo

I “touch” a widget all sorts of funky things may happen, also annoying things like changing mode of filebutton

Can you provide me with an example of this. I just tested here and I can’t recreate this issue.

@Samo

bound hight from 8 to 10…

This is the first time I’ve ever come across this. I’ll take a look.

@Samo

Yes I noticed that as soon as I “touch” a widget all sorts of funky things may happen

Please don’t be afraid to report the issues when they occur. Otherwise I’ll never be aware of them

@Samo

Channels could still be used and interfere within Csound even when automatable(0) , right? And labels cannot be automatable , right?

Correct. You can still interact with any widgets via Csound, as long as they have a channel assigned. Sliders, comboboxes, buttons and checkboxes can be automated via a host. The rest cannot.

@Samo

I don’t want to complicate with this, but most of the time I find it annoying when things change automatically.

I would to, and it’s certainly not by design. Does this happen a lot? Thanks to your report from above I now know that clicking on a widget with a height of 8 causes it to be changed to a height of 10. But I have no other reports of this happening.