You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: proposals/2025-12-02_controller_shared_data.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -71,7 +71,7 @@ No two hardware mappings will have the same namespace, and we can enforce that w
71
71
`Grouping` is a logical value defined by the controller mapping definition.
72
72
It can be like a Mixxx-style group ("`[Channel1]`") but it can be any arbitrary string.
73
73
Many controllers will want to define something like `deck1` to refer to a device that can itself be assigned to multiple mixxx channels.
74
-
This document does not use the word `group`, instead prefering`grouping`, to try to differentiate Mixxx-style "groups" from this concept, which is a distinct abstraction.
74
+
This document does not use the word `group`, instead preferring`grouping`, to try to differentiate Mixxx-style "groups" from this concept, which is a distinct abstraction.
75
75
76
76
The controller mapping decides how these groups behave and Mixxx does no enforcement of them.
77
77
To reiterate: even if a "grouping" "looks like" a Mixxx group, it is not.
@@ -88,7 +88,7 @@ Similar to "grouping", keys bear no relation to equivalent Mixxx keys.
88
88
89
89
The shift button on the left side of a Traktor S4MK3 would be stored this way:
90
90
91
-
psuedocode:
91
+
pseudocode:
92
92
93
93
`sharedData["S4MK3"]["deck1"]["shift"] = true`
94
94
@@ -130,7 +130,7 @@ There is no effect (no logging or error) If a controller does not implement this
130
130
131
131
### Possible future directions
132
132
133
-
The following are possibile future extensions to this proposal that are currently out of scope and will not be implemented in the first version, but we want to make sure to leave room in case we add them in the future:
133
+
The following are possible future extensions to this proposal that are currently out of scope and will not be implemented in the first version, but we want to make sure to leave room in case we add them in the future:
0 commit comments