DIY 14 Bit Midi

[Mudo]

...

Thanks Nemonic,
I'm not pissed off, I said that I "understood" from the old discussion and I'm not defending HID over MIDI as a closed protocol, I love MIDI but it seems that Numark has MIDI for open solutions but HID for ITCH. They argue it is better for response and (based in my own research with arduino) I could understand why they say those.

In the other hand I know you are involved in SCS.1d develop... is not? Then please explain me WHY is so crappy at scratching? It is due to platter itself and nothing to protocol?

When some users where discussing at Ms. Pinky forum about what protocol and why use them... we were talking the same doubts...

I love when Fatlimeny or you correct me (somebody has to I'm only a madman advertiser xD) because there are some facts that not are clear and my argues focus on find answers.

Without my wrong argues I will never find truth, sorry.

My apologizes for booth and please if you (fatlimey and/or yourself) could bring some tech info about protocols, physical connections and so on... please share them!

At last, as I said before:

If you use an arduino (or any micropic based in FDTI chip) you will have a funnel because it is emulating a serial port.

HID "seems" more fast than the other protocols and I thinks it is due to kind of interrupt/message output. About close or open (I prefer open of course), well... I'm working on it and I will share my efforts, of course.



...

[nem0nic]

Serato is writing support for both HID and MIDI in their applications, but according to everything we've seen so far, the NS7 is communicating via MIDI - NOT HID.

The SCS.1 controllers were developed several years ago, before anything like them existed in the market. They weren't working with something that was already in the market, so there were no standards to work towards. MIDI was the standard and a natural choice. They had working prototypes in 2007, and showed the SCS.1 system live and working at NAMM 2008.

Throughout the development, they tried to choose open standards and give developers and users a platform to work with that was easy. That's why MIDI Translator was used for example. But our mistake (in my opinion) was not to target a single app instead of choosing the more open route. It meant that while we had the potential to work with a number of different programs, we were a master of none. This is where we are right now with the platter implementation on the SCS.1d.

If you look at the raw output of the SCS.1d through something like the testing VST we developed, you can see that performance is solid. But just like the NS7 and the VCI-300, the SCS.1 controllers have trouble in apps like Traktor, partially because software hasn't caught up to the leap hardware has made in the last year.

The great thing right now about the NS7 is that it has a program it was made specifically to work with (Itch). Any other application support is icing on the cake. We don't have that right now.

There is a LOT of development going on right now on SCS.1. We're looking at a bunch of things we can do to make the SCS.1d a more solid performer. And I would argue that the SCS.1m is easily one of the most useful controllers out there. And I fully believe that the SCS.1d will grow into it's role as a platter controller and become something cool in the near future. We just have some work to do first.

[Fatlimey]

Mudo, keep asking questions! I have no problem with that, it really is the only way to learn. So long as you decide to listen to the responses you'll be fine, which you seem to be doing!

Having programmed USB/MIDI at the low level in the Midifighter, I can't really see how much faster any other system could be. For each MIDI event we essentially wrap it into a 4-byte "packet" and add it to the USB "endpoint". An endpoint in USB is a 16, 32 or 64 byte piece of memory especially set aside for the USB device to hold messages for the Host. Once the 4-byte MIDI event is in the endpoint we can either flush the endpoint (by waiting for the Host to poll it for "bytes to consume") or we can continue adding MIDI events until the endpoint is full. Every keydown, CC change or input MIDI event are just these 4-byte packets stuffed into an endpoint. No device on a USB bus can do anything other than wait for the Host to pass by and pick up the data it has in the endpoints. Hosts do everything, devices do nothing but wait (but they can influence how often a Host decides to drop by for more information...)

HID works in exactly the same way except it has a different packet layout and a different subsystem listening at the Host end of the USB cable. Pretty much the only difference between USB/MIDI and HID is how the Host reads and interprets the endpoint packets. There's nothing that designing a device can do to influence how your operating system has decided to support MIDI. With custom HID drivers, you can route the information more directly to your application. Another difference is that MIDI prefers values to be unsigned integers in the range 0..127, or longer values broken into 7-bit sections whereas HID is able to represent variable length information more easily and has representations for different numeric data types. As for the speed and latency? They're exactly the same.

So, open and limited to some extent (but just as fast) or closed, tied to one particular application and requires drivers that are subject to "bit rot" over time.

I'd go for MIDI every time.

[pilmat]

Very interesting conversation. I'm learning a lot!

Also looking forward to the software opening to the advances in hardware. It feels like we are only really starting to scratch the surface of what controllers will eventually be able to do.

Thanks, Phil.

[licks]

me too. Thanks again.

[Mudo]

...

Ok guys... then I believed that NS7/V7 (or better said ITCH) work with relative interrupting trought HID but if it is encryted sysex (like APC40) or plain and can do the work... COOL!

About SCS.1d I have some love/hate relationship I can try it and I'm not sure if the issues were on soft or hard side but if Nemonic said that work in is progress... well count for my support. I prefer open platforms ever. If you can share more details or what kind of help do you need I will try to bring some net research or ask my teachers (I get wrong but because I'm the madman student ).

About midi fighter and protocols, the 7bits or 14bits has a "bit" detail, almost in arduino or FDTI platforms (which emulate the serial port) because these packets are truncated (the biggers) and make it a bit "laggy", test will be interesting in different scenarios (crabbs, platter scratch and so on...). Also resolution is important and 7bits maybe is not enoght for fast scratching... we could try to (anybody remembers what kind of message sends rastieri scratcher?).

In the other hand (Nemonic) at Traktor support for scs.1d you have another handicap: When stanton released "the system" NI dropped the sysex 14 bits timecode support at same version... it makes me think in market wars (maybe I'm wrong again) and this is bad for final user.

Let's continue talking because I'm interested so much on contiune learning.

Thanks to all!



...

[nem0nic]

...but if it is encryted sysex (like APC40) or plain and can do the work... COOL!

It's not encrypted. It's out in the open plain MIDI. And it's not all SYSEX. There are SYSEX messages for things like device ID, motor start, etc, but the bulk of the messaging is garden variety MIDI. And while I haven't sniffed traffic between the APC40 and Live, I know that by default it sends unencrypted MIDI as well. There is a challenge/response between the ACP40 and Live in order to enable the APC40 specific functionality, but it's not necessarily encrypted (although it might look like it). It's much simpler than that.

[nem0nic]

On SCS.1, our main focus right now is internal testing of the Windows 7 driver. But we also have several new presets in the pipe and a new DaRouter as well.

[Mudo]

...

Cool.

Maxforlive patch planned?


...

[Reticuli]

Pretty sure the Xponent is a 10-bit fader. Just because they update it to send 14-bit messages doesn't mean the fader itself is 14-bit. 10-bit is certainly a step up from 8-bit, though, which is useless. Think of 10-bit faders as equivalent to 45 or 60mm analog faders and 14-bit faders as equivalent to a 100mm analog fader. A 10-bit 100mm fader will not respond to the smallest movements, though, as you see on the Xponent and Versadeck that too teeny a movement won't do anything... even in Deckadance with its three decimals visible. On a true 14-bit 100mm pitch fader, even the smallest motion will register and you never need worry about it not making a difference. If it’s a 10bit fader, the length should not be 100mm.