Advanced Mapping for the Behringer CMD MM-1

[Swiftb0y]

This is my proposal for a more complicated mapping of the CMD MM-1
Its not 100% done yet, for example the reset rate function doesnt work (probably because of the overuse of engine.softTakeoverIgnoreNextValue) and there are still free spots in some higher layers where features could be mapped.
Wiki: https://www.mixxx.org/wiki/doku.php/behringer_cmd_mm-1_advanced_mapping

Hope I can get some good feedback from a couple of people

[Be-ing]

Move these all the way to the top and use camelCase instead of ALLCAPS.

[Be-ing]

Thanks for submitting this. I think we could have one mapping for this controller that covers all use cases with different options. Could you make it so each column can be individually configured for any effect unit or deck? What do the effect unit assignment buttons and faders do when the knobs are configured for effects?

[Swiftb0y]

Could you make it so each column can be individually configured for any effect unit or deck?

I can try but it might get a little confusing. I thought I could use the third layer for this: the 1&2 buttons are used as bits to get numbers from 0 to 3 and the cue buttons define if the channel is used for controlling a deck or a EffectUnit.

What do the effect unit assignment buttons and faders do when the knobs are configured for effects?

Instead of being mapped to [High,Mid,Low,Quickeffect] of the corresponding channel, they are mapped to [Meta1,Meta2,Meta3,Mix] of the corresponding FxUnit.

I think we could have one mapping for this controller that covers all use cases with different options.

I dont think that works because mevsme made his mapping to be used with the rest of the modular CMD controllers, while my mapping is supposed to be used with the Launchpad Mapping (PR will come soon).
Ive mapped most of the functionality the PL-1 and DV-1 provide onto the MM-1 so my mapping only makes sense when used with a grid-based controller like the Launchpad.

[Be-ing]

I can try but it might get a little confusing. I thought I could use the third layer for this: the 1&2 buttons are used as bits to get numbers from 0 to 3 and the cue buttons define if the channel is used for controlling a deck or a EffectUnit.

I meant making it configurable with options at the top of the script. I don't think there's a reason to make it configurable from the controller.

Instead of being mapped to [High,Mid,Low,Quickeffect] of the corresponding channel, they are mapped to [Meta1,Meta2,Meta3,Mix] of the corresponding FxUnit.

Yes I see that on the wiki. But what about the effect unit assignment buttons and fader below the knobs when the knobs are controlling an effect unit?

I dont think that works because mevsme made his mapping to be used with the rest of the modular CMD controllers, while my mapping is supposed to be used with the Launchpad Mapping (PR will come soon). Ive mapped most of the functionality the PL-1 and DV-1 provide onto the MM-1 so my mapping only makes sense when used with a grid-based controller like the Launchpad.

If the mapping supports configuring each column individually for a deck or effect unit, I don't think there's any reason it couldn't be used by itself.

[Swiftb0y]

I meant making it configurable with options at the top of the script. I don't think there's a reason to make it configurable from the controller.

xd to late. PR pushing it this evening...

Yes I see that on the wiki. But what about the effect unit assignment buttons and fader below the knobs when the knobs are controlling an effect unit?

The dont have anything to do with the assignment of the buttons. so they are still controling fx1&2, orientation and fx3&4.

If the mapping supports configuring each column individually for a deck or effect unit, I don't think there's any reason it couldn't be used by itself.

It can be used by itself of course, but most people will probably buy it because they want to add the stuff the launchpad cant do or because they already bought the other stuff from the CMD-series (in which case the mapping by mevsme would be better because its simpler and the whole fx functionality gets already provided by another controller). But if the want the freedom of reassigning the knobs they can still use my mapping. Some features might just be implemented twice.

[Swiftb0y]

This push updates the whole mapping to have two different modes for every Channel:
Deck-mode (as you expect)
and Fx-mode (controls the fxUnits)
You can also update the channel assignment at runtime.

Quick manual until I update the wiki:

Deck-mode controls are the same, But when you are in the thirdLevel (shift+ctrl) you can toggle the channel between Fx- and Deck-mode with the Cuebutton and reassign the channel 1&2 (they are (sort of) binary encoded so [0,0] = 1,[1,0] = 2,[0,1] = 3,[1,1] = 4).

In Fx mode:
CUE:

• normal: pfl
• shift: master
• ctrl: toggle effect 3
• third: same in Deck-mode (toggle channel mode)

1&2:

• normal: Enable FxUnit 1&2 for effect according to UnitNumber (not the best, ill find something better, maybe)
• shift: Enable FxUnit 3&4 for effect according to UnitNumber (not the best, ill find something better, maybe)
• ctrl: toggle Effect 1&2
• third: same as Deck-mode (change channel number)

[Be-ing]

In case you missed it, we've decided to release Mixxx 2.1 beta on 12/22/2017. I'll get back to reviewing controller mappings to be included in the 2.1 release after the beta is released.

[daschuer]

@Be-ing: Nit: 12/22/2017 date format is ambiguous around the world and especially between UK and US. Use 2017-12-22 (ISO 8601) which is not.

[Swiftb0y]

I just double checked this mapping for bugs, which I was not able to find any of. If there are no obvious design flaws, this mapping is ready to be included in 2.1
The only problem that would have to be solved is the fact that there is another simpler mapping already by mevsme proposed.

