What are some cool uses of MIDI you have seen outside music-making?
https://www.youtube.com/watch?v=b7nMZvueKNQ
> Compressorhead are built out of metal scrap, most of the movings are made with electro pneumatics. It is controlled via Midi. There is an interface that changes the Midi signals in switch signals for the electro pneumatic valves…,” Kolbie’s voice drifts off. He has soon got his face in a Robotics for Dummies manual. [1]
[0] https://en.wikipedia.org/wiki/Compressorhead
[1] https://web.archive.org/web/20181016144145/http://www.gibson...
https://www.youtube.com/watch?v=evHVh4bqaOQ
All controlled by MIDI, unsurprisingly.
I used to do a lot of experiential retailing experiences and OSC was our preferred control scheme.
It almost doesn't even matter because outside of musical gear, OSC is becoming the established standard to control everything from DMX lighting to VJ software to OF/Cinder interactive installs to some more performance oriented software like Ableton Live (via LiveOSC).
I've written software MIDI sequencers (all the way back in the early 90's even) and you'll never be able to convince me MIDI is better than OSC.
(disclaimer: I develop an OSC-based sequencer, https://ossia.io)
A good example of non-music MIDI is Firmata; it’s a protocol based on MIDI and allows remote control of Arduino and other MCUs [1]. Seems both modbus and midi have transports over Ethernet now as well.
1: https://github.com/PatternAgents/Electronics_One_Workshop/wi...
One of my favorite parts of both APIs is that they don’t require focus on elements or the window/tab and are naturally multi-touch.
This allows you to rapidly speed through the interface and perform tasks.
Specifically, for exclusive messages in IMIDI, the first byte specifies the type of message and the channel (some exclusive messages might be channel independent, and this is also indicated), and the second byte is a namespace number. The four types of exclusive messages are: application message, namespace error, namespace request, namespace response. Note that the first byte has four bits for the channel, one bit for channel independence, and two bits for message type, filling up the seven available bits, and the namespace number is also seven bits. (If the channel independence bit is set, then a 11-bit namespace number is used, because the channel bits are used as additional bits for the namespace number in this case.)
Some namespace numbers may be predefined by the application in use. Other namespaces are negotiated by the use of the protocol mentioned above.
edit: spelling
For electronic drums I would of much prefered at least 24bit. Volume is by far and away a drum's most expressive dimension, so it will be limited by a 16bit velocity range. Adding velocity curves just masks the problem
Though of course 16bit is orders of magintude better than the current 8bit range
It wont be limited at all, real human players have no control as subtle as 256 levels, much less 65K levels... Nobody would even notice anything...
I know literally nothing about drumming but I've no doubt there are plenty of other characteristics of a drum strike than velocity. Such as the mass being applied to the hit (e.g. is it being hit with the weight of the stick alone or is it the drummer's whole arm) or the location of the strike, or the release time.
This doesn't analogise well to digital instruments, as the minimum and maximum velocity/amplitude/whatever is already known and defined. You already know what the exact potential dynamic range is before the first note is ever played. The concept of headroom doesn't exist. Anything that you can think of which you might define as "headroom" is either beyond the input and/or output capabilities of the device and therefore irrelevant, or it should be within the normal scale.
That would be a re-hash of the hobbyist USB VID/PID fiasco. MIDI synthesizers are one of the main non-activities which non-professional people have been doing. So many amateurs and educators whip up MIDI synthesizers in a few hours in a workshop or after work. And that is thanks to MIDI being a dirt-simple, unlicensed standard.
>You will also have access to the MMA Github which has code for MIDI 2.0 to MIDI 1.0 translation (and vis versa)
My introduction to MIDI was as a cheap-ass soldering-iron wielding 13 year old hooking together components for my Commodore VIC-20. I credit that work for my subsequent career as a scientist, programmer, and mathematician.
$250 a year. To solve a solved problem?
Everyone generates a UUID. Part of the CI setup is mapping the 128-bit UUID to a short identifier. Or some other compression scheme. Hell, even 64-bit random identifiers will almost-surely not collide on a bus.
So much for "hobbyist-friendly".
And totally unnecessary.
At the end of the day specs are only as good as adoption. If there is a reliable workaround (or even easier way to do things) than using the UUID then people will do that instead.
Also, it's pretty naive of these guys to assume their Github repo will stay hidden behind a $250 charge for very long.
What's the alternative? This is a bit like MAC addresses - if network gear manufacturers didn't have some type of system for de-conflicting addresses it would be chaos when you bought 2 pieces of gear that conflicted with each other.
MIDI 2.0 brings additional capabilities to device interconnection, and AFAIK has nothing to do with GM (which not many people care about anymore)
Professionals (musicians, engineers, etc) don't use MIDI as a general-purpose playback method, they use it to control their samplers, synths, external effects units etc.
They don't need "consistent samples" because they provide their own samples, different for every song (plus pure synth sounds, etc).
Basically, MIDI began as a protocol used between hardware devices. General MIDI is a product of the ROMpler era, a ROMpler being a sampler that can't be reprogrammed, i.e. what most people know as a "keyboard", and it's far from universal.
Musicians often don't care about standardising. They're hooking up all sorts of wonky instruments to their rig and reconfiguring it for one-off projects. There is often no need to recall specific patches after you've recorded the part you wanted.
edit: TCP -> HTTP.
MIDI has nothing to do with samples itself.
>and even in games these days, nobody uses it, sadly.
Most recorded music, soundtracks, and almost 100% of game music is been done with MIDI.
MIDI doesn't amount to the .mid files that people used to download / play on some player on their PC and which sound tinny.
It's a professional specification that's used in every single studio, and is the basis of every professional digital workstation for recording music and sequencing electronic instruments.
What you're describing is like confusing the JVM with Java applets, as if that's its only use.
If in your game you go the synthesis mode (chiptunes and whatnot) MIDI is a comunication protocol between devices.. if you want to use it to communicate a game with its own synthesis engine it makes less sense. Buy you may want MIDI so you compose in a standard music composing program.
It is used also in other areas that need automation, as lighting (DMX).
But I agree it would be nice to have better examples.
My 386 could do a decent job running DOS trackers (software synths) years before mp3’s were feasible on PC hardware (there was not enough storage, bandwidth or compute for MP3’s).
The Kosmic Free Music Foundation published a ton of music on one CD-ROM this way:
Even on WiFi it is useful although latency is very jittery.
Disclaimer: I'm working on a RTP MIDI implementation for linux (https://github.com/davidmoreno/rtpmidid)
Could you elaborate on why Wifi latency jitter would be an issue for MIDI?
From an outsider's perspective and with only a vague knowledge of MIDI, it doesn't seem to be something that should be any more sensitive to latency jitter than other realtime applications like audio/video.
If drum beat is sometimes, and only sometimes, 100ms later than it should, the result is not nice at all. And it is random jitter.
Think of it like playback vs a phone call. If you have 0.5s gap between audio and video, you hardly notice. But the same latency in a phone call makes it very awkward.
In music performance, the awkwardness would be multiplied by the number of spectators cringeing :)
If your video comes later than audio and depicts human mouth talking you would notice it ever for 1 frame (0.02s for 50 frames/s) delay; but it's true that if audio is delayed relative to video, then 0.5s is hardly noticeable.
https://archive.org/details/GDC2013Pavaheau
Even 5ms jitter is perceptible, and 10ms is obvious when compared directly with 0ms.
As a programmer I'm used to walled gardens and competing standards. MIDI is a breath of fresh air. I hope whatever 2.0 brings can keep this spirit alive.
Wonder what the next swing of the pendulum will look like?
At $250 a SysEx ID it seems MIDI 2.0 is exactly the opposite of that spirit.
> To implement MIDI-CI and MIDI 2.0, you need a manufacturers SysEx ID. A SysEx ID by itself is $250 a year, but it is included with your MMA membership.
A membership, not an open protocol.
OSC absolutely has caught on in a lot of professional applications, just not the ones that MIDI was initially designed to serve. It’s huge in the world of theater, for example.
(Background: I wrote the initial OSC implementation for QLab [a theatrical show control application].)
This was probably partly intentional, as it was designed by the academic community to solve the needs of relatively esoteric music production systems (e.g. [1]), whereas MIDI was standardized by a broad consortium of manufacturers of professional-oriented music products.
[1] https://www.synthtopia.com/content/2009/03/24/slabs-touch-pa...
> No, MIDI 2.0 is a transport agnostic protocol.
> That's engineering speak for MIDI 2.0 is a set of messages and those messages are not tied to any particular cable or connector.
https://www.musicradar.com/news/mini-jack-connectors-are-now...
That's fine if you're connecting everything to a computer, but it's kind of a step backwards from what MIDI used to be, which was an easy way to connect almost any keyboard to almost any synthesizer made in the last three and a half decades or so.
I've wondered if CAN bus would be a good modern-ish alternative to DIN-5 and USB, but I don't know enough about it to say if it has some limitation that's not immediately apparent but which would become a problem. (On the plus side, it's much faster than plain DIN-5 midi, allows longer wires than USB, and it seems to be supported natively on a lot of cheap microcontrollers.)
All wireless of course. Like Bluetooth but actually working. A man can dream.
PS: it would also stream multitrack audio over ASIO wireless and expose its inputs and outputs.
- perfectly synchronised
- zero latency
This may be hard to realise with lots of devices and wireless connections.
Assuming that the latency of the wireless connections is at least relatively predictable, you could just introduce a suitable delay like with NTP time syncing, right? Of course, it's possible that the latency will be wildly unpredictable and in that case it's pretty much impossible, but that doesn't have to be the case.
Also, my dream included vintage synths with just cv controls that would just connect to some dongle/wireless CV converter and boom, integrated. The dongle converted perfectly between all the various Yamaha, Roland and Moog standards.
For some reason this made me lol. The idea of cramming some JSON inside a SysEx seems crazy.
Hopefully the timing is actually improved in 2.0. Once you are past “hello world” getting midi gear to sync up has always been a nightmare.
One quote summarizes a couple thousand words "We should be designing to minimize the cost of human attention."
http://esr.ibiblio.org/?p=8254
when you can run all the world's stratum 1 traffic on a raspberry pi, you shouldn't be optimizing for bw and speed, but for bug-free-ness and security and ease of use. Likewise back when a minimal computer system was a multicard S100 Z80 system minimal midi made sense, but now a days it should be like adhoc wifi with a REST API or something similar.
Please read up on langsec.
When you look into it, while ESR says he's using JSON, he's really using a custom format that is readable by typical JSON libraries, but his format has very strict limitations, and his implementation is designed to error out early, rather than parsing an entire 10MB object tree before handing anything back to the application. He does not acknowledge this inconsistency in the article, only mentioning it late in the comment section.
Extensibility is valuable, but does that mean the format should support '"position": {"x":5,"y":[7.2,"XXIV"],"font-face":"Comic Sans"}', where every single object can have arbitrarily-many unrelated fields inserted? HTTP is better, with a flat key-value list, but if you build on top of HTTP itself, you now do not know if any of the systems on the network or libraries used might respond strangely to some obscure old header.
Personally, I think transmitting integers as text is at best rude, and somewhat comparable to Java allowing any reference to be null: Every client now has to handle an extra error condition on every parse. With binary integers, every bit pattern is valid, so you can perform a single range check to handle every type of bad input. Use 0x1234 as a magic number somewhere, and endianness errors are trivially debugged from a single sample packet.
Both very welcome additions! Finally no stepping on CC and note velocity, and the DAW can really know about the synth / controller capabilities, as it knows already with VSTs.
And keeps MIDI 1.0 compatibility.
Whatever this hustle is, it can fuck right off in my book.
I'd kind of like to see MIDI replaced outright with something built on a somewhat different (less piano-centric) abstraction; something more voice-oriented rather than note-oriented. Instead of having some number of fixed pitch notes that you turn on and off and settings that apply to all notes, you have voices that you can control independently (set volume, filter cutoff, control the envelope, disable and enable, and so on). You can do that now with the one-note-per-channel trick or MPE if it's supported, but it's kind of kludgy and only works with synths that are multitimbral to begin with.
Whatever this is, I'm hard pressed to care.
