Which controllers with motorized platter does Traktor support?

[GeekGod]

nem0nic: any idea when we will see this: "To Solve this we are Developing a new version with Integrated USB MIDI over (without FDTI) Which is amazing Enhance STI "

Just curious, I would love help test when it's ready (or close).

Great project!

[Afterhour Ali]

Do you have more details how Traktor handles the Scratch/Pitch bend command with encoders?
I'll still need details from the Numark engineerers on how to make sense of the midi data which is sent by the platter. I just don't understand it.

Should I seperate the midi data coming from the platter into timeslots. I mean I collect all data received from it and evaluate what to send to Traktor every 40 milliseconds.

[zestoi]

Should I seperate the midi data coming from the platter into timeslots. I mean I collect all data received from it and evaluate what to send to Traktor every 40 milliseconds.

can't traktor process all the relative message commands fast enough or it just drops some? i am curious why scratching on a midi controller doesnt seem to be as responsive as via timecode from what everyone says when in theory midi over usb should be fast enough afaik.

is that why this statement from Mudo?

Dedicated solution (such DaRouter or even custom software) will be better to do the job. That's the reason for all the troubles that make start the topic more or less... and the reason for non-standard with every brand trying to find the best solution.

with 4k ticks per revolution surely 14bit absolute messages could be sent out at a rate that trakor can handle. ah... thats the point of using something like darouter? to reduce the traffic?

surely even a 7bit relative message would also work - with different values depending on how matter platter ticks have passed - or can't traktor be setup to handle that precisely? (i've played about with the jog settings in treaktor but not 100% of what does what )

edit: cheers Mudo for the english translation on your page...

[nem0nic]

nem0nic: any idea when we will see this: "To Solve this we are Developing a new version with Integrated USB MIDI over (without FDTI) Which is amazing Enhance STI "

No idea. Should ask Mudo, since I think he's the one who said it.

Do you have more details how Traktor handles the Scratch/Pitch bend command with encoders?

Not sure what you're asking here. What are you trying to achieve?

Should I seperate the midi data coming from the platter into timeslots.

Don't know how to answer this one either. MIDI data should be time stamped from the controller. Many controllers do this, so it should be easy enough to use something like MIDIOX to take a look at the data coming off a platter and make sense of it.

Also, just out of curiosity, how did you arrive at the 40ms throttling value?

...from what everyone says when in theory midi over usb should be fast enough afaik.

The problem is not (never has been) that MIDI isn't fast enough to handle modern DJ needs. That's bullshit. The problem is that there isn't a standard for platter messaging, and most DJ software have MIDI "engines" that are less robust and developed than their timecode "engine". MIDI has been seen until very recently as support for add-ons that require relatively little bandwidth. So lots of software developers have MIDI engines that reflect that mentality, with poor buffering strategies (that are prone to overflow), low priority handling, and poor support for higher resolution control.

with 4k ticks per revolution surely 14bit absolute messages could be sent out at a rate that trakor can handle. ah... thats the point of using something like darouter? to reduce the traffic?

The bit depth of the message isn't a factor at all in this case. Please explain what exactly you gain by assuming 14bit messaging. And no, DaRouter isn't there to reduce the traffic.

[zestoi]

The bit depth of the message isn't a factor at all in this case. Please explain what exactly you gain by assuming 14bit messaging. And no, DaRouter isn't there to reduce the traffic.

just meant you could send some kind of absolute message for platter position if the platter had 40k different positions and you were using 14bit messages. not saying that it would be any use in traktor at all ofc.

i hadn't even looked at 14bit messages until the other day actually - and currently my own midimasher (darouter type app) doesn't support them and not yet convinced it needs to for what i want.

[Afterhour Ali]

Do you have more details how Traktor handles the Scratch/Pitch bend command with encoders?

Not sure what you're asking here. What are you trying to achieve?

To get the NS7 platter to do anything useful in Traktor I need to do three things:

• Make sense of the data coming from it
• Turn it into something useable by Traktor
• Get the whole motorized platter thing working in a environment for non-motorized platters

For the first point I'll ask the responsible Numark engineers for details and investigate further myself.
The third point is easy as all it requires is sending the correct midi-values to the device to start/stop/slow down/speed up the platter.

For the second point I need to understand what it means if I send a certain midi-value to Traktor's Scratch/Pitchbend function, how time between these events influences it etc.
I can research this myself but I guess someone of you already did that.

Should I seperate the midi data coming from the platter into timeslots.
Don't know how to answer this one either. MIDI data should be time stamped from the controller. Many controllers do this, so it should be easy enough to use something like MIDIOX to take a look at the data coming off a platter and make sense of it.

Also, just out of curiosity, how did you arrive at the 40ms throttling value?

40ms was just a wild guess.
How does the time-spamping work for these controllers?

I've written a tool myself to analyze it. It isn't easy to make sense of it.

[nem0nic]

just meant you could send some kind of absolute message for platter position if the platter had 40k different positions and you were using 14bit messages. not saying that it would be any use in traktor at all ofc.

I understand, but no one is using absolute messaging for platter control that I am aware of. It's actually a neat idea, but not implemented.

I can research this myself but I guess someone of you already did that.

I'm going to assume that Traktor isn't looking for a string of packets to feed a pitch bend message, but rather a note. I know there have been some changes in 2.02 to platter messaging, and there are several platter messages to map towards, but none of those messages (that I know of) are actually pitch bend messages. That's why I was asking for more info. It seems like you're actually asking about the behavior of the "pitch bend" mode of one of the platter messages. Is this the case?

40ms was just a wild guess.