[Be-ing]

I will get to reviewing this soon, but for now I will be taking a break from development and code review for a few days.

[Be-ing]

@Swiftb0y, @mevsme: I read the wiki pages for both your mappings and I'm a bit confused. It looks like this mapping from @Swiftb0y is mostly the same by default and adds other options for effects? The only major difference I can tell are the two knobs in the top left of the controller. Considering the effects columns already have the mix and superknobs mapped, I think it would make most sense to change this mapping to use the top left knobs for the master gain and balance like @mevsme's mapping then merge just this one. What do you think?

[Swiftb0y]

Yeah. That sounds like a good idea, but I'm on vacation right now, I'll try to get around changing its this week. And I'm not comfortable with it until I tested it again.
Can you name a more concrete deadline, since I have a half finished mapping for the N4 as well?

[Be-ing]

We're doing the release candidate on Tuesday April 3. If you can't do it before then maybe @mevsme can?

[Swiftb0y]

I'll change the buttons until tomorrow but there are some minor known bugs (as pointed out in the wiki).

[Be-ing]

Considering this controller does not have buttons for the effect enable switches, I suggest setting all the effects for the effects units that are mapped on the controller to enabled and set the effect unit's mix knob to 0 (fully dry) in the init function. That should avoid situations like what I described in #1103.

[Be-ing]

Looks like you forgot CMD before DMM.out.

[Be-ing]

Shouldn't this go before FUNCTIONS.enableSoftTakeover();?

[Swiftb0y]

Sorry yeah, I forgot this matters. Can you change it?

[Swiftb0y]

I think i fixed everything in the newest commits.

[Be-ing]

Ah, sorry I didn't read the wiki close enough. I see now that the mapping does actually allow for controlling the enable buttons of the effects, so this isn't needed. I'll take care of it.

[Swiftb0y]

Oh, I thought you had an issue with mixxx being out of sync with the FX buttons.

[Be-ing]

I rebased this on the 2.1 branch, removed the accidentally committed Launchpad mapping, and removed "Advanced" from the name of the mapping. I merged the contents of the https://www.mixxx.org/wiki/doku.php/behringer_cmd_mm-1_advanced_mapping and https://mixxx.org/wiki/doku.php/behringer_cmd_mm-1 wiki pages so there is only one wiki page users need to refer to (the latter one). I also edited and reformatted the contents of the wiki. Please look over the wiki page and make sure that it's all still accurate.

Whenever someone gets a chance, please test the 2.1 branch with a CMD MM1 to confirm that I didn't mess anything up in the process.

Also, I recommend changing the behavior of the buttons in the effect mode so that the effect enable buttons are controlled without any modifiers. It is more useful to have quick access to those than the deck routing buttons.

[Swiftb0y]

Unfortunately, I won't have access to my MM1 until next week, but I contacted Behringer about the missing product page and channel switcher tool.

[Swiftb0y]

Also, I recommend changing the behavior of the buttons in the effect mode so that the effect enable buttons are controlled without any modifiers. It is more useful to have quick access to those than the deck routing buttons.

I don't know how you would imagine this to work since there are only two buttons available. So deck 1&2 can already be assigned without any modifiers but I have to use shift to make the other ones accessible. I was thinking that doesn't really matter when using the whole controller in two-deck mode (two decks & two fxUnits). I didn't intend for people to change the channelmode very often (The FxUnit Mode is only there so the possible extra controls get wasted when someone just uses two decks).

[Be-ing]

I don't know how you would imagine this to work since there are only two buttons available.

Use the CUE button as the third effect enable button. The PFL routing switch on effect units is only for the case of previewing how effects will sound in headphones on a track that is already heard by the audience on the master output.

[Swiftb0y]

Yeah, but this will only cover the third deck. I think if people use the third deck, the fourth will be used as often as the third, so why would we "exclude" (would still be accessible over shift) it?
And I think the pfl'ing the effect is quite useful sometimes.

[Be-ing]

It seems you misunderstood what I suggested. I am suggesting to make the default behavior of the buttons in effect mode control the enable button for each effect in the unit, not the routing buttons that control which decks the effect unit is active on. In other words, swap the default and Ctrl behavior of the buttons.

[Swiftb0y]

ohh, yes I missunderstood. Ill switch those controls, but I'm a bit confused about how:
So you rebased the commits for the mapping and they are now where?

[Be-ing]

The commits are now in the 2.1 branch. So if you want to continue working on this now, checkout the 2.1 branch (git checkout upstream/master, assuming you have already done git remote add upstream https://github.com/mixxxdj/mixxx.git), then start a new branch from there (git checkout -b new_branch_name). Note that I renamed the files to remove the word "Advanced".

https://xkcd.com/1597/

[Swiftb0y]

checkout the 2.1 branch (git checkout upstream/master)

Wait, so are they on the master or the 2.1 branch??

[Be-ing]

I just merged the latest updates from the 2.1 branch to the master branch, so your commits are in both now. If you want to make more changes to go into the 2.1 release, start from the 2.1 branch (otherwise I'll have to rebase your pull request again instead of just pressing the merge button on GitHub's website).

[Swiftb0y]

ok, ill use the 2.1 branch, thank you.