M-Audio Xponent, advanced mapping

[MelGrubb]

This is an advanced mapping for the Xponent. It fully utilizes all of the controls and lights to the point that I think the Xponent has more functionality than many larger more expensive controllers.

This mapping is compatible with Mixxx 2.0, and does not use the Components framework yet. It has been fully documented on the wiki, and the files are available on the forums already.

[sblaisot]

Please add the two files to windows NSIS uninstaller: https://www.mixxx.org/wiki/doku.php/contributing_mappings#windows_installer_update

[MelGrubb]

The PR has been updated. It's a good thing too. The previous commits in this PR were not correct. The real work had been on a different branch altogether. They've been pulled to master now. This is very nearly a complete rewrite of the original mapping.

[Be-ing]

Will look through this in more detail soon, but here are a few quick things I noticed.

[Be-ing]

This should be connected to play_indicator, not play.

[MelGrubb]

changed to play_indicator

[Be-ing]

There should be a callback function connected to changes in cue_indicator.

[MelGrubb]

I have eliminated this. There was no need for scripting as the XML mapping is adequate for the cue button.

[MelGrubb]

I could map this in script, but the only thing I would gain is the ability to turn the led on and off if you held down the button while switching banks (1&2 to 3&4), but you'd still have the light turn on when you switch back, so it could still get out of sync possibly, and the cue button is only ever momentary anyway. It didn't seem worth the trouble. At this point, Cue, and seek fwd and back are the only things still handled by the XML, which seems adequate to me.

[Be-ing]

I apologize for the delay in reviewing this. Your code looks about as neat as it can for Mixxx 2.0... but we're not releasing any 2.0.x. Are you going to update this for 2.1?

[Be-ing]

There should be a way to enable master sync (sync_enabled control). If you want to keep bpm_tap on the shift action of this button, you could do it like the GUI and make a long press activate sync_enabled.

[MelGrubb]

I can see that. Unless a long-press is handled by the engine, I'm not sure I'd want to do that in the script. I don't want javascript responsible for polling, timing, any of that. I could change the shift-sync behavior, and reassign the tap behavior, but it seems that it doesn't work anymore anyway, even from the UI. If a track has existing bpm information, it won't listen to the tap, so I 'll just repurpose the button.

[MelGrubb]

I've updated this so that shift-sync toggles sync_enable for the corresponding deck.

[Be-ing]

#1082 added a track_loaded control specifically for this that will be in 2.1.

[MelGrubb]

I saw that. It's just not available to 2.0, which I still need to use as a "daily driver" until 2.1 is stable.

[Be-ing]

These probably aren't working because you're using the deprecated aliases. Since 2.0 the EQs are special effects racks.

[MelGrubb]

The effects themselves work fine, it's just the soft takeover that doesn't work. In 2.0, soft-takeover won't work for parameters, only values. That's fixed in 2.1, where this code should work. There's still the problem of doing a soft takeover for controls that are now on the wrong "side" of the current value though. I don't see a way around that, and I tried a few things to no avail.

[MelGrubb]

As a general comment. I don't see a problem with maintaining a 1-version backwards compatibility for now. That means that I can't use track_loaded, but I have a workaround for that anyway, so we're fine there. In general, it doesn't seem like 2.1 is quite ready for me to play with yet. I had numerous problems with deck 3 (and only deck 3) acting funny with the same script I was using just fine in 2.0. There were some other oddities as well. I'll update the script for 2.1, but I'll need to try it with a more recent build first. There's some beautification to be done as well, which I may undertake before updating the PR. The functions are more or less in order of convenience, with no real scheme to their order. I'll fix that up as well, and just alphabetize them somewhat.

[Be-ing]

As a general comment. I don't see a problem with maintaining a 1-version backwards compatibility for now.

