fixed the controller mappings for ION-discover DJ#936
fixed the controller mappings for ION-discover DJ#936rryan merged 5 commits intomixxxdj:masterfrom nieknooijens:master
Conversation
|
Thanks for fixing this. Could you write a description of how it works on http://mixxx.org/wiki/doku.php/ion_discover_dj ? Considering the limited controls on this device, something is inevitably going to be awkward. I think mapping the "volume" knob as the low EQ makes sense. So you just use the crossfader to control volume with this mapping? I initially thought mapping headphones to the reverse button might be more useful than mapping it to reverse, but considering this is a cheap controller without a built in sound card, I suspect many users don't have a sound card output for headphones anyway. |
|
well writing docs... don' t know what to write do you have an example of a good wiki? then I can use that as template. for headphones, I bought this controller as a cheap add-on for my stage set since I usually need to play some music in between performances and a mouse just isn' t ideal for that. I usually hook up a xenyx X2442USB but since the USB function of that doesn' t have a volume knob and can only be forwarded to either the headphones or the main, I simply use my main soundcard with a patch cable to assign it to channel 11/12 which gives me a fader for volume control. I do hook up the USB for mixxx's headphone output since you can forward the usb to the headphones and it has a seperate volume control for that, even better, pressing the "solo" button on another channel gives me the audio from that channel and it will mute mixxx's audio. |
Here are a few good examples:
They're all documented on http://mixxx.org/wiki/doku.php/mixxxcontrols
There's no need for that, but a written description helps. It also shows someone who might be considering getting the device that it actually has a functional Mixxx mapping. By controlling volume, I meant channel volume, not the volume of the whole mix. |
|
yeah I just crossfade to control volume the crossfader is surprisingly accurate on this device. |
|
@Be-ing to reiterate, documentation is not a prerequisite for approval of a controller configuration. It's nice to have, but it's ok to merge code and then file a separate bug to get documentation written. |
|
Not requiring documentation before merging is how we ended up with a mapping that had pitch mapped to gain, sync mapped to headphones, and no working LEDs. It's not just to document it for users, it verifies that the controller is actually mapped in a sensible way. |
|
Yes but it's ok not to catch problems like that right away. That's why I mentioned a followup bug. With this process the the config gets in and stops rotting, which is important. If there's a problem with the mapping we'll see it when the documentation does get written. |
|
My concern with that approach is that it could take a long time to discover issues with mappings and perhaps longer still to get in touch with someone who could fix the mapping, if either of those ever happen. I think reviewing documentation on a GitHub pull request before merging is the best time because the mapping author is most likely to be engaged with Mixxx, responsive, and willing to fix issues. In the event that the author is unresponsive for a while after opening a PR, which doesn't happen often but does occasionally happen, I agree that it would be better to get the mapping merged and not let it rot. I think it would be considerably harder to get in touch with someone who has the controller and could fix an issue if it is reported on the Launchpad bug tracker, which requires a separate account from GitHub, after the PR has been merged and the mapping author is likely not very active in Mixxx. (On that note, @timrae's suggestion to move the wiki to GitHub is worth considering.) The mapping for this device was originally included in Mixxx 1.8, released 6 years ago, and the device has since been discontinued by the manufacturer. It would be okay to not catch issues like that right away, but it's not okay to keep an awkward mapping in Mixxx until after the device has been discontinued. Mappings are typically submitted by people who are relatively new to Mixxx and mapping the first controller they've owned. So, there are often a couple of oddities in submitted mappings that don't make much sense or could be implemented in a way that's more intuitive to use. They're typically not as extreme as mapping a controller's sync button to Mixxx's headphone button, so I think these issues would be even more likely to go unreported by users for years. Having people who are more familiar with Mixxx and the usage of controllers review mappings can catch these issues early. Additionally, I think having documentation done (or nearly done) before merging PRs is the best opportunity to review the documentation for the same reasons it's the best opportunity to review code. Mappings are often submitted by people who don't know English very well, and even if they are, everyone's writing could use review to make it clearer. I think it's best to talk about the wording and structure of the documentation when the mapping author is actively engaged with Mixxx. |
|
Contributors can flake out at any number of stages of the process -- sometimes we have a complete configuration but they aren't even willing to make a github account. I would like to keep the barrier to entry as low as possible and the positive feedback at a low threshold. If someone disappears right after submitting a PR, well, they probably weren't going to stick around for the whole PR. I appreciate your concerns but I would prefer that we stick to a two-step process for config and documentation. |
You should definitely migrate the wiki over to github IMO. Having to create a new account, and figure out a new unfamiliar wiki system just adds one more barrier to contribution. The fact that the wiki is currently BROKEN (can't login with new accounts, and I have received no response from @rryan on IRC), and in general probably requires some periodic maintenance from the core dev team should add a large motivating force to start migrating. I recently migrated a project I lead (AnkiDroid) from the Google Code Wiki to Github. There was a script to automatically convert to github MD language, which worked acceptably well with a few quirks, and was mostly a painless process. You can see the result here if you're interested. |
|
Hi @timrae
I just registered a new account and was able to edit right away. Could you provide some more DETAILS about your setup? Browser, OS, etc.? ;)
Sorry about that. I often pop in and out and I guess I missed your message. Feel free to ping or direct message next time.
While having to create a different account is a downside, having to know git is a significantly higher burden that I'd like to avoid imposing on the non-developers in our community. Thanks for the suggestion! |
I hear your concern, but empirically this hasn't been much of an issue. Since I've been reviewing documentation for mappings together with PRs, we have had 9 new or updated mappings submitted that I can confidently say are good quality mappings with quality documentation: Hercules DJ Control Instinct (#700), Hercules DJ Console 4-MX (#810), Reloop Beatpad (#752), Vestax VCI-100 Mk2 (#729), Pioneer DDJ-SB (#663), Pioneer DDJ-SB2 (#816), Numark Mixtrack (Pro) 3 (#905), Stanton SCS3m & SCS3d (#809) On the other hand, only 3 times has the mapping author been unresponsive, unwilling, or unable to write documenation and complete a thorough review: FaderFox DJ 2 (#867), Allen & Heath Xone K2 (#660), Behringer CMD Studio 4a (#869). For the Xone K2, fortunately someone else contributed documentation later. |
Chrome 50.0.2661.94 on Ubuntu 16.04 64-bit
Have you used the github wiki before? While it is internally based on a separate github repository, this is an implementation detail that is generally not exposed. I have not once had to use git to do anything on the AnkiDroid wiki. |
|
(Sorry for cluttering your PR with these discussions @nieknooijens :P ) |
|
Personally, when I submitted my first mapping, I felt let down that no one critically reviewed it. Having my mapping held to a lower standard than any other contribution felt like it wasn't very important. I don't think that's a good way to encourage an active community of contributors. On the other hand, some mapping authors have expressed gratitude after I've suggested alternative ways to map their controllers that they agree are more intuitive or useful. |
|
I wrote the wiki article so stop fighting 🌴 relax! |
Weird... If I login from my mobile phone, with WIFI OFF (bypassing the NAT on my local network) then I can login. If I enable WIFI the same issue happens even on my mobile. I've been using the same router for >5 years and this is the only site I've ever had any issue with as far as I'm aware. |
|
Great, thanks @nieknooijens ! I edited the wiki page a bit for style and wording. A few little comments:
|
|
sync_enabled? you mean when you long-press sync? well I prefer the flashing from beat_enabled which also sort of shows that the 2 songs are in sync, maybe we could map that to the "rev" button since that only lights when you press it. re-mapping "browse encoder press" is probably a good idea but I don' t know what would be the best control to map it to, if you want to mute the master output just turn that big knob at the top to the left, and maximize library is something I don't use at all, the library is big enough on a 1920x1080 screen so why should I make it any bigger? |
Not everyone has a 1080p screen. For example, my laptop is a few years old and has a 1366 x 768 screen, so maximizing the library is helpful. |
I'm planning on submitting a PR sometime (hopefully in the next week or so) to create a control that allows toggling between track selection and crate / playlist / etc selection. This would be an ideal mapping for the encoder wheel push action IMO, at least on my controller (MC4000) which works more-or-less this way when you use it with Serato. |
Odd -- what kind of errors do you see in chrome's network requests in developer tools? |
Hm, I guess I like the customization options we have on our wiki. File hosting, fine grained permission groups, ability to lock pages, custom plugins for things like table support, etc. Also we have a lot of good SEO built up for mixxx.org via our wiki. People searching for Mixxx help tend to get landed at the right place in the wiki based on our webmaster tools stats. |
Sure, that would work. But that control doesn't exist yet. How about mapping it to [Master], maximize_library for now, which keeps the mapping compatible with Mixxx 2.0, and when @timrae creates that new CO, you can open a new PR to update the mapping. |
|
One thing I don't like about controller documentation is that it's a separate artifact from the controllers since it lives on the wiki. I think it would make sense to introduce a structured documentation format for controller scripts where that documentation lives alongside the controller script itself in this repo. This would make it easy to serve documentation to users inside of Mixxx and integrate them into the manual. Markdown is a reasonable choice though something with a little more structure would be nice (e.g. a way to indicate explicit features that are supported such as 4 decks, effects, etc. so in-app we can say "This preset is/isn't good for 4 deck use" or something like that. Though maybe that belongs in the XML). If documentation lived next to the scripts in our repo I think it'd be more likely they'd get written and kept up to date (independent of the question of whether they are a precondition for an initial merge of a preset). |
|
Hm, interesting idea. What about using ReStructuredText and making them part of the manual? |
+1 ReSt or Markdown (maybe with a standard template) would work fine -- I was thinking they could live in res/controllers/ alongside their preset. Maybe each preset should move into a folder for organization? This would help with the "import/export MIDI mappings" use case since we could .zip the folder so users pass around a single file for a preset. It would also allow users who have a crazy preset that isn't suitable for inclusion in Mixxx to write documentation and have Mixxx render that documentation in-app when you import the preset even though it's not an "official" Mixxx preset. |
|
I like the idea of giving each mapping its own folder. That would help with mappings with lots of JS, which could be split into multiple files, and mappings like the Hercules DJ Control MP3 e2 which already are spread across more than 2 files. What I'm wondering about most is how to serve the documentation within Mixxx without introducing a heavy dependency like a browser or HTML rendering engine. |
Good point -- I think we may be ok though. Qt comes with a builtin HTML renderer for a subset of HTML (doesn't require QtWebkit -- which we disable on our Windows/Mac builds). http://doc.qt.io/qt-4.8/richtext-html-subset.html This is how little HTML snippets get rendered in various places in the codebase (e.g. the crate section in the library): https://github.com/mixxxdj/mixxx/blob/master/src/library/cratefeature.cpp#L782 |
|
I think using that subset of HTML directly would be easier for people to contribute documentation. RST and DocuWiki are easy to learn, but it's one more thing to learn, and they're both relatively uncommon. OTOH many people already know HTML. |
I just reproduced the issue behind my company firewall as well, so it's reproducible on completely separate networks. There are no errors as such, here are the headers:
|
Hm, from your screenshot the remote address looks pretty sketchy (10.136.0.56:8080). This means your DNS provider is resolving www.mixxx.org to 10.136.0.56. The 10.0.0.0/8 IP address range is for private networks. Does your company have an Internet filter? Who is your DNS provider? (Note that "xxx" in the domain name sometimes triggers porn filters) |
I don't think that's the problem as it happens at home as well, and in that case I shouldn't be able to access the domain at all. We have a proxy server here though, so maybe it's better to debug based on my home configuration. I'll update later tonight. |
Ok, I think I figured it out. "Sorry, there was an error processing your request. If this is an error contact us at info AT mydomain.com." is the response that our spam detection plugin for dokuwiki displays when it thinks a request is spam. |
|
Do you have a problem with spam on the wiki? If not could you maybe just disable it? I've never encountered any spam on a google code or github wiki. |
|
Yea, we do have problems with spammers. I replaced the old plugin (which hasn't received any updates since 2013) with a new one -- so hopefully that does it? |
|
Excellent, yes that did the trick! |
|
Ok i pushed another 2 fixes for this controller, this will not only map the rotary knob to maximize/minimize library, but also makes the scratch-mode less sensitive so that 1 rotation on the DJ controller equals 1 rotation of the spinnies in mixxx, this is not only more natural, but the controler sometimes spazzes out when doing too small movements. this fixes that by allowing you to use bigger movements. |
| <options> | ||
| <script-binding/> | ||
| </options> | ||
| </control> |
There was a problem hiding this comment.
I'm confused where the maximize/minimize code is. Did you accidentally stage the wrong changes for this commit?
There was a problem hiding this comment.
no this is the correct one, I used the midi-learning wizard.
There was a problem hiding this comment.
All this diff seems to be showing is moving the <control> element for mapping the jog wheel further down in the file. Am I not seeing something else changing here?
|
There is a lot of commented out code in the JS file. If this won't be used, could you delete it? |
original mapping had some problems, pitch was mapped to gain and sync was mapped to headphones. also the leds didn't work there's still something thats quite awkward and that's the fact that this DJ panel only has a 2 band EQ and mixxx uses a 3-band one, therefore the volume knob has been mapped to the low EQ since mixxx already handles the volume pretty well using replayGain.
|
ok I just rebased it to remove empty commits. |
|
Cool, looks good to me! 👍 Thanks for fixing and documenting this! |
|
Could someone merge this? |
|
wait... is this still open? |
|
thanks @nieknooijens ! |
5 participants
original mapping had some problems, pitch was mapped to gain and sync was mapped to headphones.
also the leds didn't work.
I mapped sync to beat_active, so it flashes in sync with the beatgrid.
rev, only lights when you press reverse.
everything else should work as expected.
there's still something thats quite awkward and that's the fact that this DJ panel only has a 2 band EQ and mixxx uses a 3-band one, therefore the volume knob has been mapped to the low EQ since mixxx already handles the volume pretty well using replayGain.