I just moved, and in the process of doing so I took the Ms apart and put them in their boxes. Granted I’m way more used to DJing on vinyl and the Ms, but I’ve hooked up my Pioneer CDJs, American Audio Radius 3000s, Gemini MDJs, and some good hires DJ Tech MIDI controllers with jogs (designed by Luis Serrano) and they are all demonstrably more intuitive to use the jog bend than the SC5000 non-M… especially the last two. BTW, not saying the MDJ doesn’t have other problems.
The bend forward and back is clearly symmetrical since the firmware fix way back, but it’s like there’s a slight delay to the bend occurring, an unintuitive curve to the rotation rate translated to a bend, maybe too low of a max rate to max bend at the lowest sensitivity setting, or perhaps it’s interacting with the Elastique key correction’s phase distortion in weird ways. I’m not exactly sure what’s causing this awkwardness. Maye a combination of factors, or even something else entirely.
The Pioneer has its own quirk with its minimum rate required, and the Radius 3000 of course has that time-based bend that ramps up and requires brief nudges & drags, but the MDJs and controllers are totally superior for jog bending. There’s no aspect of the Prime firmware jog bend that can match what I’m getting from the MDJs and the controllers, no matter how I adjust the Prime jog bend sensitivity. The Prime bend is so weird I’d rather be using the CDJ or ADJ bend.
I bet if I was using BPM counters and phase meter with some visual mixing that whatever moment-to-moment temporary auditory timing oddities would not be misleading my mixing, but just mixing by ear there seems to definitely be something going on that fools me into thinking the inputs are having different outcomes than they should, at least at the split-second level and using just my ears. Anyone else notice something weird about the non-M jog bend?
All I can say for my part is based on the LC6000 jogwheels which are similar to those of the SC6000 as you know.
Note however that my opinion may be biased because they are connected to a pair of SC6000M. And the SC6000M firmware does not allow for bending sensitivity adjustment unlike the Sc6000 firmware. The LC6000s cannot therefore benefit from the customization of this parameter (it would also be good if the development team corrected this on the M firmware at least when an LC6000 is connected)
I have long used CDJ 2000 NXS and indeed the sensitivity setting seems clearly different. The default setting of the CDJ 2000NXS, although it is not adjustable in my memory, is very balanced by default unlike the Default setting of the LC which is much too sensitive. I would prefer to have a much lower sensitivity and a lot more range of motion during the nudge phases using the jogwheel.
I get something much more comfortable when I use the LC on VDJ because I found a precise sensitivity value that I can set and that suits me (JogBendSensitivity parameter set to 0.02250) if you want to test.
What I suspect is that depending on the manufacturer must probably have its own linearity setting for the jogwheels. The jogwheels of the Denon units are very sensitive but very linear
The pioneer jogwheels seem to have a sensitivity curve varying according to the speed with which the platter is moved, with a very low sensitivity providing more precision when the jogwheel is moved at low speed, and a higher sensitivity when it is launched at high speed for quick catch-ups. In any case, that’s a bit the feeling it gives me.
I think that in addition to the sensitivity setting we should be able to choose between several types of linearity curves.
If you turn the sensitivity down on the non-M, the max rotation has a low bending cap. You certainly seem to be capable of a much larger bend on the Pioneers if you rotate fast enough. The Pioneers’ bend is more difficult to get nuance from due to the threshold limit, though, unless you rotate in relatively fast, short, jerky chunks to get past the rotation rate deadzone while still keeping the bend quantity low. On the pre-CDJ-3000 models, at least, this method thankfully still has very low latency and a highly predictable outcome, including when keylock (master tempo) is activated, even if this nuanced input is unintuitive and requires deliberate user inputs.
There certainly does seem to be a need for different bend limits on the Prime players, but I can’t tell yet if it’s necessarily a curve shape exactly that needs improvement or something else in addition to the max limit change seemingly warranted. I guess if we want more bend possible on the shoulder of the curve while retaining the current nuance for a substantial portion of the foot region, then a curve change does make sense.
Obviously if there is an Engine OS firmware latency issue or an issue with the keylock group delay interacting with speed change, then using the LC as a controller with VDJ bypasses both those potential issues just as much as using VDJ’s own jog bend sensitivity and curve.
I’m curious, though, how does the LC’s bend feel in comparison to the M’s motor-off jog bend, other than the fact that the latter has more mass and also has the magnet cogging action that will wobble slightly back?
This is just a simple hypothesis but I wonder if in fact the jogwheel of non-M units does not simply send simple midi messages with a resolution lower than the HID protocol. EngineOS seems to be after all just a simple application running as an overlay on a linux environment.
An SC unit and all its controls are perhaps ultimately just a box where each key sends midi signals, just like an LC unit would do when connected to an application such as Djay or Traktor with a mapping.
For example under Djay which seems to use only a simple midi protocol, a kind of latency is clearly noticeable when using the jogwheel. This is particularly visible in vinyl mode if you try to scratch. It’s not as responsive in Djay as in VDJ or the LC6000 seems to have benefited from a real HID integration which gives a real feeling of responsiveness of the jogwheel including for scratching instead of a simple midi mapping.
The difference is very clearly perceptible between the two. You can also feel this difference on traktor which only supports simple midi mapping. Trying to scratch on traktor is a nightmare compared to VDJ with the LC units.
Well what I can tell you about this, the sensitivity of the jogwheels of the LC units is identical to that of the deactivated M platter in terms of the amplitude of curvature when these two units are associated.
Apart from the fact that the M platter is heavy and has inertia because it does not have a braking system unlike the LC obviously
So you will not have more amplitude of movement wiith the LC than with a deactivated M platter. This is why I indicated in my previous post that I found the sensitivity of the jogwheels of the LC units far too high and why it seems illogical to me that the firmware of the M units does not have a sensitivity setting when LC units are attached to it unlike the firmware of the non-M units