Which controllers with motorized platter does Traktor support?

[Mudo]

The lawsuits with N2IT (which both NI and Stanton, along with many others were involved in separately) have nothing to do with the fact that NI doesn't directly support moving platter controllers. N2IT's patent infringement lawsuits didn't effect SCS.1 (at least not in the way you're implying).

The version before "breaking" the partner had mtc and 14 sysex for transport control. The version after dropped it. These are facts, the rest my opinion of course...

I'm only saying "that's suspicious"

The biggest problem (in my opinion) with SCS.1 is that it was never fully developed. At it's core, the concept is fantastic. And the hardware implementation would be (mostly) fine if there was a software partner that offered direct support at release. But that didn't happen - which is ONE of the reasons that the DaRouter solution was utilized.

It is the same which told me Norbert with actual cdx hack. We are considering make a basic maxmsp/pd patch like "da router" solution but open source code.

Honestly, I don't think we've seen what SCS.1 can really do. I still think that clever programming and the right firmware could radically change the product. But I'm not sure the executive staff at Stanton is willing to do the things necessary to make the product right (they certainly weren't while I was there - instead wanting to nickle and dime the issue). There are some clever people working on it now, and I hope they're able to accomplish something amazing in spite of the corporate climate.

Really sadly...

Nemonic has a lot of knowledge and he is a great speaker for discussing all this stuff (and source for learning).

Thanks for these aclarations.

[nem0nic]

I'm beta-tester for NI and work for Numark. NDA from both.

You work out of the Willich office? If so, PM me! We have an office there too, and I spent a month there in April. Next time I'm there, we'll have some drinks at Cena Bona!

The version before "breaking" the partner had mtc and 14 sysex for transport control...

And OSC support.

It is the same which told me Norbert with actual cdx hack. We are considering make a basic maxmsp/pd patch like "da router" solution but open source code.

Are you planning on grabbing the raw data out of the SCS.1 through HSS1394?

Mudo, if you need any help - please consider me a resource.

[Mudo]

And OSC support.

Right! They keep OSC for clock (I think) and drop transport control!

Are you planning on grabbing the raw data out of the SCS.1 through HSS1394?

Mudo, if you need any help - please consider me a resource.

(Big Thanks and) We are going to make a blog entry inviting community to get involved, any help/contribution are welcome. I believe it could be not "so much" work implement the input data from scs.1d... it is recognized as "midi in" right?

[Afterhour Ali]

spanish? orly?

Have you considered writing bilingual?
I recommend the qTranslate plugin for Wordpress. Have been using it for years.

[Mudo]

spanish? orly?

Have you considered writing bilingual?
I recommend the qTranslate plugin for Wordpress. Have been using it for years.

Uhm... it is in booth languages (maybe with mistakes due my english skills without online translation correction)

Could you check it again please?

[GeekGod]

I ended up using http://translate.google.com/translat...preview%3Dtrue

Impressive project!

[Afterhour Ali]

Nice post. I've got just one question.

Won't breaking down the data from the platters into MIDI-data greatly hurt its accuracy?

[Mudo]

It is a good question... at this time with only one buffer and arduino based solution we have the trouble with "missed bits" in addition with the lack of poor configurations options in traktor.
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.

To me the system implement by vdj with xml is a great idea. Mixvibes and Mixxx seem to have a good options in this way to... so that's the part about "collaborative" and "open source" because we want to save the old gear in addition to maybe create a new one platform which "glues" all of them.

[Afterhour Ali]

What you're trying to achieve is pretty honourable.

Why not define an open standard for this kind of data? It would be definitely cool if NI would define specifications for an interface we could use to feed it platter-data from our devices.

I backed off translating the NS7's MIDI data because I'd only feed MIDI to Traktor which is not precise enough for a good feeling. That's why I use Virtual DJ as my slave-application now to get a Timecode signal to Traktor. The resolution of the timecode signal is good enough. Its just the latency and unnecessary complexity of this solution which bothers me.

[nem0nic]

Won't breaking down the data from the platters into MIDI-data greatly hurt its accuracy?

No. Why would it? The SCS.1d has roughly 4000 counts of resolution per rotation. The messaging the platter sends is a relative message, and it sends a message every "tick" of the platter (count of resolution). This is higher than the resolution of either Serato's or NI's timecode BTW, and you don't have the additional problem of missed bits and error checking. The DJ application is looking at not only the last byte of the platter CC, it's also looking at the stream of time-stamped CC messages against a clock to determine platter movement speed.

MIDI is capable of being as "fast" as it's carrier is capable of going. So if it's traveling down 5pin DIN, it's going to be slower than if it's traveling down (for instance) USB or Ethernet. And because it's a simpler protocol than something like HID, there is less overhead (making it faster still).

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.

This is changing slowly, and some manufacturers are choosing to adopt HID instead of MIDI (for many reasons) - fracturing the market further. Unfortunately for users, there isn't really a good motivation for the industry to establish a "standard". It really isn't in their best interest - especially now when there's so much flux. There's new technologies waiting to be developed, new hardware to sell, and no reason at all for anyone to hitch their wagon to a single standard when it could all change when the new hotness comes along.