What is considered "normal" latency and lag with controllers? Moving from SSL

[robscomputer]

Hello,

I'm pretty new to the digital controller world, mostly my experience is with Serato Scratch Live and now a few weeks into Traktor Pro 2. To save space from using turntables I recently purchased a Vestax VCI-400SE. But finding that the delay with the jog wheels/fader is more than I expected. My laptop is current Apple MBP and should be able to handle the load of playing a song with no effects.

I wanted to ask is this latency normal for all controllers? I heard that the only controller with near zero latency is the Kontrol S2/S4 due to HID integration but are there other controllers that also make use of HID? If I switched to an Serato Itch based controller will I have better performance. My requirements are pretty low, I just need something responsive, hardware controls for browsing, and maybe some fx's.

Thanks!

[nem0nic]

When you talk about latency, you're talking about a LOT of things - most of which have nothing to do with the MIDI controller. So basing your controller decision on latency is a lot like basing your car decision on what the weather is like today.

Go out and get your hands on some controllers and figure out which one you like the best - then buy it.

[mostapha]

There's no reason that your MBP should be running noticeable latency. It's also probably not the controller's fault. It has more to do with the audio buffer.

What latency is your sound card running at? Anything over about 8-10ms round trip, I start to get annoyed by. My 2011 MBP can easily do <4ms latency depending on the audio card.

[KLH]

...I recently purchased a Vestax VCI-400SE. But finding that the delay with the jog wheels/fader is more than I expected.
What you're describing isn't latency of digital audio, but rather a (rather large) lag due to MIDI and jog wheels. ALL standard MIDI devices have this lag on jog wheels because the data transfer is too slow AND the resolution of data being transferred is too low.

Native Instruments, Serato, and Denon have each made a custom way of addressing this lag. NI uses HID/USB unique to the S2 and S4. Serato has a customized high-speed MIDI for their ITCH products (for Numark and Vestax specifically). Denon (supposedly) uses standard MIDI just at high-speed (at USB 2.0 speeds).

The thing to realize is that EACH method is proprietary and must be accounted for if compatibility with each hardware is desired. IIRC VirtualDJ is the only DJ app that works with all of these devices.


I wanted to ask is this latency normal for all controllers? I heard that the only controller with near zero latency is the Kontrol S2/S4 due to HID integration but are there other controllers that also make use of HID? If I switched to an Serato Itch based controller will I have better performance.
Latency exists across all digital audio software programs, but this isn't what you're referring to.

The S2, S4, NS7, NS6, VCI-300, and MC6000 controllers should NOT have the jog-wheel lag that standard MIDI devices have... but to do so, you'll have to use TP, TP, ITCH, ITCH, ITCH, and VDJ respectively.

Are we having fun yet?

-KLH

[robscomputer]

What you're describing isn't latency of digital audio, but rather a (rather large) lag due to MIDI and jog wheels. ALL standard MIDI devices have this lag on jog wheels because the data transfer is too slow AND the resolution of data being transferred is too low.

Native Instruments, Serato, and Denon have each made a custom way of addressing this lag. NI uses HID/USB unique to the S2 and S4. Serato has a customized high-speed MIDI for their ITCH products (for Numark and Vestax specifically). Denon (supposedly) uses standard MIDI just at high-speed (at USB 2.0 speeds).

The thing to realize is that EACH method is proprietary and must be accounted for if compatibility with each hardware is desired. IIRC VirtualDJ is the only DJ app that works with all of these devices.


Latency exists across all digital audio software programs, but this isn't what you're referring to.

The S2, S4, NS7, NS6, VCI-300, and MC6000 controllers should NOT have the jog-wheel lag that standard MIDI devices have... but to do so, you'll have to use TP, TP, ITCH, ITCH, ITCH, and VDJ respectively.

Are we having fun yet?

-KLH

