-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add [Main] to the list of valid groups for HID. #12102
Conversation
Fixes issues with calls to resolveGroup returning undefined
@@ -1252,6 +1252,7 @@ class HIDController { | |||
"[Sampler6]", | |||
"[Sampler7]", | |||
"[Sampler8]", | |||
"[Main]", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what group is this again? we also need to add [App]
IIRC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There seem to have been recent changes that moved, say, vu_meter_l to the "[Main]" group. This list needs to be kept up to date or HID controllers stop working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added [App]
I think we have also more valid control group names:
@Holzhaus Could you have a look, if this list is complete? |
I wonder if we can get rid of this list completely. it's only used in two places: 1: inside resolveGroup to decide if the group being resolved is already known. But all this function does is resolve "deck1" and "deck2" to the appropriate channel. As written, otherwise it returns the group as-is. So we could just replace the whole function with a test for deck1 and deck2. There is an indirect debugging effect that it returns undefined if the group is unknown, but in practice any typoed group name will be caught elsewhere with a missed engine connection or otherwise. 2: inside getActiveFieldGroup, where it is essentially doing the exact same thing -- calling resolvegroup. So I am going to get rid of this list and see what happens |
Code LGTM! Did vou check that no mapping uses this public list directly? |
This seems not the case. LGTM. |
Fixes issues with calls to resolveGroup returning undefined