I just started checking out the new version 4.7, my first stop was the “radio buttons” feature. I have many radio buttons now, all scripted. It seems that you cannot have grouped widgets be part of the built in radio button feature. Let me back up. Firstly, groups are now called “widget links” it appears. There is a new option called “Radio Group”. This is set to 0 by default. I guess there is no “0” radio button group, so whatever is set to “0” means it is not a radio button. So when I tried to set one of my existing radio buttons to 1, I got an error message that “Radio buttons are not allowed to be a part of a linked widget group.” This is a bit of a bummer (unless I’m missing something) as pretty much all my radio buttons are part of “linked widget groups”. For example, when I select a radio button, it usually bypasses/unbyasses a plugin and at the same time, another (grouped widget) solos a particular channel in a mixer. Is this not possible then with the built in Radio Buttons feature or is there a work around? If not, I guess I’ll just hold on to my rackspace script.
Suppose you have two radio buttons in radio group 1 and the first radio button is linked with some other button A and the second radio button is linked with some other button B
Button A and Button B, not being part of a radio group, are both allowed to be down at the same time – so what should happen when you press them both given that only one radio button can be down at a time but both radio buttons are linked? And if you answer, “whichever button was pressed last”, then what should happen when you switch variations and both buttons essentially go down simultaneously?
There are all sorts of potential conflicts - hence the current restriction.
Yep - GP Script 
And the scripts can probably be simplified significantly since they don’t need to keep track of what widgets are up or are down.
For example, if X, Y and Z are buttons in a radio group, and A,B and C are regular widgets, then the following will just work - no bookkeeping needed
On WidgetValueChanged(newValue : double) from X
SetWidgetValue(A, newValue)
End
On WidgetValueChanged(newValue : double) from Y
SetWidgetValue(B, newValue)
End
On WidgetValueChanged(newValue : double) from Z
SetWidgetValue(C, newValue)
End
Gotcha! So still scripting, but instead of scripting the radio buttons, script the regular widgets and it’s a much simpler script. Ok that works, thanks!
So I rewrote the script to follow the above, and just discovered that the “new” radio buttons cannot follow variations. Ignore variations is always ON and cannot be changed. I guess I can see why, but I always used both live and varations combo and that’s what I’m used to. I need to go back to the old scripting way. LOL
What does it bring with regard to the new radio buttons group?
The old radio button script allows me to group it with other widgets (which we discussed a work around above) + it follows variations.
If you want radio button behavior based on variations, then you don’t need radio buttons - just use regular buttons and set their state appropriately in each variation, i.e, everything off except one per variation.
I understand, but it takes a lot more clicks to setup and and if I make a change I have to redo a lot more clicks. I found it the most convenient for me, is to setup radio button script one time, then can copy the RS and make changes. So I like having the radio button functionality with following variations. I’m not sure why that choice couldn’t be left up to the user? Make it default to not follow variations, but allow it to be changed.
You are right, more clicks - but a lot more?
Maybe this behavior is designed because of situations which could lead to issues when it would not.
First things first: radio buttons are a great !!
related to the constrains: i can understand the point with the linked widgets – i don’t understand the point with the variations.
I use “Buttons” to select different instruments via “NoteOn” and i use this within a rackspace via different variations. “Radio Buttons” will be perfect for this type of changes to ensure that you only have ONE instrument live within a variation.
I don’t understand the argument that within variation you can do this “manual” by using regular buttons and set their state appropriate in each varaiation. That’s also true for rackspaces – so no need for Radio Buttons??
Radio Buttons make live easier and reduce risks (like activate accidentally two instruments)
When you use variations then radio buttons are not really needed.
Of Cause i can do the switching between NoteON from different MidiIn manually - but the idea of a radio button is to make it easy and avoid mistakes. Why should be the switching between variation different to switching between rackspaces??
Is there a SW or Design constrain?? If yes - we have to live with it … If not it would be great to have the radio buttons also enabled between variations.
To avoid mistakes, you can easily lock those widgets 
For more specific use cases the the current radio buttons implementation, you have either scripting (as already mentioned) or the Gig Performer radio buttons extension.
I understand that i can do all this with scripting or an extensions and i have done this before. But it needs time and work and is not fail-safe.
There is the new and nice and easy to use radio button feature and i do not not understand why this is not usable with variations.
There are many situation they will be a perfect solutions eg selection of instruments or the B3 Black Keys or … and these are all use cases for variation as well…
The developers understand.
That’s highly presumptuous position to take in my opinion if you don’t mind me saying so. In my work flow it is much more convenient to have the radio buttons be able to follow variations. But it’s ok, with the old scripting I can do everything I need to.
I assume our comment
indicates that there is a SW / Design / technical reason preventing the usage of Radio Buttons controlled by variations.
Many of the community members have a technical / SW / … background and understand that the usage of a feature may be limited. No reason to hide a limitation.
It is clearly not the perfect way to hide limitation by downplaying use cases the community has highlighted.
It’s a current limitation!
You get the best news award in this thread!!! LOL
Well, there’s really nothing else to say – in a future update, we will see if this limitation can be removed.
As we’ve often said in the past, if we waited until everything was perfect then
- An update would never get released
- There would never be more than that one update after it never got released