DIY 14 Bit Midi

[Mudo]

...

7bits is not enough resolution for all and midi is not enough "fast" neither as serial dependant protocol but it is still usefull of course.

Check the web with the battle MIDI vs HID vs OSC...




...

[pilmat]

What do you want to do with a 14bit controller? Remember that Traktor can only get any 14bit benefits on the pitch fader (search the 14bit VCI-300 jog issues in Traktor). Until the software can handle it, the hardware is not much use. DJTT looked into 14bit for the VCI-100 (it would have been firmware 1.4), but we have heard little about this in a year, I am guessing, due to the software limitations.

Phil.

[Mudo]

...

+1

...

[midifidler]

MUDO
USB midi is not limited by the old RS-232 data transfer speeds, only old devices which use legacy midi din plugs are limited by this - you are confusing the hardware and software protocols.

Unfortunatley for now 14 bit resolution is not much help in Traktor as only pitch supports it - hopefully they upgrade the EQ line and cross faders asap.

I think for most FX especially when in chained mode 7 bit is enough

As a side note any device out there which currently supports 14 bit midi on its knobs/faders will actually only really have 10 bit resolution. That is the typical adc resolution of the device used in midi controllers, yes you can buy higher resolution ADCs but they cost a lot more, and the percevable difference between 10 bit and 14 bit on a knob is going to be nill.

The VCI itself could be upgraded via firmware to support 14 bit midi (once again it would only really be 10 bit ) there is no software or hardware limitation. I would say vestax have an ulterior motive for not delivering this request

[Fatlimey]

We really should do something about reverse engineering that VCI firmware. We have a disassembler, we have an assembler, we have a programmer. Should just be a matter of tracing what connects to which pins, seeing if there's a recognizable ABI, breaking the code into chunks based on calls/returns, finding the USB code to ignore, finding the I/O port reads and writes, and then mapping out the remains of this large amount of assembly to find the inner loops that read switches and writes USB/MIDI packets.

Not enough hours in the day to do all the fun stuff I want to do!

[Mudo]

...

@Midifidler:

In addition to "physical" connections you must take in consideration "protocol" itself. Midi is serial one... the way how message are send and so on.

Obviously trought usb it becomes faster in data transmission but the protocol still is serialized in comparision with OSC (i.e) which has multicast options.

For regular uses Midi is far enough but for "scratch" scenario (i.e again) numark uses HID because it is far speed and best resolution and DVS use timecode/timestamp because Midi couldn't afford the specs (compare scs.1d with V7).

It is a issue with protocol itself not developed for "all". At last it is a debate done around the net and my conclusions are clear:

HID best for scratch.
OSC best for interfacing and multicasting.
MIDI (sysex included) for the rest.

And take in consideration the platform because if you want to use an arduino (i.e) the FDTI chip "emulates" a serial connection and again you have a "funnel" in data transmission, not in other platforms like CUI or 18f450 pics based, arms... etc.



...

[licks]

Hey thanks for all the info. I didn't realise until this thread that the high resolution midi was strictly for pitch control. I was tossing up whether to include pitch control at all in my design. Would be great if EQs and volumes had higher resolution as well. 1-127 really isn't a lot of detail.

[nem0nic]

In addition to "physical" connections you must take in consideration "protocol" itself. Midi is serial one... the way how message are send and so on.

Wrong. The fact is that MIDI is able to take full advantage of whatever transport medium it's using. It's more than fast enough to convey scratching with precision. For example, the SCS.1d has 4000 counts of resolution per rotation. This translates to 4.7 messages per millimeter of platter movement - more than enough to convey minute movements accurately. And the firewire bus can handle all of this traffic without throttling (applications are a different story). We've looked at the NS7 and it has a very similar platter resolution, and achieves it's rock solid performance over USB. But you say the NS7 is HID...

For regular uses Midi is far enough but for "scratch" scenario (i.e again) numark uses HID because it is far speed and best resolution and DVS use timecode/timestamp because Midi couldn't afford the specs (compare scs.1d with V7).

This is WRONG. PLEASE don't talk about what specific products output unless you've actually tested them yourself. The NS7 sends PURE MIDI - NOT HID. All you need to do to verify this is to fire up MIDIOX or SendSX to see the output. This has been tested thoroughly, and you can search online and find other companies that will verify it (VirtualDJ developed NS7 support right after it was released, and there's a lot of info on their boards as well).

Mudo, ALL of your arguments here are red herrings that are obviously not researched. Normally I wouldn't bother replying to stuff like this, but I felt the need to in this case, because your assumptions hurt the future of controllerisim. HID is a black box environment, and users have little control over devices that use it. In some cases, that's acceptable (especially from a developer standpoint). MIDI is open, the protocol is well supported, and it's not as limited as your posts would have people think. It's not limited to a specific speed or transport medium, it's fast (faster than protocols like OSC because there's smaller packets and less overhead), and it's not maxed out at a 14bit word length.

I'm not trying to argue that MIDI is superior to HID or OSC. Honestly, I know of situations where I can see all 3 being appropriate to use. What I am saying is that you're maligning a protocol you obviously haven't researched at any length.

[MiL0]

so how does the motor control work on the NS7?

[nem0nic]

The platter and "spindle" send separate messages - the platter sending a timestamp and the spindle sending a traditional relative message. There's also a message required to turn the motor on.