Updated Controller Mapping: American Audio VMS2 #876
Conversation
There is no << operator for QPoint, QSize, QRect when building with qdebug=0.
Fix build error due to passing a const pointer to modplug read function. Fix UI baseclass (QWidget instead of QDialog) Fix UI size behavior for ModPlug Decoder Preferences. Remove superfluous tabstops that were giving warnings.
Add custom VMS2 MIDI support with advanced script functions. This replaces the included VMS2 mapping by Groschi.
Conflicts: res/controllers/American-Audio-VMS2-scripts.js
|
Thanks for updating this. Can you document it on http://mixxx.org/wiki/doku.php/american_audio_vms2 ? |
|
I'll update the wiki as soon as this is merged ;-) I already put a link to that page in the XML file. |
|
Please update the wiki first. Without having access to the hardware, it's not really practical to review a mapping without a written description. Can you start a new forum thread for this mapping? I think that would be better than posting in http://mixxx.org/forums/viewtopic.php?f=7&t=3202 and have your mapping buried after pages of old discussion. |
|
@Be-ing I was just writing a much too much too long wki page for this controller. I did not see your comment before I saved it, but actually I thought this would be already merged by the time I press save ;-) The changes I made to the mapping are described in the pull request description, but you are of course free and very welcome to review the complete mapping. The diff got convoluted because I also removed and renamed the old mapping. That is a bit unfortunate for a quick review on github. I will not post a comment on the forums. But I think the old thread is still fine. It's only three pages and lots of interesting information in there. This pull request is linked from the wiki and will still be available after it has been merged. I will put links to the raw files (from my fork) in the pull request description. This way others can easily find and download the current mapping. Thanks for caring for the mappings and the wiki! |
|
Sorry I haven't gotten a chance to thoroughly look at this yet. Hopefully I'll have time this weekend or next week. I took a quick look at the wiki page and it's great! However, it is a bit too verbose in some places. You don't need to re-explain what is already explained elsewhere on the wiki or manual, just link to the more general documentation. |
|
Okay, finally reviewing this :) Sorry for the delay. Thank you for documenting this. I reorganized, reworded, and trimmed down the text on the wiki. I don't think it's really useful for users to keep information about what might possibly work in the future on the wiki, so I removed some info. I also rewrote the Audio Setup section to make the important details clear and obvious at the top. The VMS2's manual implies that the master volume knob and gain knobs control the VMS2's hardware mixer. Can you confirm this? Mixxx's individual deck outputs aren't affected by Mixxx's master gain knob, but they are affected by the channel gain knobs. If the hardware mixer is applying gain, then turning the channel gain knobs applies gain twice, so I don't think the MIDI signals for the gain knobs should be mapped. It may also make sense to unmap the MIDI signals for the master gain knob as well to clarify that the change is actually being done on the VMS2's mixer. The following points address changes introduced in Mixxx 2.0: Considering the left and right arrows move through the library sidebar, it would be a better use of the push encoder to map pushing it to [Master], maximize_library. Use cue_indicator rather than cue_default in the XML file to map the output for the cue buttons. cue_indicator is used by the buttons in the skins and changes behavior depending on the cue mode selected by the user in the preferences. I presume the playlight and playlightflash functions were helpful before play_indicator was introduced, but now Mixxx handles when the play light should be on or flashing with the play_indicator control. All the mapping needs to do is turn the light on when play_indicator is 1 and turn it off when play_indicator is 0. Change the sync button to use the new sync_enabled rather than beatsync. |
|
@snue , thoughts about the above comments? |
|
@Be-ing I somehow missed your previous comment here, sorry. I guess all your comments address valid points. Unfortunately the device is already back with its current owner, so I can't really test any changes. The gain knobs definitely affect the hardware outputs, as they also work fine for the analog inputs and mixed analog/digital inputs (with analog on one deck, digital on the other). The analog input volume always seemed quite low in comparison to the digital. Don't know if that is related to double affecting outputs, as it is already the case in "normal" position with no additional gain.That said, workflow with the proposed script was quite fine overall. I liked that the MIDI signals actually showed the current position of gain knobs in the skin and would reset any strange settings applied by e.g. mouse interaction, so I would not really want to unmap those. I was not aware that the gain knobs that actually correspond to knobs usually found on a mixer would already influence the signals sent out by the individual decks (and not only the left/right "bus"). I rather consider this a bug. I would expect that to behave like a true hardware setup, where mixer gain knobs don't influence the signal that is fed into the mixer from the decks. But maybe that breaks the use case required by some other midi controller. But then again, the same is true for the equalizer buttons which should probably not influence the "deck" signals, which would require the VMS2 to be operated in pre-EQ mode (which the hardware supports), and I was aware of that so I don't know why I missed that for the channel gain. You are right that information about possible future changes should probably not be included in the wiki. That's rather for "launchpad blueprints". But as a colleague of mine likes to say: "The wiki is where information goes to die." 😢 I would not really want to change center push knob behavior as it is much more pleasant to use the knob to scroll in sidebar and main library window. I would rather find a new use case for those four buttons around the center knob (like using one of those to toggle maximize library). I never used those four buttons really. I could not get the I have no idea how the sync button change would influence work flow with that controller. I would need to read up on that in the documentation. Syncing to the other deck worked quite fine with the current mapping (and "real DJs don't use [sync] anyway" 😜 ... well no really that needs to work as it is a very nice feature). Thanks for thoroughly reviewing this. |
|
I understand that it is nice to see the status of the controller reflected on screen, but I don't think that's worth compromising the gain structure. I'm not sure if the gain knobs in Mixxx affecting the unmixed deck outputs is intentional or not. To make the gain knobs not affect the unmixed deck outputs, I'd guess that would require some refactoring in Mixxx to make sure ReplayGain still works in that case. @daschuer , thoughts on this? I like the wiki to be a place where information goes to live. :P To be clear about the library navigation controls, what I am suggesting is to leave the encoder just for scrolling in the library but not the sidebar. The sidebar generally has a lot fewer items to scroll through than the library, so going through it one-by-one with button presses is okay. I personally find it nice to have a way to toggle the maximized library on controllers, but considering that this hybrid controller/mixer can't really be used with 4 decks (when maximizing the library really helps), not having a way to toggle that on the controller isn't a big deal. (But really, I think any mouse is better for library navigation than an encoder and buttons on a controller ;) ) Would you be able to get access to the VMS2 again to test changes? If not, I'd be okay with merging this as-is. You could open another PR for further changes if you get the opportunity to test them in the future. |
|
@Be-ing I don't have any concrete schedule for when I will be able to get my hands on the controller again. It is not impossible, but I would rather merge this quick and open a future PR when I incorporated and tested your suggestions. Maximizing the library is definitely a nice and useful feature. But as I said I would map that on one of the redundant buttons around the knob. Changing crates and skimming through tracks in the crate all by just rotating and pressing the knob is really a pleasant workflow. The more I thought about 4 deck support for the VMS2 I realized it needs quite some workarounds because the volume/gain controls and crossfader all affect hardware outputs. It's just too easy to screw this up in live situations, so that will probably not happen. For the part about signals affecting the deck output, I think that is fine the way it works right now. It enabled me to put mappings for the software EQ kill switches on the controller. Those would not work if the deck output wasn't already affected by software EQ (and therefore channel gain for consistency). One could map the [left/right bus] outputs instead of the [deck]s to the controller to make it clear the EQ/gain section affects the signal, but then those need to be pre-crossfader, which they currently do not seem to be. But that discussion is for a dedicated issue. |
|
@rryan There is always room for improvements but I currently do not have access to the device anymore. In my opinion this is good to be merged for now. |
+1 |
|
Great -- thank you @snue ! |
This patchset improves the American Audio VMS2 controller mapping in various ways:
The patchset also removes/replaces the old mapping by Groschi, since it was incomplete and should not have any advantage. This was suggested by Groschi in this forum post. After that there is only one VMS2 mapping left in the codebase.
Download the mapping files (you need both):
American Audio VMS2.midi.xml
American-Audio-VMS2-scripts.js