Pioneer DDJ-FLX4: New mapping base on DDJ-400

[Robert904]

Mapping for the Pioneer DDJ-FLX4 controller.

It has been based on the DDJ-400, adapting some part to the new layout and buttons.
Mostly the FX part has been adapted and the lights indication the performance pad mode.

Separate PR for the manual is also proposed

[JoergAtGithub]

Please fix the pre-commit issues. Either by setting up Pre-Commit on your system: https://github.com/mixxxdj/mixxx/wiki/Using%20Git
or by downloading the pre-commit.patch artifact of this build:

[JoergAtGithub]

The remaining pre-commit (eslint) issues can't be fixed automatically. Please have a look at the error messages!

[JoergAtGithub]

Please add a comment, which explains the calculation of idx

[JoergAtGithub]

Suggested change

	<author>Warker/nschloe/dj3730/jusko/Robert904</author>
	<author>Warker/nschloe/dj3730/jusko/Robert904</author>

Just mention the author of this mapping - it's enough to mention, that it's based on the DDJ-400

[JoergAtGithub]

Welcome and thanks for improving this! Please sign the Mixxx Contributor Agreement and comment here when you have done so. It gives us permission to distribute your contribution under the GPL v2 or later license and the Apple Mac App Store. It is also helpful for us to have contact information for contributors in case we may need it in the future.

[Robert904]

Welcome and thanks for improving this! Please sign the Mixxx Contributor Agreement and comment here when you have done so. It gives us permission to distribute your contribution under the GPL v2 or later license and the Apple Mac App Store. It is also helpful for us to have contact information for contributors in case we may need it in the future.

Just did it

[Zecken1]

Effect on/off button doesn't work on deck 2. I can either use deck 1 or 1&2, but if set to deck 2 then the on/off is without effect.

Do you experience the same issue?
Any idea how to address that behavior?

[grizeldi]

I did some extensive testing, going through all the bindings explained in the PR to the manual one by one, as well as playing a set or two using the binding and here are my findings. Do note I'm primarily a Rekordbox user and this is my first time dealing with mixxx, so in some cases the problems outlined might be caused by user error.

Tested with Mixxx 2.3.3 on Ubuntu 22.04.1 LTS 64 bit using JACK as the audio backend chosen in Mixxx, though the actual sound system used was pipewire.

Directly binding related

Problems/bugs

• VU meter colors don't really match what's being displayed in mixxx. I'm never redlining in mixxx, yet the red light on the controller is on almost all the time. Some form of remapping might be needed.
• As @Zecken1 pointed out, the FX refuses to turn on or off when set to only deck 2
• Loop IN and OUT buttons don't behave as described in the documentation. The documentation says "If held during an active loop, sets the new start/end point when released." Instead what happened was that it got repeatedly set as long as I held the button down.

Suggestions

• Selecting the FX channels 1-3 directly using the left/right/down buttons in the beat FX section of the controller feels a bit weird. Personally I think it would feel a lot better if you could use the left/right buttons to select the desired FX channel (1-3), moving the focused channel left or right and then use the down button to select the desired effect. Having to use shift + down to change effects is a bit cumbersome.
• The sampler button bindings make no sense. If the user is using a 16 sampler skin, there's no reason it shouldn't be mapped 1:1. Right now if I try to activate the bottom right sample on the left deck, it will instead activate the rightmost sample in the first row of samplers inside Mixxx, which makes it quite counter intuitive.

Headphone cueing and MIDI

The problems described here probably aren't directly caused by the mapping, but definitely impact the experience using the controller in negative ways.

• Jog wheels feel floaty. Like realy floaty, there's too much delay between when I move the jog on the controller and when Mixxx actually moves the tracks. To the point it made scratching impossible to pull off in the rhyhtm and made manual beat matching rather annoying.
• This one is minor, but the entire time it was being used, my controller was in bluetooth pairing mode. Since it doesn't do that in Rekordbox, I assume a "you're connected now, stop searching" type message is missing from Mixxx when connected.
• Not sure whether this is a hardware limitation, but anything to do with getting the master channel to the headphones was a mess, especially when I wasn't using the controller's output as master out. In that case the cue button for master straight up didn't work.
• Headphones mix knob which is supposed to determine the balance between the cue and master channel was behaving weirdly, no matter whether the controller was used as master out or not. When the knob was all the way to the CUE setting, it was working as expected, as well as in the MIX position. However, turning it towards MST did nothing, but fade everything out. When fully in the MST position, I had silence in the headphones.