The main issue is that it can't really be forwards compatible with the new effects UI because that didn't exist before. The old controls still exist, but they're laid out much differently so any effects mapping made for 2.0 will be awkward with 2.1 (and they were all awkward for the 2.0 skins they weren't designed for). As far as I'm concerned that's the only part of the mapping that needs to be updated for the 2.1 release. If you want to rewrite the script with Components, cool, but you don't have to rewrite the whole script to use Components for the effects.

[Be-ing]

By the way, your code is neat and easy to read. :)

[MelGrubb]

I'll try to find a more recent Windows build and see what I can do this weekend. In the alpha version I had, I wasn't really getting how the new effects framework, or at least its UI, works. I had a lot of other problems with it too. I think there are more recent Windows nightlies to look at, so I'll see if it's any different now since I haven't had any luck getting a build environment up and running yet. Thanks for the comment. Code is like whittling. The longer I work on something, the smaller it gets. I have some linting to do, and some more dead code to eliminate. I'll probably put the init code in a little better order as well. I'll probably pull off my own 2.0 branch just to maintain it for personal use until 2.1 is released, and I'll start looking at porting it to the Components framework on a separate branch as well.

[Be-ing]

So far only the Deere skin and the new Tango skin (#1151) have been updated for the new effects UI.

Code is like whittling. The longer I work on something, the smaller it gets.

Well said. :) It was really satisfying to see the Hercules P32 mapping shrink down to less than 500 lines of code as I developed Components.

[Be-ing]

Okay, this looks good to me for 2.0. Should we have two mappings for the Xponent or should this replace the old (Mixco) one? Is there a clear advantage of one over the other? If you update this one for 2.1 and the Mixco mapping does not get updated, I think this should be the single mapping for this controller. @arximboldi, thoughts?

[arximboldi]

I would happily update the Mixco one to 2.1.

The question is then about the features. From looking at the code and the documentation, it feels like both scripts are quite similar. Featurewise, both scripts cover at the moment most features. This newly proposed script support 4 decks via banks and Samplers (admittedly I had these planned for the other script but I am lazy 😄 ). The newly proposed script on the other hand does not seem to support browsing, using the track pad for effects, or spinpback. There are some differences that are a matter of taste (e.g. I bound to some effect knobs to the beatroll effect, while all effect knob in the new script seem to be used for effect racks).

From the point of view of performance and stability I can not judge until I try the new script.

I don't have a strong opinion, what do you people think?

[MelGrubb]

If anything, I think this would replace the old stock mapping. The Mixco mapping is also newer, but I don't know about how active its development is. It's a CoffeeScript-based framework that was used to make three different controller mappings, but I don't know if they were ever truly finished. Maybe it's advanced since I last looked at it, but I had some trouble with it.

This script partially supports browsing. Shift and the jogwheels moves the library selection (left-over from the original mapping) but I hadn't settled on a button to load the tracks. I wasn't sure whether this was heavily used functionality or not. I have never once used a controller to browse and/or load tracks... I don't get why anyone would. I mean, there's a fully-functional laptop right in front of you. The Xponent has its own trackpad and mouse buttons built-in, and I'm never without a mouse anyway. I'm already triple-redundant. If you think this is something people demand, then Shift-Play or Shift-Cue or something could be mapped to load. You're already holding the shift key to browse with the jog wheel anyway. Is there an established "standard" for this kind of thing that I should follow? I could try to make some kind of double-tap on the wheel gesture, but that seems a little weird to me.

Regarding backspin, I could easily implement multiple modes for the big minus button so users could choose between backspin and reverse. Again, that's personal taste. I have no use for a backspin myself.

I'd like to use the trackpad in midi mode for effects, but I'm not sure what to map it to. The first two parameters of the focused effect? I'd like to map it to some kind of Kaos pad-like functionality. I'm just not sure what to wire it up to. Any suggestions are welcome at this point.

This is my first mapping, so guidance is appreciated. I'm certainly open to doing more if there are any controllers that need done.

[MelGrubb]

