Update Mixtrack 3 mapping to support #1187#1287
Conversation
Be-ing
left a comment
There was a problem hiding this comment.
Thanks for updating this.
I suggest switching around the mapping so shift + pitch up/down doubles/halves beatjump_size and shift + beats encoder does the jumping. This would allow for quickly beatjumping through the track with repeated beatjumps. Using buttons for this would require repeatedly pressing the buttons, but it is easier to repeatedly turn an encoder.
Have you considered remapping the autoloop pad mode like the Pioneer DDJ-SB2? Considering you already have other controls for beatjump_forward/backward, I think it would make more sense to use shift + halve/double as beatjump_1_forward/backward (independent from beatjump_size).
| beatJumpSize = parseInt(control.match(/\d+/)[0]); | ||
| }; | ||
| if (increase) { | ||
| jumpSize = presetJumpSizes[(index + 1) % (presetJumpSizes.length)]; |
There was a problem hiding this comment.
Is there a need for wrapping around when reaching the smallest/biggest value? When I was developing #1187 I found such behavior to be a little unexpected. I think checking against a minimum and maximum value is sufficient. This would also allow the user to enter a non-power-of-2 number into the spinbox and halve/double it from the controller.
There was a problem hiding this comment.
No need and I agree.
Yes, I saw this, will have to play with it. Ideally I'd like encoders for both - which could be sort of accomplished by doing
I enjoy the current autoloop setup on this controller but will consider changing the shift actions. |
It might get confusing if two different modifiers with the same encoder do slightly different functions.
Then you would lose access to small loops on the controller. A benefit of the new loop controls are that they allow controllers to fit more functionality into the same physical components while allowing the user to access a wide range of loop sizes. |
Also using this method instead of checking `deck.duration`.
The old library controls are better for my use case, and I imagine for many people with smaller controllers. Suggestions on how to make use of the new library controls are welcome..
When no effect is focused and instantFX are off, the touch strip is mapped to control the super knob, thus it makes sense to have it be visible.
|
I think I'm about done with making changes for now. Did a bit of code clean-up, fixed a small but annoying bug and mostly kept the mapping the same. I thought about your suggestions but my personal preference is to keep things the way they are. I'm not opposed to re-visiting as the release of 2.1 gets closer. I really like the new interface for looping and beatjumping by the way, nicely done! Wiki has been updated to reflect these latest changes. Unless you've got additional suggestions, this is ready to merge as far as I'm concerned. Thanks! |
| var samplerGroup = '[Sampler' + samplersToToggle[i] + ']' | ||
| var gainValue = engine.getValue(samplerGroup, 'pregain'); | ||
| var gainMultiplier = 3; | ||
| var maxGain = 4; |
There was a problem hiding this comment.
This relies on an implementation detail of the pregain ControlObject which could potentially change in the future. How about using engine.set/getParameter instead?
There was a problem hiding this comment.
I'm a little unclear on the difference between getValue and getParameter tbh. Basically parameters perform scaling and bound checking between 0 and 1?
“Parameter” values range from 0 to 1. If you set a parameter to 1 then the value of the control becomes the maximum value. If you set the parameter to 0 then the value of the control becomes the minimum value.
So basically setParameter and setValue are almost always preferred?
There was a problem hiding this comment.
set/getParameter are preferred for ControlObjects with a continuous range (knobs and faders) whereas set/getValue are preferred for ControlObjects with discrete values (binary or multi-state buttons). setParameter and setValue both perform bounds checking unless the ControlObject specifically allows setting outside its normal range (as mentioned above, I think only "rate" does this currently).
|
|
||
| this.PADSampleButtonHold = new LongShortBtn(NumarkMixtrack3.onPADSampleButtonHold); | ||
|
|
||
| engine.softTakeover(this.group, 'pregain', true); |
There was a problem hiding this comment.
This is manipulated by a relative control (Beats encoder), so soft takeover doesn't matter.
|
|
||
| gainValue = gainValue + increment; | ||
|
|
||
| if (gainValue < 0) { |
There was a problem hiding this comment.
ControlObjects take care of value clamping automatically unless they specifically allow out of bounds values (AFAIK only the "rate" CO for decks allows out of bounds values).
|
The changes LGTM. Thanks for the code cleanup and making small commits that are easy to review. :) Have you considered swapping the effect enabling and focusing? That is, having the focused effect selection be the default mode of the effect buttons and use Tap + effect buttons for enabling/disabling? When I played with the Pioneer DDJ-SB2, I found it more useful to have quick access to different effects' metaknobs than the enable switches. I generally don't manipulate the enable switches while I am using effects because that makes sudden changes in the sound, but having quick access to each metaknob allows for easier control of effect chains. |
|
I've addressed your review comments, and switched the mapping of effect toggle/focus. You're on point here:
I usually turn down the mix knob before making that change, but this is pretty good too. As an aside, I just got a good deal on a Vestax VCI-400SE and may be using this controller less/possibly selling it :/ |
|
Great, thanks for your work. The Mixtrack Pro 3 and Mixtrack 3 are some of the best selling DJ controllers now (or at least they were last year), so having a good mapping for them will impact a lot of people. :) The VCI-400 mapping could also use updates for the new effects and looping UIs. Its effects controls will work well with the EffectUnit object in the Components library. Have you tried the new reloop_andstop ControlObject? You can right click the reloop icon on screen to try it. I think having access to that is a big advantage for the way I mapped the 4 loop buttons on the DDJ-SB2. |
|
I think that the VCI-400 I have is different unfortunately as it's the Ean Golden edition which has different firmware. I'll see what I can do mapping wise. I do kinda want to keep it just for fun.. we'll see. I haven't tried I'll take a final look at it and make sure nothing fucks up - will tag you back for a merge. |
Yeah it seems that firmware has lots of (apparently undocumented) differences from the regular VCI-400 firmware. In your JavaScript you may have to work around ugly hacks they did with the VCI-400 firmware to work around Traktor's limitations. If you find that the firmware is sending weird MIDI messages that are cumbersome to work with in Mixxx, you might want to replace the firmware with the regular VCI-400 firmware. Since Vestax went out of business, Serato is hosting the firmware on their site. If you do stick with the Special Edition firmware, that firmware is available online so I think the mapping could be used with regular VCI-400s. |
|
Yikes it looks like there was a miscommunication between Vestax and DJTT so that the firmware updates via USB of the VCI-400 and VCI-400 SE are incompatible... To get an idea of some of the quirky MIDI behavior of the VCI-400 SE... |
|
Do you have any idea what is going on with the issue some users report on the forum of the right jog wheel not working? |
|
I don't know... Both my jog wheels definitely work. I think a clean install
of either 2.1 or 2.0 would rectify it barring any hardware issues. I
actually have had my jogs be unresponsive but that was while playing in a
dusty environment and it cleared up with a little tapping.
…On Jun 25, 2017 11:29 PM, "Be" ***@***.***> wrote:
Do you have any idea what is going on with the issue some users report on
the forum of the right jog wheel not working?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1287 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABDqeIEZs4VdnNiZeT8J5uWgBxJEdFl0ks5sH0-_gaJpZM4N_Rck>
.
|
|
Thanks for the links on the VCI-400SE, I've been doing some reading myself but only getting it today. Looks like I'll have my work cut out but it seems like it's achievable, if painful. One more off-topic question - do yo have any recs for MIDI debugging on Windows 10? Back on the current topic, I think we're good to merge. Played with it last night and the latest changes behaved predictably. @daschuer? :) |
|
Yes LGTM to merge this. On Windows you can use MIDIOX to intercept MIDI messages (on Mac you can use MIDI Monitor). |
|
Thank you for the work! |
Just bringing up the mapping to support new controls introduced in #1187. May take opportunity to re-map as a few button combinations have been freed up.