[JoergAtGithub]

You merged the Main branch into this PR, which is targeted for branch 2.3.
Target branch 2.3 is the correct one for mapping PRs.

[Robert904]

You merged the Main branch into this PR, which is targeted for branch 2.3. Target branch 2.3 is the correct one for mapping PRs.

Sorry, new to github and PRs, I made a wrong click in my branch :-(
Not sure how to revert that...

[Swiftb0y]

Not sure how to revert that...

Somewhat depends on how you manage your branch, if you use the git cli locally, you can reset it using this:

git pull # make sure your local branch matches the remote
git reset --hard 8107365a939916aa0525e6cb4b6b161d2dbd82c1 # reset the branch tip to the last intentional commit from you I found
git push --force # forcefully update your branch on github, while you should normally never use --force, its required here since we want to "undo" parts of the commit history (only ok in this specific case)

[Robert904]

• VU meter colors don't really match what's being displayed in mixxx. I'm never redlining in mixxx, yet the red light on the controller is on almost all the time. Some form of remapping might be needed.

Indeed, the source mapping was multiplying a value between 0 and 1 by 150, while the max on the console is 127...
Now it seems to match better the app one

• As @Zecken1 pointed out, the FX refuses to turn on or off when set to only deck 2

I found that one.

In addition, I see a behavior inherited from the code of the DDJ-400 that I find surprising.
shift-ON/OFF turn off all the active FX channels, but at the same time turn to MIX knob to 0... Is it desirable ? I could remove that behavior !

• Loop IN and OUT buttons don't behave as described in the documentation. The documentation says "If held during an active loop, sets the new start/end point when released." Instead what happened was that it got repeatedly set as long as I held the button down.

Somehow, even if the loop start/end is repeatedly moved to the current playing position while the button is pressed, it still provides the documented behavior as I understand it... The loop is not applied anymore while pressing and you have a visual clue of where the start/end will be set when you release...

• Selecting the FX channels 1-3 directly using the left/right/down buttons in the beat FX section of the controller feels a bit weird. Personally I think it would feel a lot better if you could use the left/right buttons to select the desired FX channel (1-3), moving the focused channel left or right and then use the down button to select the desired effect. Having to use shift + down to change effects is a bit cumbersome.

I agree on that one, but beeing a complete newbie on such console I wanted to stay close to the behavior if the DDJ-400, so I just change the order of the buttons to reflect the new layout of the console. I'll try to change that later...

• The sampler button bindings make no sense. If the user is using a 16 sampler skin, there's no reason it shouldn't be mapped 1:1. Right now if I try to activate the bottom right sample on the left deck, it will instead activate the rightmost sample in the first row of samplers inside Mixxx, which makes it quite counter intuitive.

You're completely right, should be better now

• Jog wheels feel floaty. Like realy floaty, there's too much delay between when I move the jog on the controller and when Mixxx actually moves the tracks. To the point it made scratching impossible to pull off in the rhyhtm and made manual beat matching rather annoying.

Connected on USB (windows, MIXXX 2.3.4), I don't feel any delay, for what I'm able to judge, it react instantly...

For the hardware channels, I'll do some tests t see if I have such behavior as well...

[grizeldi]

Tested on Windows10, 64bit, Mixxx v2.3.4 as well.

VU meters now work nicely, as well as channel 2 FX. Didn't test samplers because I can't be bothered setting my fragmented library back up on Windows. The problem of floaty jogs sadly remains though, but I have narrowed it down to the edge nudge being floaty, while touching the top surface is rather responsive.
I don't have another controller to compare it to in Mixxx, but it might be just me being used to how Rekordbox does the nudging and Mixxx does it differently, making it a bit hard to manually beat match.

[Robert904]

That part comes directly from the ddj-400 mapping, I'll try to compare Pioneer's documentations to see if something has changed between the 2 models...

[wesleyote]

In Pioneer-DDJ-FLX4-script.js, this code yields what I think is more intuitive behavior for selecting effects within FX unit 1:

PioneerDDJFLX4.beatFxLeftPressed = function(_channel, _control, value) {
    if (value === 0) { return; }

    switch (engine.getValue("[EffectRack1_EffectUnit1]", "focused_effect")) {
        case 1:
            engine.setValue("[EffectRack1_EffectUnit1]", "focused_effect", 3);
            break;
        case 2:
            engine.setValue("[EffectRack1_EffectUnit1]", "focused_effect", 1);
            break;
        case 3:
            engine.setValue("[EffectRack1_EffectUnit1]", "focused_effect", 2);
            break;
    }
};

PioneerDDJFLX4.beatFxRightPressed = function(_channel, _control, value) {
    if (value === 0) { return; }

    switch (engine.getValue("[EffectRack1_EffectUnit1]", "focused_effect")) {
        case 1:
            engine.setValue("[EffectRack1_EffectUnit1]", "focused_effect", 2);
            break;
        case 2:
            engine.setValue("[EffectRack1_EffectUnit1]", "focused_effect", 3);
            break;
        case 3:
            engine.setValue("[EffectRack1_EffectUnit1]", "focused_effect", 1);
            break;
    }
};

The selected effect will now cycle when pressing the beat FX left and beat FX right buttons.

PioneerDDJFLX4.beatFxSelectPressed can now be used for something else.

[JoergAtGithub]

The selected effect will now cycle when pressing the beat FX left and beat FX right buttons.

According to PioneerDJs DDJ FLX4 manual, this should be the functionality of the FX SELECT button:

• Pressing FX SELECT should select the next effect
• SHIFT + FX SELECT should select the previous effect

We should only alter the functionality of buttons, where Mixxx functionality differs from the original DJ software.

This is the case vor the BEAT < and > buttons. Here is Mixxx missing a feature to map the original functionality.

[Robert904]

Rebased to 2.4

[Robert904]

Applied the proposed ES6 style patch... Strange that my local pre-commits did not stopped me from pushing the previous one !

[Swiftb0y]

I have a personal interest to see this merged soonish. The code is abhorent as usual with the mappings copy-pasted together from old code, but thats the fault of the DDJ-400 mapping this is based on. @JoergAtGithub can we merge or do you have any unresolved comments that would justify blocking for now?

[JoergAtGithub]

I've not reviewed the latest code. @Swiftb0y Feel free to merge it, if you think everything is fine!

[Swiftb0y]

Yup, new code is about same quality as old code. Couldn't spot any obvious bugs.

[rjohnsonbade]

Hello, just came across this PR.

Should it have included changes to update the list here, https://github.com/mixxxdj/mixxx/wiki/Hardware%20compatibility ?

I was looking for Mixxx + FLX4 compatibility and was disappointed that it wasn't on that list.

[Swiftb0y]

That list has gotten quite unmaintained. For a more comprehensive list of mappings included in mixxx in a particular version, refer to the corresponding manual section. https://manual.mixxx.org/2.4/en/hardware/manuals

[rjohnsonbade]

Ah great, thanks for the reply and link.

[daschuer]

Hi @Robert904, I am currently adding the missing 2.4 contributors to the contributor list in the Mixxx about box. Which name should I use for your? Your real name?

[Robert904]

Hi!
Sorry, your email went to the spam, I just found it now...
It can be my real name (Robert Hendrickx) or my github user, whatever is the standard practice...
Many thanks

[Swiftb0y]

Hey there @Robert904. Can you do me a quick favor and look into #12622, do you have any idea what the culprit of the issue could be? I'm not super familiar with the DDJ hardware, so I'm hoping you might know more. Thank you.

[Robert904]

I'll try to take a look during the weekend

[grizeldi]

I'll take a look, though I'm still not sure what precisely is supposed to be wrong, even after reading the entirety of that not overly informative conversation.

[grizeldi]

While testing #12622, I noticed that master level knob on the mixer section doesn't seem to be affecting the master level knob in mixxx 2.4. Should I open a new issue for that?

[Swiftb0y]

I think thats intended because that master knob is controlling the hardware gain afaik. If that same knob would also mess with mixxx's gain, that would make the gain overly sensitive. Also, good gain-staging practice is to leave all gains at 0dBFS (I think, not good with db scales) and then only use the last stage (the hardware gain on your mixer likely) to actually set the volume. Not mapping the gain knob only applies when that knob is influencing the hardware already, so it would be nice if you could confirm that that is actually the case.

[grizeldi]

I see, I wasn't using the FLX4 as any of the audio outputs, which is probably why it bothered me that the knob fidn't move in Mixxx. Is it possible for the mappings to be conditional? Something like "if (usingFLX4asOutput) disableMapping();"? I'll test tomorrow if the master gain works in hardware.

[Swiftb0y]

Is it possible for the mappings to be conditional?

yes, with a little bit of extra javascript, quite easily. Though we generally discourage it. The problem is so common that implementing the same switch for each mapping is tedious and repetitive. We need a general solution. It's just that nobody has come up with it yet.

I can see how that is annoying for you, so I'm happy to provide you with a little snippet that enables that functionality if you can tell me what the midi messages sent by that knob (channel and control).

[grizeldi]

I've tested the master gain knob and discovered that we have an inconsistency in the mapping. Both master and headphone gain knobs seem to do their job in hardware, as they work even if I delete the relevant bindings that move the knobs' Mixxx counterparts. Yet as discussed above, the master gain knob isn't mapped, while the headphone gain knob is mapped to its Mixxx counterpart, making it quite sensitive (though part of that is also the fault of my low impedance headphones).
For the sake of consistency we should probably either map both knobs or none of them, as the current implementation is a bit confusing.

@Swiftb0y Pioneer's official MIDI table says the MSB is transferred in MIDI channel 7, CC 8, while the LSB is transferred in MIDI channel 7, CC 40.

Output of aseqdump -p $FLX_PORT > knob.txt while I moved the knob from 0 to about half and back: knob.txt.

---

Ubuntu 23.10, 64 bit
Mixxx 2.3.6 from the official launchpad PPA
ALSA audio backend

[Swiftb0y]

For the sake of consistency we should probably either map both knobs or none of them, as the current implementation is a bit confusing.

Yeah, in that case it'd probably make sense to map none and then just set the headphone knob to headphone on mapping init. Are you interested in submitting a PR for that?

@Swiftb0y Pioneer's official MIDI table says the MSB is transferred in MIDI channel 7, CC 8, while the LSB is transferred in MIDI channel 7, CC 40.

Thank you, so you can add back the master knob controlling by adding the following to the mapping (presumably in ~/.mixxx/)

<control>
            <control>
                <group>[Master]</group>
                <key>gain</key>
                <status>0xB6</status>
                <midino>0x08</midino>
                <options>
                    <fourteen-bit-msb/>
                </options>
            </control>
            <control>
                <group>[Master]</group>
                <key>gain</key>
                <status>0xB6</status>
                <midino>0x28</midino>
                <options>
                    <fourteen-bit-lsb/>
                </options>
            </control>

[grizeldi]

Thanks for the mapping. I'm a bit hesitant to dive into a new codebase as big as Mixxx, especially as I have no clue about c++, but if it's only the binding's javascript parts, I believe I could handle making the PR. However, if I'm already going to be working on the mapping, I got a few other improvements in mind, most notably sending the sysex that lets the controller know it's connected to something so it exits the bluetooth pairing mode.

Could you elaborate a bit on the "and then just set the headphone knob to headphone on mapping init" part? When the mapping gets initialized, read the knob state and sync harware knob with software one, but then ignore the CC messages for it afterwards?

[Swiftb0y]

Could you elaborate a bit on the "and then just set the headphone knob to headphone on mapping init" part?

Sure, I just meant to do an engine.setParameter("[Master]", "headMix", 0); to make sure the headphone channel within mixxx is actually sending the headphone signal, not the main channel. Otherwise inexperienced users might get confused. That would happen in the PioneerDDJFLX4.init function.