In praise of MIDI
theregister.com
theregister.com
MIDI's issues in a notation context are twofold: non-standardization of controls for e.g. choosing articulations for string instruments, and an inability to communicate future information if known to the MIDI producer - say, for instance, knowledge that this Note On event is the beginning of a phrase that will last for 2 measures, as known to notation software.
There's a real way in which MIDI solved for communicating trigger events over the wire, but was not extensible enough to allow for further backwards-compatible standardization that would let it communicate music over the wire. By contrast, the web evolved from communicating hypertext to sending entire application environments and executable code over the same protocols. The web was born later, to be sure, but in an age where an Arduino can execute JavaScript, I wish we were looking to much more extensible modes of communication as inspiration for what can be done with interoperable musical devices.
On the other hand, you can hook up a 40 year old MIDI keyboard to a brand new iPhone via MIDI and it just works.
But I get your point.
To me, the downvotes suggest the way the community is changing.
I suspect I could have been just as pedantic without acknowledging it - and perhaps even aggressively argumentative - and been more appreciated by my readers. Probably leaving off the equanimious point-getting sentence would have improved reception.
Anyway, MIDI was a ChatGPT of my youth and because I was gear aware when the DX7 showed up in music stores, now that I have empty nest adult money I have considered buying one and hence done some research. A fantasy largely abandoned after having bought and sold a handful of cheaper and lighter late 80's Yamaha MIDI instruments.
For what it's worth, there is a somewhat rare third party upgrade board for the DX7's MIDI ports, and if the maximum you want to do is send and receive Note On/Off on a single channel a stock DX7 will be good enough. It just doesn't do most of what people expect MIDI to do even though what it does is pretty amazing for the price when it was released.
Thanks for giving me an excuse to write.
And what was going through my head as the downvotes happened.
And as I read your comment.
Then started writing.
What happens when I have the time and mood to write.
Self awareness is another thing HN gives me.
The biggest problem in MIDI is IMO the fact there was no possible option for any standard negotiation between devices.
You had MIDI IN and OUT, and at any time one or both could be connected to instrument/controller, you didn't knew where you were outputting it, and you didn't knew who send you control messages.
That utter simplicity had benefits from interfacing perspective but it also made it impossible to expand the standard easily.
There was no option for "MIDI 1.1" that would say improve some stuff but still had option to send MIDI "1.0" compatible signal if it detected that other side doesn't talk it.
There was also no option for simple "tell me what CC 85 does on you" so every mapping between devices had to be done by hand or by loading someone's profile.
It kinda had to be what it is, it was introduced in 1983 where extra transistors were pretty fucking expensive so simplicity of the protocol was huge benefit, I'm pretty sure simple MIDI keyboard could be implemented even with a bunch of logic chips without much problem.
While I agree for ease of designed use, I also think that’s one of the fantastic features of MIDI, because it makes it possible to use participating devices in novel ways, never anticipated by their manufacturers.
For example, I sometimes use note pressure messages (a.k.a. polyphonic aftertouch) as a second set of 127 control change messages, rather than their documented design intent.
It does look pretty overcomplicated, but then the variety of use cases might be excusing it.
Also the fact it has some kind of negotiation doesn't preclude doing clever things with it, just the fact you don't need to rename knobs differently for every single device you connect
Yes indeed, but one of my favourite pastimes over the last while has been to buy inexpensive used (and no longer manufactured) midi controllers and use them together with ultra-modern software (DAW, virtual instruments and fx).
My kind of hacks (and numerous others) will hopefully continue to extend the useful life of older MIDI capable hardware and lessen the burden of landfills a tiny bit.
I’ve been very relieved and excited to read, that MIDI 2.0 is supposed to be very backwards compatible, so hopefully I can use my old hardware with ultra modern software for a long time.
> Also the fact it has some kind of negotiation doesn't preclude doing clever things with it.
In theory yes, but unfortunately I’ve seen too many cases of this type of simplification for straightforward use cases also preclude the facilitation of other use cases.
If we make developers think and work too much about use cases, rather than just the power of the naked protocol, they often neglect the latter in favour of the former.
I should probably dig that MIDI dashboard project out of pile of abandonded projects someday, once upon a time I bought cheapo midi matrix controller (Midiplus smartpad) then kinda... not really using it for much so I mapped which MIDI command lights what light and wanted to make a dashboard of various stuff out of it...
I do like how trivial 1.0 is; implementing it on a microcontroller has been a breeze.
>> Also the fact it has some kind of negotiation doesn't preclude doing clever things with it.
>In theory yes, but unfortunately I’ve seen too many cases of this type of simplification for straightforward use cases also preclude the facilitation of other use cases.
> If we make developers think and work too much about use cases, rather than just the power of the naked protocol, they often neglect the latter in favour of the former.
That does worry me a bit with 2.0, it is absolutely "and the kitchen sink" of protocols and considering how even 1.0 implementations can be janky we might see a bunch of pretty badly designed 2.0 implementations
MIDI isn't technically tied to a medium, but the only notion of addressing are MIDI channels (at least the classic v1 from the 80s) - you can target messages to any channel 1-16. It's up to you to set your devices to listen on the right channels. For example: If you have a keyboard set to transmit on channel 5, and two modules listening on channel 5, they'll both play when you press a key on your keyboard.
Classic MIDI with the DIN plugs was a RS-232 wire protocol - devices typically had an IN, OUT and often a THRU port to forward all received MIDIs (some forwarded everything out of the OUT port). Latency was a problem with the older devices, but there were "MIDI hubs" that fixed that, and when computers started getting MIDI hardware (Atari ST had it built-in, and ISA MIDI cards for the PC were a thing), it got better.
So as long as devices are connected via some serial-like communication method and can forward to each other, MIDI will work over it if all the devices involved can use it. I'm not too familiar with everything Bluetooth but I know that Bluetooth virtual serial/COM ports are a thing. MIDI speeds are low (33Kbit/sec). Classic MIDI will work just fine over that, without any additional engineering, as long as all nodes agree to send and receive MIDI over it.
The DIN 41524 / IEC/DIN EN 60130-9 connector is a common way of connecting MIDI devices. It is often referred to as “DIN MIDI” and “5 pin MIDI.”
Perhaps because serial is not a standard.
Even Hayes AT commands (the closest thing to a standard at the scale of MIDI) required knowing baud rate, data bits, stop bits, and parity bits to establish a serial connection.
For me, Bluetooth works much better than MIDI because there’s no setting channels or sending all-notes-off because something hung up.
I didn’t see the comparison because it didn’t make sense to me. YMMV.
The comparison was between the compexity level. Also between MIDI and MIDI 2.0: whether 2.0 would be similar to its current serial MIDI 1.0 implementation, USB, or BT complexity wise.
>For me, Bluetooth works much better than MIDI because there’s no setting channels or sending all-notes-off because something hung up.
That must be a joke, right? Because BT is 10 times worse in this regard, getting the user to manually forcefully do a connect/reconnect cycle, not connecting and not knowing why, dropping the connection, and so on.
MIDI once it's connected, it pretty much just works: which is why they do live shows with midi for 3+ decades, whereas they wouldn't touch BT for live show with a 100000000 long pole, even if latency wasn't an issue...
I think they're basically saying "if it is as much mess as BT protocols it will be a nightmare"
MIDI 1.0's failings are much simpler - limited resolution, limited channels, and limited support for polyphonic expression.
MIDI 2.0 has addressed all of those, but it's a bureaucratic monster of a protocol and I suspect it's not going to be popular.
We could really have done with a MIDI 1.5 which kept the same message types but made them 16-bit instead of 8-bit, and also added some extra poly-start and poly-controller features. That would have been enough to open a whole new world of expression without adding a lot of extra complexity.
I generally agree with most of your points, although I'd prefer to call it "limitations".
But even with those limitations, MIDI 1.0 has been used in numerous practical applications that have transcended the original use case concepts. From GM to MCU to MPE and many other things people have done at smaller scale or even just in their own custom setups.
Sure, those are "hacks", but especially on this site, I'd consider that worthy of praise, rather than ridicule.
To this day, thanks to MIDI 1.0, I can and do cobble very different pieces of hardware and software together to effectively create a highly individualized and therefore creativity boosting music making environment.
> MIDI 2.0 has addressed all of those, but it's a bureaucratic monster of a protocol and I suspect it's not going to be popular. -- We could really have done with a MIDI 1.5 ...
Yeah - MIDI 2.0 gives me a a vibe somewhat analogous to IPv6. But it's early days, so I'll wait how it plays out ...
But the space of "what can you do with an 'instrument' to make music" is immense, and not feasibly susceptible to enumeration in a protocol like this. Music is art, and almost without exception every great musician ends up doing something that can't be represented by the algorithmic conventions of her ancestors.
MuseScore has the disadvantage of trying to live in this weird world of "typeset music", which has (for centuries) tried really hard to pretend that this disconnect doesn't exist. But it does, and it's not MIDI's fault any more than it is the fault of whoever invented the drum roll or pizzicato strings or anything else that didn't have a pre-existing notation.
Quite frankly MIDI isn't even MuseScore's biggest problem. Just look over the shoulder at any teenager playing with Garage Band with a big cacophany of effects and then ask "how do you put that in MuseScore". You can't, and you never will, and... that's probably a good thing.
And the space of "what you can do expression-wise with very commonly used VST and sample libraries and notation packages" is hardly vast, and could very well be covered with MIDI if it has some more very basic capabilities.
It doesn't need to cover all the space (like how to express a musical saw performance), and nobody asks for this.
They ask for very common problems, everyone in the notation, sountrack, etc. field has, and that sequencers already solve - but in ad-hoc and non-standard ways, or ways that require too much manual intervention.
Common people, it's not like a 40 years old, pre computer music format, is the holy grail, and anybody criticizing it for lack of certain features needed today (today? Huh, expressive mode switch in sample VSTs has been a thing for 2+ decades) is akin to implying "USB lacks support for ametric poetry."
Just that MIDI was really invented for electronic instruments and, well, most of them were notes generated by pressing keys and maybe a modulation bar or joystick. Hell, arguably you still could transfer a lot of those modulations via CC commands but you'd have to standarise on which exact CC change corresponds to what instrument's technique.
That being said MIDI 1.0 clearly has a bunch of pain points (low resolution, no bidi communication making auto-config hard etc.) that are getting fixed in 2.0 but that just slowly started, so 1.0 is there to stay for a long time still.
To be clear: that was the point. Typeset music notation has struggled to keep up with the physical expression of music[1] for hundreds and hundreds of years. There's nothing new about this problem, and it has nothing to do with MIDI.
[1] And MIDI is just another such expression in this context. MIDI is absolutely not an attempt to reproduce typeset music, it's designed to capture electronic instrument behavior.
MIDI is not a notation protocol. It's a stream of real time events (plus sysex metadata). Let's evaluate it that context.
Which is irrelevant as an observation.
The context here is not whether MIDI is a notation protocol or good for notating purposes, but about using MIDI to play the music in a notation app.
And the problem is that MIDI can't transmit and take advantage of the extra information a notation program has access to about the piece.
That's a problem with MIDI 1.0 EVEN outside a notation context. The limitations under notation program use of MIDI to play orchestral music, are also limitations of MIDI itself for things that would be very handy to have under many more contexts.
Standard MIDI sequencers for example, can't send messages about "playing mode" with semantic purpose, and resort to hacks (sending a simultaneous out-of-range MIDI note with your actual MIDI notes to signal a specific expression like pizzicato to a VST sample player), each done in its own ad-hoc ways (including CC, custom notes, abusing channels, and so on), and requiring ad-hoc mapping for every new VST, even for common shared attributes.
The video notes that MIDI just wasn't designed for this purpose. It was designed as a standard messaging protocol facilitating communication between the different RTOS's used in synthesisers. The fact that it became a standard format for digital musical notation was probably just an afterthought, albeit a pretty good one. I couldn't watch the whole video, however there are always MIDI control codes which can be used for the kind of meta-information they're talking about, like specifying Staccato, or Tremolo.
I’ve seen high end libraries with multiple staccatos, for instance.
And if you're not using CCs/Sysex in an ad-hoc way, e.g. if you can get VST vendors to agree on some semantics for those, then you've just built a new protocol layer on top of MIDI, only you did it as a kludge, with whatever was available as a "safety net for unknown stuff" from 40 years ago, and not a proper design...
I'm surprised MuseScore is attempting to piggyback on MIDI to store sheet music. That seems like trying to typeset a book using Teletext.
They are trying to use MIDI to play the sheet music, with their built-in sample player, and with third party orchestral VSTs, but with less information loss about expressiveness...
I wish midi was used for more things. Like I wish it was easy to map a dj controller to Final Cut Pro using midi. Or to studio one for photo editing. I don’t know how to do that right now.
There are utility programs, that allow you to trigger and/or script keyboard and/or mouse actions et. via MIDI.
So it becomes entirely possible to use a hardware MIDI controller to control a variety of software allowing lots of key commands.
I currently have a a few such pieces of software on my Win10 system:
CoyoteMIDI, Extended Expression, Bome MIDI Translator
p.s. However, I'm not up-to-date on the state of such software on MacOS or Linux.
Granted it doesn't do chord detection.
It might actually have some "real" use cases: you could run an Amiga/C64/etc emulator, and a tracker within that, and then use this (with a proper keymap) to give it MIDI input. I didn't yet provide the ability to customize the keymaps, other than direct to source, though.. Pull requests welcome.
Ever since MIDI, every audio tech company has been convinced that its technology was going to be the next MIDI, and that the licensing fees from it would the ticket to an island of their own. E.g. check the state of audio-over-IP. You can almost hear people saying "I mean, imagine how much [ EDIT: Roland ] & Sequential could have made if they had licensed this!"
How so? Synthesizers are mostly controlled by piano-like keyboards.
At least, all the actually successful ones.
Pianos are a very specific type of instrument in that they have fixed pitches (compared with any non-fretted string instrument, the tuba or the human voice). MIDI has many assumptions built into it that are derived from the way pianos work, which means that using it in contexts where you want the sort of control not possible on a piano is ... challenging. One obvious example is playing something in a way closer to what you can do on a guitar: MIDI has no real way of representing the sorts of control a guitar player has access to. That said, people have tried, and the best systems are quite good, although they tend to subvert MIDI semantics and just use the syntax of the protocol.
Why limit yourself to trying to make it work like a guitar or a saxophone? The Yamaha EWI is a lot of fun to play, but I don't really see what it adds. You can add a bit of expression to relatively crappy samples, or to some unconvincing physical modelling synthesis of a woodwind instrument, but it's never going to fool anyone. You can use it to drive other parameters on a more "conventional" (by which I mean, creating artificial sounds rather than attempting to emulate acoustic instruments) synthesizer, I guess, but how much does that really help?
Per-note modulation is only slowly getting there and severely sub-optimal (MPE is using a channel per note, cutting down number of devices you can drive from single MIDI port significantly).
Now I would say "hobbled" is overstatement, but it definitely have annoying parts that we have to deal with for decades now.
On top of that there are the usability issues, uni-directionality and simple protocol made it easy to make peripherals in the 80's but nowadays it's liability, because simple thing like "ask the device what CC it accepts and what they are named" is impossible in standard
It's not a hack, it's part of the original MIDI specification.
If you do, you need to design an instrument with an incredibly precise and stable filter, and analogue synthesizers don't have that.
Shove it into a synth that have a bunch of oscillators, filters, LFOs and effects [1] and you'd probably be forced to downgrade few of those parameters back to 7 bit
There's actually a very clever reason for this, and if you study the circuit diagram and the voice card firmware you'll see just how clever it is.
Recently expressive instrument makers have settled on MPE as a workaround. That works, but it's kind of kludgy and isn't widely supported. You can also use an MPE-like approach on synths that don't explicitly support it as long as they're multitimbral.
Unfortunately there's a lot of amazing synths out there that aren't multitimbral.
Recent controllers that use MPE include the Linnstrument, the Roli Seaboard, the Haken Continuum, the Expressive E Osmose, and the NuRad wind controller.
Or synth woodwinds that encoded not just fixed pitches (from the keys), but continuously changing airflow and breathiness.
You can come up with examples for pretty much every instrument, really. Imagine what you could accomplish with a synth guitar that allowed you to bend pitches.
If MIDI had supported features like that, we may very well have seen an explosion in creativity of different types of synthesizers, beyond just digital pianos and drum kits.
Fortunately we might actually see that now, with MIDI 2.0 [1]. A quote:
> This should mean music played on MIDI 2.0 instruments will feel more analog, and make it possible for non-keyboard instruments to work better with MIDI. Historically, guitar, violin, and trumpet players have had to learn play keys in order to better translate their work through MIDI. Now, hopefully, they will be able to play their instrument of choice as an input into MIDI-compatible recording software.
Never mind bowing, look at plucked string instruments - there aren't any really successful guitar synths that are actually playable to any real degree. The old Roland analogues in the 80s did the best job using a hexaphonic pickup and six PLLs to track the string frequency but they still didn't track well on lower notes, which is why Pat Metheny plays so far up the neck.
Of course it is not a free lunch.
The current "1.0 Specification", circa 1995, is document version 4.2.
Now by default these home computers often had two joystick ports and to be able to play I-don't-remember-which-game we hacked some additional dual-port thinggy on a little PCB we'd hook into the ST's parallel port. This allowed us to play four players at the same time, each with our own joystick, on a single ST / monitor.
The 1.0 encoding is incredibly simple and to have gone 40 years (and still going), with many many devices being compatible with the protocol, is something that should absolutely be celebrated.
Here's to 2.0 being just as long lived and successful, presuming its just as simple but expands on the field sizes, timing improvements, and flexibility in terms of non-western music as it seems to promise.
"There’s no MIDI 1.1"
That was both its strength and its weakness. It took 40 years of MIDI consortium bureaucracy to evolve and agree upon the MIDI 2.0 spec.
Oh yes! And I still copy them over every time I migrate to a new music making computer. And play them back every few years for a good smile.
I even spent quite a bit of money on commercially produced floppy disks of midi files containing arrangements of popular songs of the day. It enabled an early form of remixing those songs.
This was quite a thing during its heyday and was quite interlinked with the MT-32 sound module by Roland, which also ended up spawning an entire subculture of classical music lovers transcribing countless classical (and thus public domain) pieces into MIDI and posting them on BBS systems.
Some of the modern classical midi archives on the web are descendants of those BBS sharing communities and I'm assuming that numerous midi files on current websites are actually from those days (late 80s to early 90s).
The eventual standard MIDI GM (for standardizing program change messages into specific instruments) and subsequent dialects like Roland's MIDI GS and Yamaha's MIDI XG standardizing control change messages for FX like reverb etc. all stem from those days.
The MT32 and later Sound Canvas series modules and Yamaha's competing models like the FB-01 eventually ended up becoming incorporated into many PC sound cards.
So many memories ...
One of my guilty pleasures is to get a well done MIDI file from that era and render it using my Kronos and Logic loaded with NI, Arturia stuff. It’s impressive how you can produce something that was basically inconceivable to the original MIDI author that was using perhaps a Gravis Ultrasound.
But sharing midi files was not more legal than mp3s.
It's mindboggling to think that you could have been playing that game in 1988 with such a soundtrack (skip at 6:40 if you're impatient):
I certainly didn't have that great of a soundtrack when playing Ultima V back then on my my C64 (AFAIK there was no MIDI support in C64 games and no MIDI add-on for the C64? Although I may be wrong on that)
Here's a neat example, though the video on the page uses the MT-32 for music: https://www.jamesfmackenzie.com/2019/06/19/atari-st-games-wi...
https://archive.org/details/audio_live-from-the-sierra-loung...
Try hooking up a computer peripheral from that era, say a Centronics printer or an MFM drive to a mobile phone and let me know how it goes.
They were used as ring tones on phones.
Seemingly overnight, that all vanished. I shared a .mid file with someone a few years ago (someone at Google!) and they were not able to play it.
And you think, wouldn't it be cool if the .MID contained the SoundFont? And... you get .MOD files, which were unfortunately seen as this weird demo scene format but were quietly doing things the music industry had not gotten around to yet. It was MID that would sound identical on any machine you played it on (assuming said machine had PCM playback)
That means putting them in ROM and that means compliant hardware or CDROM latency.
It's also a bit eerie, to see long dead pianists play from rolls converted to MIDI files for instance, it really has a 'ghost in the machine' kind of feeling.
Complaining shouldn't be allowed by anyone who hasn't studied it. You can't know what it can't do until you know what it can do. Many critics just don't know. And can't be bothered about that computer junk. Meanwhile, many top producers in Hollywood produced top-grade filmscores with it.
32Kbits per second is about 3000 bytes or 1000 of MIDI's biggest commands per second. Even 100 notes per second leaves a lot of room for CCs, NRPs and other controllers. Oh, and a rest is the distance between a note-off and a note-on ... if you actually have to convert to notation.
That's true, if you consider the task at hand to be allowing any piano-like keyboard controller to connect to any synthesizer and just work.
It starts to break down if you consider it as a protocol for general-purpose musical expression. No explicit support for any tuning other than 12-tone equal temperament. No support for unisons on a single channel. Some support for per-note expression, but there's not really a sane way to support volume swells that works in a predictable way across devices.
I think it should be possible to improve upon MIDI and make something that's a lot more flexible without adding too much complexity.
MPE is a pretty good temporary workaround, but it's not the kind of thing you'd do if you were designing for expressive instruments from the start.
I think MIDI is very well suited to build on top of, without needing to change the spec. Most if not all of what you discuss can be built in software (and hardware! but it might need to be purpose built for some tasks, which is admittedly a weakness of the aging spec) with MIDI’s existing features.
Importantly, I think that can be done without introducing ambiguities that would require end users to pierce the abstraction layer. (I say this as someone who works on projects rooted in a relatively younger but also old-by-today’s-standards spec, with very good abstractions built atop, but breaks down for certain use cases in ways that came up just today in my weekly check in.) Granted being such a small, low level target means it’s easy to get those abstractions wrong. But as someone might say of a house, it’s got good bones. A motivated person with the right tools and skills can do incredible things.
I’m not sure that’s a compelling argument that MIDI objectively should remain unchanged for the better part of a century. But it’s compelling enough I’d scrutinize any proposal to revise for its thorough in-spec alternatives.
> OSC's main features, compared to MIDI, include:
> Open-ended, dynamic, URI-style symbolic naming scheme
> Symbolic and high-resolution numeric data
> Pattern matching language to specify multiple recipients of a single message
> High resolution time tags
> "Bundles" of messages whose effects must occur simultaneously
Also OSC is typically transported on UDP messages (because it is easy to do), but that's a terrible transport since it is unreliable, and messages larger that some OS and network dependent size are just discarded, so you can only use it reliably for message bundles smaller than a few hundred bytes.
I disagree. I think MIDI uses a basic abstraction that's awkward for anything that's not piano-like, and attempting to fix it by laying things on top just muddles things. MPE works around MIDI's limitations, but it's not a very clean interface. Users have to be aware of whether they're using MPE or not. If they are, channels don't work the same way as when they aren't.
(And interestingly MIDI gets things wrong in about the same way that standard music notation fails.)
I think MIDI's main mistake is that it assumes that a key, a note, a pitch, and a voice are all unique and be used to uniquely identify each other. So, for instance a keyboard can send NOTE-ON 72 127 when someone hits the C4 key at full velocity, and then when they release it the keyboard can send NOTE-OFF 72. There's this assumption that there's only one C4 being played at once, so the keyboard can just say, "stop playing the C4 note" to get it to stop. This breaks down if you send two NOTE-ONs for the same note in a row (which I think is technically allowed), but sending a NOTE-OFF when there are multiple notes playing is undefined behavior.
The way most synths actually work internally is that you have one or more voice engines that can be tuned to any arbitrary note.
I think a more sensible approach is to just have the controller allocate voices explicitly, and then tune them however it wants. Voices can be referenced by a unique ID that's independent of pitch.
For instance, the controller might send messages like, "hey, I want to allocate a new voice which I will call V1; please set aside one voice engine and tune it to 261.63 hertz". The controller might do this before the user even hits a key. Then when the user hits a key it might send a command "please apply a percussive envelope to voice V1 using such and such parameters." When the user releases the key it might send a command "please apply an aggressive damping filter to voice V1". And so on.
The controller might want to allocate more voices than the synthesizer actually has, but that's fine -- modern synths generally implement some notion of voice stealing anyways.
Like, the MIDI format is pretty elegant and easy to decide but why inherit limitations of 14 bit numbers and continue using "sysex" as kludge to drive everything ?
Keep the format of <command><channel> (really, <channel><command> is probably better for decoding but whatever) but then instead of the silliness of 7/14 bit encode rest of the parameters properly
edit: from midi wesite -->
Can MIDI 2.0 provide more resolution?
Yes, MIDI 1.0 messages are usually 7 bit (14 bit is possible by not widely implemented because there are only 128 CC messages). In MIDI 2.0 velocity is 16 bit. The 128 Control Change messages, 16,384 Registered Controllers, 16,384 Assignable Controllers, Poly and Channel Pressure, and Pitch Bend are all 32 bit resolution.