Just a thought, would it be too weird to hold down the shift button, move the jogwheel using the touch-sensitive surface, and then release the shift while still touching the wheel to load? That seems a little weird to me, but just weird enough that you wouldn't do it by accident. Taking your finger off the wheel BEFORE releasing shift would do nothing. You'd have to let go of the shift button first. It's a thought. Maybe it could be controlled by a config setting at the top of the script like the other optional behaviors.

[arximboldi]

Hey @MelGrubb, I maintain Mixco and the the Mixco mapping and mostly I consider it done but I keep doing some maintenance to catch with Mixxx from time to time (or with improvements that I come up with when preparing for a gig 😄)

I agree that the trackpad and browsing was mostly just nitpicking. I consider the scripts to be functionally very similar.

I kind of like programming better in the Mixco framework and I like that it provides quite few guarantees about state consistency that I have seen other scripts to lack, testing facilities, that it uses direct mappings when possible, and that code is very terse. On the other hand, I concede that it is "another layer", requires extra tooling, and is a bit esoteric for people not familiar with web programming tools. Thus, an argument for using your version, is that it is more consistent with the other scripts, being maybe easier to dig in for novices.

So my veredict: I am not opposed to replacing the script with this version 😄 It looks like thorough and well done work. I am looking forward to trying it out, but sadly I won't be able to do it until April... Do as you guys prefer!

[MelGrubb]

Pushed more commits. Holding shift and tapping the wheel surface or pressing Cue will load the selected track into that deck. The duration of what's considered a "tap" is configurable at the top of the script. I also mapped shift-BigX to be spinback since it had no shifted function previously. This leaves the big minus button to be reverse/censor as it was before. I'll have to get to updating the effects mappings later this week,

[Be-ing]

This does not matter much, but IMO it is good practice to leave a trailing comma after the last key-value pair in an object literal. If you ever add more to that object literal, it's easy to forget to add that comma.

[Be-ing]

Personally I like to have shift + my cue button mapped to go to the beginning of the track (the start_stop ControlObject).

I do not know if you've seen this yet, but I have redesigned how the EffectUnit object in the Components library works in PR #1211. The public API only has a few small changes.

[MelGrubb]

You can blame the linter for the commas. I tend to treat code like a game, and I only "win" a file/class/method when my tooling has no more complaints. If I were working "without a net", then I'd probably not have noticed. As for the shift-cue, how is that different than the normal cue behavior? I'd like to have the controls follow the "majority rules" opinion. I think maybe a nice addition to the wiki might be a set of standards for what certain controls should do on all mappings. For instance, a shift-hotcue should delete that hotcue, etc. Basically a list of "if your controller has button X, it should do Y". I'd be willing to compile this and add it to the scripting/mapping section if there's some way to gather a majority opinion. I think having established standards would make it easier to move from one controller to another. They should be common sense for the most part.

After doing some more testing, the wheel surface tap actually works very well, so I may just leave that and remove the shift-cue mapping. I'll be looking into the effects mapping for 2.1 this weekend as well.

[Be-ing]

As for the shift-cue, how is that different than the normal cue behavior?

The cue point is often not at the start of the track, especially with Denon and Numark cue modes (personally I use Numark mode). But I still like to be able to jump to the beginning of the track.

I'd like to have the controls follow the "majority rules" opinion. I think maybe a nice addition to the wiki might be a set of standards for what certain controls should do on all mappings.

That is part of the point of Components. Most mapping authors shouldn't even have to think about it; just reuse code that's already there.

They should be common sense for the most part.

They're not common sense. When design is good, it feels like common sense, but it takes a lot of work to make it that good. My first mapping sucked. I can't even remember all the details of how to use it. It takes experience and months of trying different designs to figure out the best way to design and implement controller mappings, which is more reason why it should be abstracted away into a shared library. Programming is the easy part; designing is hard.

[MelGrubb]

