I have begun mapping the Hercules P32 DJ controller to Mixxx. See the wiki page for more info and links to download the mapping files.
Great because I was really struggling with the JS script…
So far, as only the crossfader seems to work, I’m guessing the script is not being used or loaded properly…
The crossfader is the only part not mapped with JS, so the JS file isn’t being loaded or the parser is encountering a syntax error. Did you save both the .midi.xml and the .js file to your user controller mapping folder? If so, take a look at the console output or mixxx.log file and see if there are any errors about loading the script. It would be odd if the parser says there’s a syntax error for you but not for me.
I figured it had something to do with the download of the file, so I tried again with Chrome (instead of MS Edge previously) and now it works
Pretty aware of the work-in-progress nature of the mapping. Honestly, I’m just really curious about the script you used for the Loop LED segment (hence my question from a while ago on this subject…). My mapping was pretty complete (using the Learning engine and tweaking a few things) but I was stuck with this part and a few other functions requiring the script.
Okay, the mapping is in a usable state. The hotcue layer of the pad grids is mapped, but none of the other layers have been mapped yet. The FX controls and slip button have not been mapped either. I have rearranged the behavior of the encoders in the top corners in ways that I think are more intuitive. All loop functionality is controlled by the loop size encoder. I have also added a handful of extra functions not labeled, including shift+record for toggling between decks 1/3 and 2/4. See the wiki for details.
I still have a lot of work to do on the JS library and cleaning up the code.
Sweet. I’ll try to test that out this week and let you know how it feels.
EDIT: Just stumbled upon a problem (3 times in a row so far), which seems to be related to the Loop function.
Sometimes after creating a loop, all MIDI controls stopped responding, but I could still operate using a mouse. After a while, MIDI debug displayed this message endlessly:
Warning [Main]: SHOULDN’T HAPPEN: seekInsideAdjustedLoop couldn’t find a new position – seeking to in point
This occurred on Windows. I’ll try on OS X if I get it.
Regarding the description on the Wiki for the Soundcard, under OS X, a volume control icon is also visible by default (I believe) in the Menu bar, just like for Windows.
Yikes, that’s not good. I haven’t run into the issue on GNU/Linux, neither with the git master branch nor Mixxx 2.0. Do you have to move the loop for this to happen? I have a guess at what could be the issue. Try using the attached JS file and let me know if it has the same issue. Also, please attach your mixxx.log file from when this happens. Does this occur with all audio file types?
Hercules-P32-scripts.js (15.6 KB)
So far so good with the new script, but I’ll keep trying. Moving the loop might have something to do with it, but I haven’t yet found a precise way to reproduce it yet.
Here is the log from the last sessions where I had the problem.
As for the audio files, they are standard MP3, 256 kbps for most of them.
mixxx.log (1.16 MB)
Okay, I think that did fix the issue. Before the script started a timer to reset loop_halve and loop_double to 0 after 400ms from turning the loop size encoder. I did that to turn the +/- buttons on screen off but still have them light up. However, it seems that there was some issue putting that on a timer rather than doing it immediately. In the log, it shows that the timer was started but the issue seems to have started when Mixxx tried to execute the function on the timer:
Debug [Controller]: "MIDI t:1031185 ms status 0x91 (ch 2, opcode 0x9), ctrl 0x01, val 0x7F"
Debug [Controller]: "MIDI t:1031381 ms status 0x91 (ch 2, opcode 0x9), ctrl 0x01, val 0x00"
Debug [Controller]: "MIDI t:1032113 ms status 0xB1 (ch 2, opcode 0xB), ctrl 0x0A, val 0x01"
Debug [Controller]: Starting one-shot timer: 2097152058
Debug [Controller]: "MIDI t:1032153 ms status 0xB1 (ch 2, opcode 0xB), ctrl 0x0A, val 0x01"
Warning [Main]: SHOULDN'T HAPPEN: seekInsideAdjustedLoop couldn't find a new position -- seeking to in point
I don’t know why it worked plenty of times before that but encountered that bug then. From the log it looks like you pushed the encoder to activate or deactivate a loop, then immediately turned the encoder right before that error message started. I tried doing that but couldn’t reproduce the issue.
Lighting the the buttons on screen isn’t a big deal, so it would be okay to go back to setting loop_halve & loop_double to 0 immediately when turning the encoder. Keep testing the script I attached in the last post and let me know whether the issue comes up again.
Still looking good on PC, but I’ve managed to get something on OS X, which causes Mixxx to hang.
Hm, so I guess the timer wasn’t the issue. Does this happen when adjusting the loop size on any other controller? What about clicking the buttons on screen? Does it happen if you convert an MP3 file to WAV? I tried converting a file to MP3 and testing it with Mixxx 2.0 but still can’t reproduce the issue.
Small change: For loops 1 beat or less, the loop only stays activated while the loop encoder is pushed down.
Interesting twist. This is something you could apply to the pads (when in Loop mode).
To answer previous questions:
- No problem creating loops on screen or using another controller (then again none of them were using your script…)
- Haven’t tried WAV files yet .
I haven’t been able to test today and unfortunately won’t be able to until next week, but I’ll keep an eye out on the forum.
I think for now I’ll go with how it is with DJUICED with the top half of pads not needing to be held down and the bottom half of the pads needing to be held down. When Mixxx supports saving more than one loop per track (which I think Ferran may be working on this summer), I think it would be more useful to use the loop mode of the pad grids for that considering that setting loops of different sizes can already be done with the loop encoder.
From the logs, the problem seems to be when doubling or halving a loop rather than setting it. I suspect this is a bug in Mixxx and not something specific to this controller script.
So I’m back.
I’ll try with other or no controllers soon, but picking where I left off, using the latest script, it seems to help on OS X. I’ve yet to get the crash from before, so that’s an improvement
As for Windows, I’m not so lucky. Included is the log from my last session which ran for a while.
On two occasions, the controller stopped reacting, the log showing a bunch of
Debug [Controller]: Killing timer: 1912602703
Debug [Controller]: Killing timer: 1895825434
Debug [Controller]: Killing timer: 1946157094
Debug [Controller]: Killing timer: 1929379849
Debug [Controller]: Killing timer: 2046820391
Debug [Controller]: Killing timer: 1996488738
Debug [Controller]: Killing timer: 2063597589
Debug [Controller]: Killing timer: 2080374811
Debug [Controller]: Killing timer: 2130706457
Using the mouse and pressing Play on the GUI, the buffer unloaded all the actions performed, and I regained control normally.
Eventually, SHOULDN’T HAPPEN: seekInsideAdjustedLoop couldn’t find a new position – seeking to in point showed up again and Mixxx hanged and I had to force close it.
EDIT: spoke too soon. It ended up crashing under OS X eventually.
mixxx.log (993 KB)
With the script I posted on the last page or the script from GitHub? Can you attach the log from OS X?
And please test whether it happens with other file formats.
Always using the one on Github.
Included are also the crash files for OS X.
I’ll concentrate on using WAV (PC) and M4A (OS X) today.
On a side one, you may want to adjust the rate of the browser encoder as I’ve noticed that it jumps over one song for every click.
OS X_crash_n_log.zip (150 KB)
Oh, I thought you were using the JS file from this post without the timer. My only plausible guesses of what is causing this issue is the timer, which I removed only in the script attached to that post, or some issue with seeking MP3 files. Please try the script attached to that post on OS X (with MP3 and other file types) and see if the issue happens. If the issue turns out to be the timer, I’ll put a revised script on GitHub without the timer.
Yeah, I was aware of the issue. Now that you mention it, I realized what was causing it. The JS function was fine, but at some point I accidentally added a second mapping in the XML file so the JS function was being executed twice for each MIDI signal. I fixed the XML file on GitHub.
Starting to get confusing. I guess I’ll pretend today didn’t happen
So to be clear, on Monday I’ll try:
- The current XML file on Github;
- The modified script file posted previously;
- various audio file format.