Thanks for the break down on that. I'm still new to the whole idea of controllers and not sure what is expected. I keep hearing how great the NI S4 jog wheels are but also they are as mentioned proprietary technology, not used with other controllers in Traktor. Could I get the precise feel of the S4 with Traktor, by using say the NS6 with Itch?

[KLH]

The Vci-300 proved the concept and the NS7 (both with ITCH) drove it home. Hi speed MIDI and/or HID are here to stay.

You'll get similar performance across all of the controllers that I mentioned. BTW, I forgot to mention the V7 (ITCH).

-KLH

[Defiance]

KLH hit it right on the head.

Between my VMS4, Mixtrack, and NS6 all have different 'feels' in that department. I find the delay resides in the 'touch-sensitivity' of the jog-wheels the most, more than the back-forth motion of the the platter. I also have no comparable experience with other formats of DJing so its more 'normal' to me.

[Budzak]

I just got the VCI-300mkII a few days ago, and all I can say is that it feels locked on. I have the latency set at 5ms for now and it feels good. Not really much of a difference between that and when I use timecode vinyl on SSL.

[robscomputer]

I just got the VCI-300mkII a few days ago, and all I can say is that it feels locked on. I have the latency set at 5ms for now and it feels good. Not really much of a difference between that and when I use timecode vinyl on SSL.

I'll need to check my settings as it's not even close to a DVS feel. I was expecting some delay but it feels more than a few MS of lag when I move the jog wheel back and forth. This weekend I'm going to test out a NS6, just to compare how it feels against the VCI-400/Traktor. Also I'm going to adjust the latency settings from default to a lower number.

If this all fails, I'll just stick with SSL. :)

[KLH]

There's no setting for "jog-wheel lag." The latency setting is for buffering digital audio on your sound interface.

-KLH

[nem0nic]

What you're describing isn't latency of digital audio, but rather a (rather large) lag due to MIDI and jog wheels. ALL standard MIDI devices have this lag on jog wheels because the data transfer is too slow AND the resolution of data being transferred is too low.
Unfortunately this is incorrect. MIDI is as fast as the transport mechanism.


Serato has a customized high-speed MIDI for their ITCH products (for Numark and Vestax specifically)
Customized how exactly? Oh, and here's some rope.


Denon (supposedly) uses standard MIDI just at high-speed (at USB 2.0 speeds).
Denon actually uses what Serato calls "HIDI", which is a combination of HID and MIDI. And hybrid mode on the 3700 is a combination of MIDI and timecode.


The thing to realize is that EACH method is proprietary and must be accounted for if compatibility with each hardware is desired.
I would only consider the Native solution proprietary.


The S2, S4, NS7, NS6, VCI-300, and MC6000 controllers should NOT have the jog-wheel lag that standard MIDI devices have... but to do so, you'll have to use TP, TP, ITCH, ITCH, ITCH, and VDJ respectively...
I'm sorry, but this is the kind of uninformed post that perpetuates ignorance.


Could I get the precise feel of the S4 with Traktor, by using say the NS6 with Itch?
There's a lot going on in the NI jog wheels, and most of that special sauce has nothing to do with the communication protocol. It's a 10bit message traveling over USB. It's no faster than MIDI would be traveling down the same USB connection.

The effect you're seeing is the benefit of tight integration between hardware and software. In all of these cases, the controller in question was designed to work in a specific software environment. OF COURSE the NS7 is going to work amazing in Itch even though it uses standard MIDI. Both products were engineered to work together. So if you're looking for tight integration between hardware and software, these highly tuned solutions are going to deliver.

But this IS NOT an issue of "lag due to MIDI and jog wheels".

[KLH]

