Advanced mapping for M-Audio Xponent

XML preset files and script files (.js) for MIDI and other controllers.

Moderators: garth, User Customization Moderators

Re: Advanced mapping for M-Audio Xponent

Postby MelGrubb » Fri Feb 10, 2017 1:06 pm

I guess I'm just looking for reassurance that there's not some known issue with putting inline functions in engine.connectControl calls. It seems like the ideal place to do some "pre-work". The basic mapping to a real function sometimes doesn't give you all the information you need, or gives it to you in a format that's not immediately useful. Within the connectControl call in the above example, for instance, I already KNOW that we're talking about Channel 0 (Deck 1), and HotCue 0 (really 1... zero-based), so why not just hardwire that into the call to onHotCue rather than having onHotCue have to figure that all out again.

The original HotCue function was a five-branch switch statement based on string comparisons. There's just no way that was efficient. In my experience, magic strings are almost always a bad idea. The mapping also contains a lot of... I don't know what to call them actually. Collections of string/value pairs? It's what I would use a proper Enum for in a "bigger" language, but using string keys to extract values from an ad-hoc object seems wrong to me.

Rather than
Code: Select all
MaudioXponent.leds = {
    "cue": 0x01,
    "play": 0x02
    ...
}


I'd rather see
Code: Select all
MaudioXponent.leds = {
    Cue: 0x01,
    Play: 0x02,
    ...
}


As I've said, Javascript is not my first language, so there may be some standard or idiom here that I'm unaware of, but why would you use strings as keys here?
MelGrubb
 
Posts: 141
Joined: Tue Apr 27, 2010 12:00 pm

Re: Advanced mapping for M-Audio Xponent

Postby Be. » Fri Feb 10, 2017 3:42 pm

MelGrubb wrote:I guess I'm just looking for reassurance that there's not some known issue with putting inline functions in engine.connectControl calls. It seems like the ideal place to do some "pre-work".


We're going pretty deep down the JS rabbit hole here for what I think is premature optimization. If you really want to optimize that, I think you'd have to use an IIFE that returns a function that calls the callback function with the precalculated arguments:
Code: Select all
var hotcueNum = 1; // calculate the number however you need here
engine.connectControl("[Channel1]", "hotcue_" + hotcueNum + "_enabled", (function(value) {
    var precaculatedArg1 = "hotcue_" + hotcueNum + "_set";
    var precaculatedArg 2 = "string" + 2;
    return function (value, group) {
        MaudioXponent.onHotCue(precalculatedArg1, precalculatedArg2, value);
    };
})() );


If any of those precalculatedArgs would be "hotcue_1_enabled", you could just reference the third argument to the callback function within the callback.

That example code is pretty convoluted for something that is commonplace in a mapping script. I think the right way to handle this is how Components does it, by storing information shared between MIDI input and output callbacks as properties of an object that both the input and output functions are also properties of.

MelGrubb wrote:The original HotCue function was a five-branch switch statement based on string comparisons. There's just no way that was efficient. In my experience, magic strings are almost always a bad idea. The mapping also contains a lot of... I don't know what to call them actually. Collections of string/value pairs? It's what I would use a proper Enum for in a "bigger" language, but using string keys to extract values from an ad-hoc object seems wrong to me.

Rather than
Code: Select all
MaudioXponent.leds = {
    "cue": 0x01,
    "play": 0x02
    ...
}


I'd rather see
Code: Select all
MaudioXponent.leds = {
    Cue: 0x01,
    Play: 0x02,
    ...
}


As I've said, Javascript is not my first language, so there may be some standard or idiom here that I'm unaware of, but why would you use strings as keys here?


I don't think that whether you reference an object property name with or without quotes is relevant to the performance. An object property name is an object property name. If you want to understand JS better, I recommend a Mozilla Developer Network guide, A re-introduction to JavaScript.
Mixxx is free because it's yours!

I heard FLAC and I haven't gone back.
Protect your hearing with earplugs!

Hear my mixes
User avatar
Be.
Mixxx Developer
 
