Which controllers with motorized platter does Traktor support?
I’m working on something and would like to know which controllers with motorized platters Traktor Pro already supports.
Which controllers with motorized platter does Traktor support?
I’m working on something and would like to know which controllers with motorized platters Traktor Pro already supports.
i believe at the moment its only the DN-S3700 in hybrid mode…
what is hybrid mode? Is it MIDI only?
What about the stanton scs1d? I feel like that gets overlooked a lot
Yes very true…
and to tell ya the truth… im not 100 percent sure what hybrid mode is, i believe the platter is still time code but everything else is midi…
How’s the Stanton SCS:1D’s vinyl feeling in Traktor? Is it accurate?
Timecode may be a good hint, thank you.
The hybrid midi mode just means timecode except you don’t have to burn a timecode cd.
The only midi option currently is the stanton scs 1d.
I have a SCS.1D with TP2. For the most part it works well but it can freak out sometimes and go into a hissy fit where nothing short of rebooting traktor will fix.
For example (and this is strange) using my trackpad to slowly increase tempo will make it go bonkers yet if I use my mouse to increase the tempo it’s OK!
It’s a fine piece of kit and I am sure they will work the kinks out (they are actively testing a beta now).
It’s been out for almost 3 years now though. Do you think it’s really going to get any better than it already is?
Yeah I think it will. There are a few DJTT veterans doing the mapping it seems.
Strictly speaking, I would say none.
Traktor doesn’t specifically support any motorized platter that I know of through MIDI.
Well not exactly…
Hybrid mode is timecode signal from platter relative control and midi/hid from cues and knobs. It is specially interesting due to timecode cds could add some “drift” making the cues useless.
In other hand if we are asking about pure midi from motorized platter into traktor then you have the scs.1d and the cdx hack that I posted recently at forum. I don’t remember at this moment if there are other motorized platters (avoiding ns7/v7 which platter doesn’t work with Traktor) working with Traktor.
Maybe I’m wrong because I didn’t try dn3700 by myself but it could be understood from:
-m!
edit: add the video link for our proof of concept. It is still in alpha version but we are focused on make a retrofit kit for any circular motorized or not surface including regular turntables.
Still have a major sweetspot for the Numark CDX players. ![]()
Nice vid Mudo!
Thanks Tekki!
The whole idea is give users the possibility to upgrade “theoretical obsolete” gear and contribute to reduce our ecological fingerprint creating a open source community around these kits but as I said, it is still in “proof of concept” phase.
Nemonic has a lot of knowledge and he is a great speaker for discussing all this stuff (and source for learning). ![]()
@Mudo: How are these hacks you mentioned working?
@Hedgehog: Like the video! Arduino hijacking the signal from the platter and sending midi to software. We want to test more apps like vdj, mixxx, torq and serato which we have preparing a nice hack too ![]()
my god… please keep me in the loop with everything on this, i got a set of cdx’s laying around and cd player is broke on one of em…
Ah, I’ve got quite the opposite problem.
I’ve got a lot of proprietary midi-data and need to make sense of it so Traktor can use it.
First off, you should try looking at the data through something like MIDIOX instead of whatever app you’re using - it will format the data in a more standard format.
Second, I don’t think the data from the V7 is at all “proprietary” - it’s just MIDI. The problem is that Traktor may not understand what’s important in that data. like what’s more important - the last byte of the platter’s relative message, or the number of messages being sent? Maybe a combination of both?
Because there isn’t a standard, the few motorized platter controllers that exist all handle messaging differently. And Native isn’t supporting ANY of them directly. I don’t blame them really - should they be expected to make major changes anytime someone decides to reinvent the wheel? It WOULD be nice if they came up with a “standard messaging” that they could guarantee would give compelling performance, and then push that standard to everyone else.
I’ve written it myself.
Instead of wasting more time on this (and get low-res support out of it), I found a different workaround which works top notch.