I’m looking at designing my own midi controller and I’m interested in finding out more about 14 bit midi. Hi-resolution faders and pots for everything just sounds super sweet to me. I can see that the Vestax VCI-300 and the Xponent both use this technology - and importantly that traktor can use it - but I can’t seem to find much info in terms of midi DIY kits. Can anyone help me?
Ok with a little more indepth searching I think this -
May actually do what I’m looking for. Seems like this particular chip can be setup to do a whole lot of things though.
I am feeling a little out of my depth but it is relatively cheap and it doesn’t require any usb->serial devices or anything like that get started hacking. hmmmm
I’m still waiting for someone to build a more precise hardware setup in a VCI-100(SE) casing. That would make such an awesome mod.
I have some low-level programming skills, but lack the soldering skills, time and money to build such a thing myself.
Well this chip seems to run entirely on BASIC. Which suits me as proper low-level assembler type languages are something ran running and screaming from 10+ years ago when I studied it at uni.
Might it be possible/easier to convert from HID or OSC to midi at the computer level?
The first version CUI has some features in this way… it will be interesting if somebody port to the new CUI32x…
About Hid2midi/osc… well if your thinking or use it with Traktor, ITCH or maxforlive you don’t need to convert: Hid is the best way but you must need to code/script.
If you need 14 bits (sysex midi) then you must code… and with software I advice you pure data (for bridgering from Hid2midi).
For something simple as volume faders or eq knobs, you dont need hi-res midi, 7-bit works just fine. The only thing that needs 14bit is the pitch fader imo.
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.
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
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!
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.
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.
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…
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.
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.