Posts: 2573
Joined: Tue Jan 06, 2015 1:00 am
Location: Chicago, USA

Re: Advanced mapping for M-Audio Xponent

Postby MelGrubb » Fri Feb 10, 2017 5:51 pm

I talked with some front-end devs that live in Javascript all the time, and I guess the two are completely equivalent. The only real differences between quoted and unquoted "properties" are

1) You can use reserved words if you quote them.
2) Some JSON serializers want the quotes there (probably not relevant to Mixxx)
3) Some IDEs prefer no quotes, and will offer better intellisense if you leave them off.

So basically, It's a wash.
I'm not really trying to optimize unnecessarily, but you can see several people's hands on this script, and I prefer a measure of consistency. Some of the objects use quoted identifiers and others don't. I was trying to understand the difference. It seems it's just a personal style choice in this case. I am trying to simplify and eliminate code duplication, though. Just for my own sanity, and to reduce the size of the mapping to fit in my head better. There are a few dead ends and unused functions in the original mapping, so I'm pruning those as well, especially where they overlap something I've added, like flashing progress bars at -30sec instead of a hard-coded 75%. No need to keep the old supporting functions and variables around.
MelGrubb
 
Posts: 141
Joined: Tue Apr 27, 2010 12:00 pm

Re: Advanced mapping for M-Audio Xponent

Postby MelGrubb » Sat Feb 11, 2017 3:39 pm

I think I'm just about ready to submit a PR for this one. I'm thinking since it's aimed at 2.0, I should take the branch from 1.12, although I'm not sure it will make it into the final 2.1 if I do that. I would imagine you're pulling 1.12 into 2.1 before it's finalized, right? Then, I figure I'll make a new branch off of 2.1 and start work on the newer version with proper on-screen focus, and hopefully leveraging the Components library.

I have a process question, though. The wiki says to fully document the controller on the wiki before submitting the PR. Since this is an alternate mapping, I was thinking I'd create and link off to a new page just for that one mapping rather than cramming it all onto the main controller page, especially since it seems there will be three mappings now (Stock, Mixco, Mine). That is unless the Mixco mapping is completely replacing the existing stock mapping. If that's acceptable, then I'll put some sort of notice up at the top that this information is preliminary so people don't wonder why they don't see this supposed new mapping in their systems. Then, when the next version comes out, I would remove that notice. Does this sound about right?
MelGrubb
 
Posts: 141
Joined: Tue Apr 27, 2010 12:00 pm

Re: Advanced mapping for M-Audio Xponent

Postby Be. » Sat Feb 11, 2017 7:59 pm

The 1.12 branch has not been actively developed. We were initially thinking of doing a 2.0.1 release shortly after 2.0, but the old build server died shortly after 2.0 was released so that did not happen. Development has been done on the master branch. I suggest posting the 2.0 compatible mapping here, then branching off of that for 2.1 to make the pull request.

For the documentation, make a new section on the existing wiki page rather than a new page.
Mixxx is free because it's yours!

I heard FLAC and I haven't gone back.
Protect your hearing with earplugs!

Hear my mixes
User avatar
Be.
Mixxx Developer
 
Posts: 2573
Joined: Tue Jan 06, 2015 1:00 am
Location: Chicago, USA

Re: Advanced mapping for M-Audio Xponent

Postby MelGrubb » Sun Feb 12, 2017 7:26 pm

Regarding my earlier question about inlining certain function calls in order to reduce work later on... I now have a reason NOT to do that. One word... closures.

As I've been re-working this script, I've been trying to eliminate repetition and hard-coded values. I've implemented a deck array to store various state variables and key values, such as the values for pressed and released (e.g. deck[1].on = 0x90 while deck[2].on = 0x91). This is part of the groundwork for adding 4-deck control to the Xponent. It already has a mode A/B switch on the front that modifies the values of all the controls, so it's ideal. Where some connectControl calls appeared only twice before, they would now appear four times. For items like the hotcues (there are 5), what used to be 10 lines now becomes 20. Throw in multiple loops, and this started to get out of control, so I thought I'd just make a for loop from 1 to the number of decks, and repeat the same initialization for each line... and that's when closures stepped in to ruin my day. Without a simple closure-busting trick, I can't dynamically fill in values based on the loop variable at initialization time because they'll all pass 5 (the ending state of the loop variable) at runtime, and there IS no deck 5. Anyway, lesson learned. Wiring up the controls with just the name of the function and doing the work there is perfectly acceptable, and means I can write my mapping to work with any arbitrary number of decks.