I think it's way too conservative. I think you'd be safe up to 1 message per ms. The way to know for sure would be to program a script or translator that would send out messages based on a timer. You could make the timer value a variable, and that variable would be fed by an absolute CC message (so you could control it). You could then feed your target application a flood of MIDI messages until you experience it "choking" on the data.

Just remember to take into consideration when you're doing this to determine something like platter messaging that you're going to have 2 platters going, plus MIDI feedback, faders and EQs moving etc. Be sure to build in some overhead.

[Afterhour Ali]

It seems like you're actually asking about the behavior of the "pitch bend" mode of one of the platter messages. Is this the case?

Yeah, from what I know all platters are mappend using the "Jog Scratch + Tempo Bend" function in Traktor.
I'll handle most of the motor-stuff in my wrapper-application. This way I can turn the motorized platters into a non-motorized ones (by evaluating the original platter data in an intelligent way).

You could make the timer value a variable, and that variable would be fed by an absolute CC message (so you could control it)

I don't understand this. Can you explain it in a different way?

Also on another note I'm trying to get in touch with the engineers of Numark who built the thing since I can't make sense of the platter data.

Every "message" sent by it consists of two midi-messages. the first byte on the first one is always the same and the first two bytes on the second ones are always the same.
Effictively I get 3 Bytes worth of data per message.

What I call a message is the smallest indivisible data-packet send by the platter.
I've got hundreds or thousands of these per second so the data has a very high precision.

You have an idea how I can make sense of this data myself? The first byte is easy as it becomes higher when spinning forward and lower when spinning backwards. The other two bytes just change wildly without a pattern in every message.

[nem0nic]

You have an idea how I can make sense of this data myself?

I would expect a standard MIDI message to be 3 bytes long, so that actually makes sense. What are you looking at the MIDI data in? Are you using something like MIDI Hack or MIDIOX? If not, try using them instead.

Without seeing a properly formatted capture, I would guess that the "first byte" you're referring to is actually the last byte of the MIDI message. If it were a relative message (which would be typical), it would center around the value 64 (in hex) and either be greater (moving forward) or less than (moving backwards). I'm guessing what you're looking at for the rest of the data is actually the timestamp.

I've got hundreds or thousands of these per second so the data has a very high precision.

This sounds right. I think the NS7 has 3600 counts of resolution.

[Afterhour Ali]

I've coded my own tool to analyze the data. It put both messages together and doesn't display the 3 bytes used to identify the message.
Then it shows only the other 3 bytes which contain actual data.

This is the data of a tiny forward movement for example.

W 1 = 127, W 2 = 063, W 3 = 072
W 1 = 000, W 2 = 061, W 3 = 028
W 1 = 001, W 2 = 092, W 3 = 012
W 1 = 002, W 2 = 056, W 3 = 084
W 1 = 003, W 2 = 078, W 3 = 110
W 1 = 004, W 2 = 117, W 3 = 049
W 1 = 005, W 2 = 001, W 3 = 071
W 1 = 006, W 2 = 083, W 3 = 063
W 1 = 007, W 2 = 127, W 3 = 034
W 1 = 008, W 2 = 019, W 3 = 117
W 1 = 009, W 2 = 043, W 3 = 058
W 1 = 010, W 2 = 101, W 3 = 117
W 1 = 011, W 2 = 109, W 3 = 040
W 1 = 012, W 2 = 070, W 3 = 084
W 1 = 013, W 2 = 055, W 3 = 122
W 1 = 014, W 2 = 112, W 3 = 027
W 1 = 015, W 2 = 095, W 3 = 057
W 1 = 016, W 2 = 111, W 3 = 084
W 1 = 017, W 2 = 016, W 3 = 110
W 1 = 018, W 2 = 085, W 3 = 006
W 1 = 019, W 2 = 003, W 3 = 031
W 1 = 020, W 2 = 019, W 3 = 056
W 1 = 021, W 2 = 117, W 3 = 082
W 1 = 022, W 2 = 113, W 3 = 111
W 1 = 023, W 2 = 013, W 3 = 016
W 1 = 024, W 2 = 098, W 3 = 052
W 1 = 025, W 2 = 008, W 3 = 095
W 1 = 026, W 2 = 007, W 3 = 016
W 1 = 027, W 2 = 111, W 3 = 073
W 1 = 028, W 2 = 120, W 3 = 015
W 1 = 029, W 2 = 018, W 3 = 102
W 1 = 030, W 2 = 042, W 3 = 081
W 1 = 031, W 2 = 107, W 3 = 094
W 1 = 032, W 2 = 052, W 3 = 053
W 1 = 033, W 2 = 075, W 3 = 048
W 1 = 032, W 2 = 111, W 3 = 105
W 1 = 031, W 2 = 000, W 3 = 124
W 1 = 030, W 2 = 007, W 3 = 099
W 1 = 029, W 2 = 122, W 3 = 018
W 1 = 028, W 2 = 058, W 3 = 090
W 1 = 027, W 2 = 117, W 3 = 018
W 1 = 026, W 2 = 109, W 3 = 014
W 1 = 025, W 2 = 107, W 3 = 111
W 1 = 024, W 2 = 038, W 3 = 070
W 1 = 023, W 2 = 118, W 3 = 030
W 1 = 022, W 2 = 004, W 3 = 008
W 1 = 021, W 2 = 051, W 3 = 014
W 1 = 020, W 2 = 122, W 3 = 068
W 1 = 019, W 2 = 077, W 3 = 086
W 1 = 018, W 2 = 086, W 3 = 066

Even if the latter two bytes is a timecode. Which format is it? Will I even need that data?

Did you figure out how the "Scratch + Jog Bend" command works? >64 is forward, <64 backwards but aside from that how often does it expect data?