Xone K2 effects mappings

Bug #1733218 reported by Be
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Medium
Be

Bug Description

We have a 4 deck mapping for the Allen & Heath Xone K2. We should have a 2 decks + 2 effect unit mapping as well as a 4 effect unit mapping.

Be (be.ing)
Changed in mixxx:
milestone: none → 2.1.0
Be (be.ing)
Changed in mixxx:
importance: Undecided → Medium
assignee: nobody → Owen Williams (ywwg)
Revision history for this message
Owen Williams (ywwg) wrote :

I've started refactoring the make_xone script to do this work. I am not sure what the best way is to map the effects units.

The xone has multiple configurations for how to configure the "layers." Depending how it's configured (hardware-side), the xone can either have three layers for just the buttons, or for all of the controls. For the original mapping, I have the user put the xone in the mode in which the just buttons at the bottom of the device can have three different functions depending what page the device is on.

But for FX, I could imagine using the mode where the knobs do different things on different pages. If each column is a separate effect unit, I'm thinking of mapping like this:
Red Page: Each knob is the Meat knob for each effect
Orange Page: Knobs are individual parameters for effect 1 of the chain
Green Page: Knobs are individual parameters for effect 2 of the chain

As for buttons:
Red Page: Enabling per-deck
Orange Page: Enabling per effect?
Green Page: ???

(We could also repeat bindings so every page has the same bindings for the buttons)

Sliders: dry/wet mix on all pages
spin knobs: chain selection

When doing 2 deck 2 fx I'll have to dupe all of the knobs on all the pages so the decks behave predictably.

(I could also imagine setting it up so that the whole Xone operates a single effect unit)

Revision history for this message
Owen Williams (ywwg) wrote :

Meat knob -> mix knob. Not sure where that typo came from!

Revision history for this message
Be (be.ing) wrote :

> I've started refactoring the make_xone script to do this work.

I don't understand what the point of this is. This nonstandard extra layer of complexity makes it harder for someone else to modify the mapping.

Do you know what configuration the Xone comes with out of the box? Ideally the Mixxx mapping should be plug and play with that.

> I could imagine using the mode where the knobs do different things on different pages

That would work if there were 4 colors available, but not having access to the parameters third effect in the chain is not good.

> spin knobs: chain selection

In the future when saving and restoring chains is implemented, that would be useful. But in 2.1 this will not do anything so I don't think it should be mapped.

> I could also imagine setting it up so that the whole Xone operates a single effect unit

Yeah, someone may want to do that, but it seems pretty overkill.

Revision history for this message
Be (be.ing) wrote :

Using the 3 colors available for the buttons adjacent to the knobs to indicate which effect is focused could work if the bottom buttons are used for the effect enable buttons. In that case, a separate page of the bottom buttons with a different color could be used for the deck assignment switches.

Revision history for this message
Be (be.ing) wrote :

> Using the 3 colors available for the buttons adjacent to the knobs to indicate which effect is focused could work if the bottom buttons are used for the effect enable buttons.

Hmm, that would only work if it the unfocused state was clearly distinguished from the focused states. Maybe unfocused could be represented by turning those LEDs off.

Revision history for this message
Be (be.ing) wrote :

Perhaps the top encoder could be used to cycle the focus through the 3 effects and the unfocused state.

Revision history for this message
Owen Williams (ywwg) wrote :

> I don't understand what the point of this is. This nonstandard extra layer of complexity makes it harder for someone else to modify the mapping.

This controller has 108 controls and almost as many lights and configuring it manually would be incredibly error-prone without using the helper script. And because you want 2 more configurations, that's that's 324 configurable controls that all have to be right. Regardless, the output of the script is standard xml so I don't even understand what getting rid of the script would improve with respect to others editing the mapping. Has someone actually asked about modifying the xml and felt scared away by the script? If not then I don't understand what relevance this question has even being here in this bug.

It makes me feel shitty to have your very first question be questioning my choice of development method.

Revision history for this message
Be (be.ing) wrote :

Okay, that makes sense. I apologize if that question felt offensive. I have been frustrated to see people implement ad-hoc systems like the make_xone.py script instead of working on improving the mapping system to make it easier for everyone. I think the reasoning behind the make_xone.py script is a good example of why the XML mapping system should be phased out and an all JS system should be implemented. Writing thousands of lines of XML code with copying and pasting and hand modifications is error prone and cumbersome. https://github.com/mixxxdj/mixxx/pull/1402 is a case in point.

> Has someone actually asked about modifying the xml and felt scared away by the script?

I haven't seen anyone ask.

Is it possible to send the Xone K2 MIDI messages to tell it to switch layers?

Revision history for this message
Be (be.ing) wrote :

I looked through the Xone K2 manual and it seems that the firmware's "Latching Layers" system cannot be configured to have different layers active on different columns or different layers active on the top knobs versus the bottom button grid. So implementing a mapping with either of those design features would have to be done in JavaScript without any "Latching Layers" system turned on.

Revision history for this message
Owen Williams (ywwg) wrote :

Yeah I understand why you want to avoid hacky things like the make_xone script. But please keep in mind that I completely burned out on Mixxx and after two years I finally feel ready to dip my toe into contributing again. I picked this task because it's an easy lift and self-contained. I don't have the stamina right now to rethink how this controller is mapped. What I feel I can do is work with the script as-is and try to write support for effects.

Revision history for this message
Be (be.ing) wrote :

If you don't want to design a whole new effects mapping, then you can use the EffectUnit object from the Components library which we've spent almost 2 years designing. That was designed for controllers that have effect buttons that can only show a single color with their LEDs. It may be possible to design a new mapping that takes advantage of the Xone K2's multicolor buttons, but that would be a lot of work and might not end up working out so well considering it can only show 3 colors (4 colors would make it easier).

Repeating from my email:

https://mixxx.org/wiki/doku.php/components_js#effectunit
Use the fader for the dryWetKnob. I think it would make most sense to use pressing the top encoder for the effectFocusButton and use the LED below the encoder for the effectFocusButton's output. I don't know what to suggest to map for turning the encoders. The buttons below the faders could be used for enableOnChannelButtons.

Revision history for this message
Be (be.ing) wrote :

I just got two of these controllers so I'll make an effects mapping.

Changed in mixxx:
assignee: Owen Williams (ywwg) → Be (be.ing)
Revision history for this message
Be (be.ing) wrote :
Changed in mixxx:
status: New → In Progress
Be (be.ing)
Changed in mixxx:
status: In Progress → Fix Committed
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8983

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.