Care to share the work-around?
I will soon in a blog-entry. Its again time-code related like what Controlled Demolition once showed off.
Cool. Looking forward to it!!
That makes sense - explains why the data looked so strange.
After few new test with Norbert (the guy at my video) I’m more agree with nemonic than ever.
The problem of wow-flutter and so leaves on how traktor understand the input data (and I remember a traktor version previously to Stanton lawsuit which has MTC and 14 bits sysex option for transport control…)
About NS7/V7 deck data DjQuartz was working on it and trying to convince Numark and Native Instruments but it seems was a “way out”. 
What lawsuit are you talking about ?
Yeah, he gave up rightfully. Being a beta-tester for Traktor Pro and also working for Numark I know the reasons behind this but can’t say anything due to NDA’s.
I’m not sure (maybe nemonic could give us some light about it) but since lawsuit about timecode patents from N2IT over Native Instruments (after break the Stanton/NI partnershipping) traktor left the midi timecode (MTC) which will be useful for Scs.1d
It will be cool know official statements almost, I don’t know what was wrong or so… Project is “stand by”? Cancelled?
Thanks to share mate!
-m!
this really sucks, everytime i talk to my numark rep he assures me that it will never happen, but i guess the rest of the numark team dosent know that because they keep confirming that it will happen.
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 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.
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.
Since when has Quartz EVER worked for Numark? I happen to know him. And who has you under an NDA?
Quartz is beta-tester for NI.
I’m beta-tester for NI and work for Numark. NDA from both.
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” 
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.
Really sadly…
Thanks for these aclarations.
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!
And OSC support. 
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.
Right! They keep OSC for clock (I think) and drop transport control!
(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?
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?
Impressive project!
Nice post. I’ve got just one question.
Won’t breaking down the data from the platters into MIDI-data greatly hurt its accuracy?
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.
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.
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.