Unfortunately this is incorrect. MIDI is as fast as the transport mechanism.
That is news to me. I stand corrected (http://www.midi.org/aboutmidi/midi-osc.php).


Customized how exactly?
I was incorrect on standard MIDI being tied to transport mechanism. As such, the "customization" of being high-speed is also incorrect.


I would only consider the Native solution proprietary.
It is just as proprietary as the others. Barring possibly the MC6000, there is no standard (meaning MIDI-based) way of supporting the platters on the controllers I mentioned without explicit permission from the manufacturers.


The effect you're seeing is the benefit of tight integration between hardware and software. In all of these cases, the controller in question was designed to work in a specific software environment... But this IS NOT an issue of "lag due to MIDI and jog wheels".
I beg to differ but can only say that because of anecdotal experiences: Torq, Traktor, Virtual DJ, and ITCH do not provide the tight performance of the respectively-designed controllers when using the controller's MIDI modes. If what are saying is true, then ALL MIDI implementations should be compatible without the need for native support (which IIRC only Virtual DJ offers).

When using only MIDI, the NS7 and V7 do not perform on Traktor as they do in ITCH. The S2 and S4 do not perform as they do in Traktor when they're in MIDI mode.

Yet the Xponent and VCI-100 do perform exactly the same in Traktor as in Torq. You can argue that they don't have the 14bit resolution required, but I was under the impression that it was also that they didn't have the speed of transfer.

I'd love to be wrong and have the VCI-400SE's performance be as tight as the S4. What do you recommend to achieve this, Nems? As the VCI-400 uses only standard MIDI over USB and 14-bit resolution, why isn't it as tight?

-KLH

[nem0nic]

It is just as proprietary as the others.
The others aren't proprietary - they're either HID or MIDI. Both protocols are pretty standard, which is why Virtual DJ can support them (as VDJ can communicate via HID or MIDI, and uses a device definition file to standardize the way you address the device via the mapper file). The Native protocol is neither HID or MIDI. It's something they created for themselves.

pro·pri·e·tar·y
1. belonging to a proprietor.
2. being a proprietor; holding property: the proprietary class.
3. pertaining to property or ownership: proprietary wealth.
4. belonging or controlled as property.
5. manufactured and sold only by the owner of the patent, formula, brand name, or trademark associated with the product: proprietary medicine.


I beg to differ but can only say that because of anecdotal experiences: Torq, Traktor, Virtual DJ, and ITCH do not provide the tight performance of the respectively-designed controllers when using the controller's MIDI modes.
You're drawing conclusions based on information you don't understand. I'll give you an example...


You can argue that they don't have the 14bit resolution required...
What is the 14bit resolution "required" for? What KIND of 14bit message? Jog platters usually use a 7bit relative CC message to communicate their movement - including the high resolution platters. This can happen because relative CC messages send a message per platter "tick". The last byte of that message communicates the direction of rotation and velocity, but the software is also determining platter movement by looking at the NUMBER of ticks per interval, and using precise timestamps on each message to sequence the messaging. So even though a message is 7bit, it can still send thousands of discreet messages per second.

So your assumption that 14bit messaging is used (required) on platters is incorrect.

So why is 14bit messaging important enough to be an advertised feature? When you see it being used, it's almost always referring to a control that is sending an ABSOLUTE CC message. A 7bit absolute CC message is comprised of 128 steps, and this type of message is commonly used for things like potentiometers (knobs or faders with a defined range of travel). In many cases, 128 steps isn't enough resolution to give compelling performance - like on a pitch fader. So it's preferable to use a 14bit message there. It's still an absolute message, but with 16384 steps instead of 128. Of course, there are other issues that may work to lower that resolution, but it's still much more compelling than 128 steps.


What do you recommend to achieve this, Nems? As the VCI-400 uses only standard MIDI over USB and 14-bit resolution, why isn't it as tight?
There are many things at play here that have already been mentioned above. Your audio interface latency is a usual suspect for funky lag. And no - the number you see in the Traktor preferences applet isn't your actual latency. The next thing you need to do is to tune your platter to your taste. A good way to do this using Traktor Scratch is to set deck A for MIDI control and load a file containing timecode into it. Route audio from A OUT to B IN and set deck B to run under timecode control. Now you have a visual representation of the platter. Have the MIDI preferences open and the platter message for deck A highlighted, and turn the acceleration to 0. Now align the movement of the platter with the TC widget in deck B. You're going for a 1:1 relationship between the two, so a single rotation starting at 12o'clock on the platter translates to the same in deck B. Once you get the sensitivity roughly dialed in, use the acceleration to tweak performance on the smaller, tighter moves. You'll have to play with both settings a bit to get it right, but this is the best way to set up platters that I've found.

But also, as I said before, you're trying to compare a product that was meant to be easily compatible with everything (the VCI400) with a product that was designed to work with a single piece of software (which was also tweaked to accommodate it). The S4 has quite a bit of "secret sauce" in it (like the position aware top platter) that can only be utilized through Traktor.

[KLH]

So your assumption that 14bit messaging is used (required) on platters is incorrect.
I was under the impression that the NS7 used 14bit MIDI messaging to determine platter movement, using ABSOLUTE CC values to determine position as 14bit resulting a wider range of values to represent platter position. If the NS7 uses relative CC messaging, then I have simply misunderstood how the NS7 works.

I haven't analyzed the NS7 with MIDIOx. Now I wish that I had when I owned one.

-KLH

[nem0nic]

I haven't analyzed the NS7 with MIDIOx. Now I wish that I had when I owned one.
This reminds me of something. There is another reason why message X might work better than message Y, and you made me think of it.

There are different kinds of relative message. Numark likes to use a "2s comp" relative message for their platters. It works in the same way as other relative messages, except the starting and stopping points of the forward and backward messaging is reversed. So you might also find that program X doesn't work with 2s comp messages, but works great with binary offset messages. This kind of thing can also bite companies that make more generic MIDI controllers (instead of targeting their controller for a specific software).

[KLH]

The S2, S4, NS7, NS6, VCI-300, (V7) and MC6000 controllers should NOT have the jog-wheel lag that standard MIDI devices have... but to do so, you'll have to use TP, TP, ITCH, ITCH, ITCH, (ITCH) and VDJ respectively.
While I may have been incorrect on how they accomplished the integration, I stand by the main point. These controllers offer higher performance with their intended DJ apps than other controllers.

-KLH

[nem0nic]

While I may have been incorrect on how they accomplished the integration, I stand by the main point. These controllers offer higher performance with their intended DJ apps than other controllers.
I agree. Any integrated solution will perform better than a "generic" solution. But the reasoning behind your conclusion was incorrect. The only reason I chimed in to correct you is because those conclusions maligned a protocol that is much better in the long run for our industry than something locked down - like HID or NHL.

[Defiance]

This reminds me of something. There is another reason why message X might work better than message Y, and you made me think of it.

There are different kinds of relative message. Numark likes to use a "2s comp" relative message for their platters. It works in the same way as other relative messages, except the starting and stopping points of the forward and backward messaging is reversed. So you might also find that program X doesn't work with 2s comp messages, but works great with binary offset messages. This kind of thing can also bite companies that make more generic MIDI controllers (instead of targeting their controller for a specific software).

Where do you find information like "Numark likes to use a 2s Comp" relative message for their platters?

Whenever I try and find detailed information about construction of dj equipment all I find is the spec list for that product lol

[nem0nic]

Where do you find information like "Numark likes to use a 2s Comp" relative message for their platters?
Usually I sit down with the product and look at the output. Programs like MIDIOX are great, and free.

[Scrap McNapps]

There's no reason that your MBP should be running noticeable latency. It's also probably not the controller's fault. It has more to do with the audio buffer.

What latency is your sound card running at? Anything over about 8-10ms round trip, I start to get annoyed by. My 2011 MBP can easily do <4ms latency depending on the audio card.

Yessir. 10ms round trip should be the highest.