Kontrol S4 mk3 jog wheel tracking not accurate

DLogiK

Has anyone found that the tracking on the jog wheels aren't completely accurate? With mine if you continue scratching/juggling the same bit it gradually gets displaced to the point that you have to go further along the wheel than where the sound should've started from (quite noticeable if you have marker stickers).

Sûlherokhh

I think the problem is the sensitivity of the jogwheels. I do know that on the qml mapping side that triggers all jogwheel related effects, there is variable safety margin that prevents the wheel ticks from translating to jog function unless the minimum ticks/[time interval] is exceeded. It is spelled out in the function wires for adjusting the beat grid. The jogwheel functions for tempobend, scratch and seek have been collected to a function packet with some extras that is inaccessible. The basic functions could be manually reconstructed with the sensitivity lowered (incidentally, the turning direction's sensitivity can be set seperately).

I haven't tried to reprogram the basic functions myself, but i managed to implement all of the above for master clock tempo control successfully for my s4mk3.

Just for info, this is how my master clock looks like:

     Wire
         {
             enabled: jogControlMasterClock
             from: "%surface%.jogwheel.rotation"; 
             to: EncoderScriptAdapter 
             {
               onTick: 
               { 
                   const minimalTickValueMasterClockAuto = 0.0009;
                   const minimalTickValueTempoAdjust = 0.001;
                   const minimalTickValueTempoAdjustX = 0.01;
                   const rotationScaleFactor = 0.5;
                   const rotationScaleFactorX = 5;
                   if (value < -minimalTickValueMasterClockAuto || value > minimalTickValueMasterClockAuto)
                       propMasterClockID.value = -1; 
                       propMasterClockAuto.value = 0; 
                   if (value < -(minimalTickValueTempoAdjust) || value > (minimalTickValueTempoAdjust))
                       propMasterClockTempo.value = propMasterClockTempo.value + (value * rotationScaleFactor); 
                   if (value < -(minimalTickValueTempoAdjustX) || value > (minimalTickValueTempoAdjustX))
                       propMasterClockTempo.value = propMasterClockTempo.value + (value * rotationScaleFactorX); 
               }
             }
         }

This moves the clock 'not at all' below the first sensitivity level (in both directions), slow between the first and second level, fast above the second level. I am sure the same things can be done for scratching functions. Somehow i doubt N.I. will update the code very soon. There are a few other things with the S4 that N.I. has so far failed to address.

Uwe303

Hello,

I don't own that controller myself, but maybe it is velocity dependent. Have you tried it really slow?

Uwe

Sûlherokhh

I think the problem is the sensitivity of the jogwheels. I do know that on the qml mapping side that triggers all jogwheel related effects, there is variable safety margin that prevents the wheel ticks from translating to jog function unless the minimum ticks/[time interval] is exceeded. It is spelled out in the function wires for adjusting the beat grid. The jogwheel functions for tempobend, scratch and seek have been collected to a function packet with some extras that is inaccessible. The basic functions could be manually reconstructed with the sensitivity lowered (incidentally, the turning direction's sensitivity can be set seperately).

I haven't tried to reprogram the basic functions myself, but i managed to implement all of the above for master clock tempo control successfully for my s4mk3.

Just for info, this is how my master clock looks like:

     Wire
         {
             enabled: jogControlMasterClock
             from: "%surface%.jogwheel.rotation"; 
             to: EncoderScriptAdapter 
             {
               onTick: 
               { 
                   const minimalTickValueMasterClockAuto = 0.0009;
                   const minimalTickValueTempoAdjust = 0.001;
                   const minimalTickValueTempoAdjustX = 0.01;
                   const rotationScaleFactor = 0.5;
                   const rotationScaleFactorX = 5;
                   if (value < -minimalTickValueMasterClockAuto || value > minimalTickValueMasterClockAuto)
                       propMasterClockID.value = -1; 
                       propMasterClockAuto.value = 0; 
                   if (value < -(minimalTickValueTempoAdjust) || value > (minimalTickValueTempoAdjust))
                       propMasterClockTempo.value = propMasterClockTempo.value + (value * rotationScaleFactor); 
                   if (value < -(minimalTickValueTempoAdjustX) || value > (minimalTickValueTempoAdjustX))
                       propMasterClockTempo.value = propMasterClockTempo.value + (value * rotationScaleFactorX); 
               }
             }
         }

This moves the clock 'not at all' below the first sensitivity level (in both directions), slow between the first and second level, fast above the second level. I am sure the same things can be done for scratching functions. Somehow i doubt N.I. will update the code very soon. There are a few other things with the S4 that N.I. has so far failed to address.

Stevan

https://community.native-instruments.com/discussion/comment/2130#Comment_2130

Let's hope they will address some of shortcomings at least.

DLogiK

https://community.native-instruments.com/discussion/comment/2126#Comment_2126

Just tried it and it's either tracking on point or the displacement is not very noticeable. But unfortunately still does if it moves quickly, especially when spinning back and forth in large amounts like in beat juggling :/ Thanks for the suggestion though.

DLogiK

https://community.native-instruments.com/discussion/comment/2130#Comment_2130

Thanks for your detailed reply. So it might be possible to fix if you edit the QML mapping? Unfortunately I haven't the slightest clue about coding so I guess I'ma have to wait until NI fixes it..:/

zephry

Maybe a long shot? But in settings, does the RPM choice effect this? Or ticks on off? Or maybe even the tension?

x-tropic

I have the same problem and I noticed that in TT mode, the sensitivity is quite normal, but in "jog" mode everything is much slower and you have to do more movements to rewind to the beginning of the starting point. I want to clarify. that this only happens during deck playback, when you release the jog to make the sound play at the original speed, and then you need to quickly return it and in this case, in jog mode, the return sensitivity is very low compared to TT mode.

I think it would be great to add a sensitivity control so that everyone can adjust to their preferences.

DJ_DichOtomy

It has a name, it's called "sticker drift" and they actually have fixed that now in one of the recent updates. It's not perfect, but it's good enough now that you can work with it. I got so used to it that I'd automatically compensate when i was scratching and then it got fixed and I had to retrain my muscle movements again.

The thing that made me mad was out of countless reviews I read and all the research I did before I bought my s4, not one review or article mentioned it and I noticed it the first time I went to scratch. I almost got rid of the controller because in my mind that was a deal breaker.

s4mk3

Would be nice if there was a way to turn off that back spin feature to see if that's the issue?

ForrestEdgar

I can assure you that the accuracy of jog wheel tracking is crucial for smooth and precise DJ performance. While Native Instruments offers high-quality DJ controllers and software, occasional issues may arise with jog wheel tracking. If you find that the tracking on your jog wheels is not completely accurate and the sound gradually gets displaced as you continue scratching or juggling.