That shift cue behaviour could also be handy when you've accidentally moved the cue point, which I do all the time. I'll add that in. On Mar 18, 2017 12:17 PM, Be <[email protected]> wrote: As for the shift-cue, how is that different than the normal cue behavior? The cue point is often not at the start of the track, especially with Denon and Numark cue modes (personally I use Numark mode). But I still like to be able to jump to the beginning of the track. I'd like to have the controls follow the "majority rules" opinion. I think maybe a nice addition to the wiki might be a set of standards for what certain controls should do on all mappings. That is part of the point of Components. Most mapping authors shouldn't even have to think about it; just reuse code that's already there. They should be common sense for the most part. They're not common sense. When design is good, it feels like common sense, but it takes a lot of work to make it that good. My first mapping<http://mixxx.org/wiki/doku.php/electrix_tweaker> sucked. I can't even remember all the details of how it works. It takes experience and months of trying different designs to figure out the best way to design and implement controller mappings, which is more reason why it should be abstracted away into a shared library. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1194 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABGZBxUPEaL6aBuF7onj9OP3Go3BIgoVks5rnAOJgaJpZM4MMcSw>.

[MelGrubb]

I think I've got the effect system locked down the way I like it. It's a 2-level focus system. The first is handled by the script, the second by the engine. It allows the user to drill down to lower levels of detail if they want. In normal mode, the buttons toggle the effect units, and the knobs manipulate their super-knobs. Holding shift and pushing one of the buttons focuses on that effect unit (The UI even changes in response... nice). In this mode, the knobs control the individual meta knobs 1-4. Once an effect unit is focused, pushing the buttons focuses down on the individual effects within that unit. In this mode, the knobs control the first four parameters of that effect. It works really well with the Xponent the way I've dedicated the left knobs and buttons to the samplers, and the right knobs and buttons to the effects.

I'm having one problem in that the samplers don't seem to be working from the controller in 2.1. This is a part of the script that was working just fine in 2.0. My build is the latest successful Windows 2.1 build, which is over a month old. Is there a known problem with the samplers? I put some debug messages in, and I'm catching the button presses, but calls to engine.setValue(group, "cue_gotoandplay", 1) aren't having any effect. I think it's the last thing to be done.

[Be-ing]

Is it really useful to have volume knobs for each sampler? In my experience one button per sampler is sufficient. Is there another way you can map samplers?

There's only so much you can fit into what a controller provides without making the mapping overcomplicated and difficult to use.

[Be-ing]

