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
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.
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.
@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ā.
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
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
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.
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 !
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?
[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.
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.
Thatās the idea. identChannels should not be used in guiMode("queue")
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
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?
I donāt think it makes any difference. They wonāt be constantly drawn so it shouldnāt incur any overhead.
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.
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.
Can you provide me with an example of this. I just tested here and I canāt recreate this issue.
This is the first time Iāve ever come across this. Iāll take a look.
Please donāt be afraid to report the issues when they occur. Otherwise Iāll never be aware of them
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.
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.