One thing I noticed that didn't work as I expected was the num_decks value. I expected it to toggle between two and four depending on the state of the UI, but it keeps saying "4" no matter whether I'm showing four decks or not on-screen. Is this normal? I suppose in the end it doesn't really affect much. If I initialize decks three and four, and you never use them, then it doesn't hurt anything.
MelGrubb
 
Posts: 141
Joined: Tue Apr 27, 2010 12:00 pm

Re: Advanced mapping for M-Audio Xponent

Postby Be. » Sun Feb 12, 2017 7:57 pm

I think [Master], num_decks only indicates the state of the engine. [Master], show_4decks indicates the state of the UI. But controller mappings should be able to manipulate decks 3 & 4 even if they are not showing on screen.

One of my goals with Components is to make toggling between decks easy to implement. However, the entire script needs to be written using the library for that to work.
Mixxx is free because it's yours!

I heard FLAC and I haven't gone back.
Protect your hearing with earplugs!

Hear my mixes
User avatar
Be.
Mixxx Developer
 
Posts: 2573
Joined: Tue Jan 06, 2015 1:00 am
Location: Chicago, USA

Re: Advanced mapping for M-Audio Xponent

Postby MelGrubb » Mon Feb 13, 2017 5:11 pm

I intend to base a new version for 2.1 on the Components framework, but it's not available in 2.0 which is what I'm using now. I'm also hesitant to experiment with 2.1 on the system I actually use for gigs. It's delicate enough as it is. I learned years ago to never let Windows update the graphics driver or I would sometimes crash in the middle of a gig. If I left it on the original OEM Nvidia drivers, it would stay up forever. Well now Windows 10 likes to update drivers without asking, and I have had it crash on my once or twice. Never during a gig, but enough that I don't want to mess with this computer unnecessarily. I've managed to roll back the drivers and tell Windows to leave it alone, but I still want to keep my fiddling to a minimum.

For some reason though, I can't get Mixxx to talk to either of my controllers when I'm running it on my current developer machine, A Surface Pro 4. I don't know why that is, but it just doesn't want to talk to my controllers. It has waaaaaay too many things listed as possible controllers, especially when it's hooked up to the dock, and the left-pane won't scale, so I have to guess from the first part of the name what the items in the list are, but I'm able to identify the Xponent in the list. Then I pick my script and.... nothing happens. No celebratory light flourish, no controls, nothing. I'll be trying to figure out what's up with that next, then maybe I'll try installing the early releases of 2.1 and see what I can do with the mapping.
MelGrubb
 
Posts: 141
Joined: Tue Apr 27, 2010 12:00 pm

Re: Advanced mapping for M-Audio Xponent

Postby Be. » Mon Feb 13, 2017 6:34 pm

Those devices you see listed as controllers are probably HID devices. I don't know why your Xponent is not working with the Surface Pro 4, but I'd suggest looking at the log.
Mixxx is free because it's yours!

I heard FLAC and I haven't gone back.
Protect your hearing with earplugs!

Hear my mixes
User avatar
Be.
Mixxx Developer
 
Posts: 2573
Joined: Tue Jan 06, 2015 1:00 am
Location: Chicago, USA

Re: Advanced mapping for M-Audio Xponent

Postby MelGrubb » Mon Feb 13, 2017 6:49 pm

Yes... tons of HID devices. More than you would expect.
MelGrubb
 
Posts: 141
Joined: Tue Apr 27, 2010 12:00 pm

PreviousNext

Return to Controller presets/mappings

Who is online

Users browsing this forum: No registered users and 12 guests