I think you will find these flickering LEDs distracting when you press shift to access alternate functionality on parts of the controller unrelated to effects. I originally had the Hercules P32 mapped in a similar way to show focus on the effect buttons when shift was pressed before implementing metaknobs (#1062 & #1063). I felt it was too annoying to keep that way.

[MelGrubb]

I could possibly have the lights remain as they are up until you actually push one of them to focus on an effect unit, which would prevent them from switching over every time you press right shift, perhaps to do something other than effects, but that seems confusing since it might imply that multiple effects are focused. The Xponent's lights are not terribly bright, so it's not as jarring as you might think. I'll give it a try and see what it feels like.

[Be-ing]

Hmm, this looks like it should work. As far as I know nothing has changed in master recently that would affect this...

[Be-ing]

I think the engine allows 4 effects in an EffectUnit, but skins only show 3.

[MelGrubb]

I'm assuming at least some skin out there could be built to allow an arbitrary number of effects, so I'm making no assumptions about the maximum here. If someone makes a skin with four effects, this will work with it, otherwise you have no way of actually loading an effect into the invisible fourth slot anyway, so you can't really hurt yourself with this.

[Be-ing]

You can't hurt yourself, but you have a useless knob. You may as well make it a dry/wet knob.

[MelGrubb]

That's actually what I had it doing before, but two different methods of getting to the same control seemed confusing. Can we say for sure that no skin will show more than three effects in a unit? Is three considered a hard limit? If so, then the fourth knob could definitely be used for the mix. I just don't want to find that in the final release there are skins with four effects per unit, and my mapping makes no sense when used with them.

I'd personally love it if Mixxx gets detachable windows in the future. I live in a multi-monitor world all day long, and I can totally see dragging the library to a second screen which would leave more room on the primary monitor for things like effects. With more screen, you could have more effects showing. I'm okay with saying that the mapping can only handle the first four because that's more than adequate. If you need more than that, then maybe it's time to start considering external hardware.

[Be-ing]

Can we say for sure that no skin will show more than three effects in a unit?

Yes, because this is what DJ controllers are designed for. I have an idea for how it may be practical to use arbitrarily long effects chains with the same 3 effect knobs + dry/wet, but don't count on that getting implemented any time soon.

I'd personally love it if Mixxx gets detachable windows in the future. I live in a multi-monitor world all day long, and I can totally see dragging the library to a second screen which would leave more room on the primary monitor for things like effects. With more screen, you could have more effects showing.

That would be nice, and maybe it'll be possible when we move from the current skin system to QML. But the main use case for Mixxx is on a laptop. I don't know about you, but I don't want to drag a second screen to a gig.

[MelGrubb]

I'll turn knob 4 back into super or mix, whichever feels more natural when I test it.

As for the monitor comment, I was thinking more along the lines of permanent club installations, or clubs that already have a couple monitors in the booth. It's rare, but it happens. Also, portable USB monitors are light and easy to carry. I have a small 5" one that I sometimes run system monitors on. Then again, there's always this: https://www.razerzone.com/project-valerie
I would totally use one of those.

[Be-ing]

https://www.razerzone.com/project-valerie

That's really cool, but I don't want to be that guy taking up a ton of space in the DJ booth.

[MelGrubb]

With my mapping, the left-hand side is dedicated to the samplers, so the knobs really have nothing else to be doing, and I have definitely fired off a sample live before and wished I had an easy way to adjust its volume. About the only change I can think of to the knobs is perhaps swapping the sides so that the samplers are on the right, that way, when you're focused in on a particular effect, I could "borrow" the knobs from the samplers temporarily in order to control parameters 5-8. That would require both the sampler and effect knobs to be filtered through the same handler though. I'm not sure I want to go there. I think the need for twiddling individual parameters at performance time is probably not very common, and if you need that level of control, you can always use the UI.

[Be-ing]

I think the need for twiddling individual parameters at performance time is probably not very common,

That's what I thought until I implemented #1211 and realized how fun it is. :)

[MelGrubb]

Ignore the comments about the samplers. I hadn't noticed the new "Bank" section over on the right, and it was on bank 2, while my script was only aware of 1. That now makes me wonder whether the controller should have a way of switching banks, but I'm kind of out of shift keys. I was going to use the shift to control whether the sample was momentary or fire & forget.

Shift and the sampler buttons could easily be used to change banks, but then I have no way to do a momentary sample (i.e. one that resets when you let go of the button). On the other hand, it would mirror the focus system I'm doing with the effects. I could do something where you'd hold down the sampler button you want, and then use the play and cue buttons to fire it off, but I don't think I like that very much. Although, now that I think about it, that would make it possible to use the hotcue buttons with the samplers. As long as you're holding down the sampler button, I'd redirect the normal transport controls to the sampler instead of the deck.

Is there any guidance/consensus on this? Which one is the most useful to people? More samples, or momentary playback?

[Be-ing]

I don't think being able to switch between banks of samplers is really useful if you can't access them all simultaneously. I am overhauling the sampler UI in #940 to rows of 8 samplers to match the common controller layout of 4 sample buttons per side, with up to 8 rows configurable for controllers with big pad grids.

Regardless, squeezing sampler controls into a controller not designed for them is going to be a challenge at best.

[MelGrubb]

The ability to use cue/pause to do momentary or fire & forget, and being able to use the hotcues, and even the keylock button to affect the samplers is kind of compelling though. There's no convenient way to do that from a controller. The main argument I can see against it is wanting to quickly fire off multiple samples like when you're drumming on the pads. The Xponents buttons aren't velocity pads, so it's not well-suited to this use case to begin with, but I can see the ability to trigger multiple different samples rapidly as the majority in this case, so I'll drop the idea for now. It sure would be nice to have those hotcues though. I've definitely used them in the past, but had to do it with the mouse.

By the way, at least in the build I have, I've noticed that Mixxx is always starting up with sampler bank 2 selected, even if that's not where I left it when I shut down last time.

[Be-ing]

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

[Be-ing]

Mixxx 2.1 has been released with the Components library and its EffectUnit which is designed for controllers with this layout for effects controls. If you would like to update this mapping to use that, then please reopen this PR. In the meantime I am closing this to clean up the clutter of open PRs.

[arximboldi]

@Be-ing I recently made an update of the Mixco Xponent script adding 4-decks support using the A-B banks in the controller (even though it is a bit confusing to play with sometimes and I actually don't use it that much :p). Maybe I will do a PR with those changes... (the current Mixco script shipped has already decent effect support, even though that part could still be improved...)

[MelGrubb]

I started looking at what it would take to migrate my Xponent mapping to the components framework. I’m not sure the Xponent is a good fit, but I’m willing to give it a try. I think the way the Xponent sends MIDI values is pretty non-standard, so I may not be able to simply drop-in a mapping to playButton and expect things to work. I’m hoping you might provide some insight here. This is the debug output of me pressing and releasing the deck 1 play button Debug [Controller]: "Xponent Audio : t:624618 ms status 0x90 (ch 1, opcode 0x9), ctrl 0x24, val 0x40" Debug [Controller]: "Xponent Audio : t:624958 ms status 0x80 (ch 1, opcode 0x8), ctrl 0x24, val 0x40" I take it the separate note (0x80) for release isn’t normal. Or is it? I followed the example in the wiki, and built this into my mapping. components.Deck.call(this, deckNumber); this.playButton = new components.PlayButton([0x90 + midiChannel, Xponent.buttons.play]); The Xponent.buttons array just holds all of the constants. In this case the value is 0x24. What I get is a momentary play button that stops playing whenever I let go of it, and an illuminated Play button on the opposite deck. So… something’s not right. If I have to build on top of the components library to even have my fully-functioning mapping considered for release, then can you help me get the first button mapped? From: Be<mailto:[email protected]> Sent: Wednesday, April 18, 2018 12:48 AM To: mixxxdj/mixxx<mailto:[email protected]> Cc: Mel Grubb<mailto:[email protected]>; Mention<mailto:[email protected]> Subject: Re: [mixxxdj/mixxx] M-Audio Xponent, advanced mapping (#1194) Mixxx 2.1 has been released with the Components library and its EffectUnit which is designed for controllers with this layout for effects controls. If you would like to update this mapping to use that, then please reopen this PR. In the meantime I am closing this to clean up the clutter of open PRs. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmixxxdj%2Fmixxx%2Fpull%2F1194%23issuecomment-382260018&data=02%7C01%7C%7C9b8c2125b32a43b163db08d5a4e79365%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636596236869164124&sdata=jAekSCeMhuZqpKldrYTUZojNJ56tQ9Ud%2B1itbbmRcdc%3D&reserved=0>, or mute the thread<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABGZB15-gTBkALQRMrMc-dPIOJA_MkTfks5tpsWEgaJpZM4MMcSw&data=02%7C01%7C%7C9b8c2125b32a43b163db08d5a4e79365%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636596236869164124&sdata=Ad8bwF4%2FfcJ%2FmM6PMXMYemJQxLLmSyaE%2BD3NL8xxA3E%3D&reserved=0>.