I feel MIDI is severely underutilized outside music. It's a simple, standard protocol that relays switches being turned on/off, and knobs being turned high or low. The only standard alternative that I know about is would be USB HID interface which has its limitations.
What are some cool uses of MIDI you have seen outside music-making?
> 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]
"Better" is a matter of requirements. You can interpret a stream of bytes of MIDI with some tens of lines of C code and a couple of bytes of interpreter state. The physical interface is less than a handful of components. For OSC you need an IP stack.
Except a lot of MIDI in control type situations (lighting, user triggers) is run over ethernet these days. So if all things are equal on that front, OSC is a far superior design.
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.
Sorry, a brief glance at the OSC website would have corrected that misconception.
That said, I only assumed as much because I don't know of any OSC client software that uses anything other than IP networks to facilitate device to device communication. I googled for serial OSC software and found some nonetheless. Does your software support OSC over serial?
I agree that it's a MIDI port. That's not under contest.
Because every claim that it's MIDI I've seen has failed to substantiate it, I searched around a bit today and found the developer of MIDI-Maze II and contacted him. Only the physical layer of MIDI is used. He furthermore said that MIDI doesn't allow a ring network anyway, in which case this must also be true for the first MIDI-Maze.
So no, the player limit has nothing to do with MIDI channels. Maybe be more clear about whether what you're saying is an unsubstantiated guess or something that you actually know. Your message reads a lot like you know it for a fact.
I haven't done a write-up yet, but my partner and I use MIDI as part of our custom lighting setup, which we bring to gigs and other events. A MIDI controller is hooked up to a raspberry pi running some Python software. We use the `mido` library for decoding MIDI. We then drive a bunch of RGB LED strips using DMX. Video: https://www.instagram.com/p/BtjLSUeFjtJ/.
The main reasons I’ve seen VJ’s use MIDI is that they can slave their rig to the performer’s Ableton Live setup. I’ve got friends that have set up timing triggers to pyro and displays / lighting (interfacing with the VJ’s rig) within a few hours of stepping off a plane for a gig that night.
It’s comparable, and in some ways superior as a general control protocol, to Modbus. Can’t recall the specifics but MIDI seemed better defined and generally saner (IMHO).
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.
DMX is standard for lighting, but although the actual protocol is rock solid the parts around it are no where near as good as MIDI. Device to device is fine, but USB DMX controllers are expensive and rubbish in my experience using them to control a ~100 piece (dumb) lighting rig
I completely agree. We are launching a new web app/platform soon and have completely integrated the web midi and gamepad APIs, allowing you to control any piece of the software with any midi controller and/or gamepad, including devices like the new Microsoft adaptive controller, which supports many more types of analog switches.
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.
The MIDI pins on game ports were an add-on on sound cards to unused pins from the game port, though. The original game port spec doesn't have anything to do with MIDI or UARTs, and joysticks and the like did not use those extra pins.
And iirc game-ports were usually their own expansion card. It wasn’t until Sound Blaster decided to include it on their cards that we started seeing it integrated into the sound card (part of a sound cards job is Analog to digital conversation, why not do the ADC conversation needed for joysticks as well? Also, games normally also want sound so seemed like a nice why to bundle everything you need onto a single card).
I agree there is many use, which is what I have done with IMIDI. You can also use it with television and all sorts of stuff. While most of the commands are same as MIDI (a few are removed, and also a few having to do with forwarding signals to connected devices are added), some of the meanings are bit more general, and the signal is two ways and the format of the SysEx payload is different (and does not require any kind of registration) (although the framing is same as normal MIDI, so if the signal is recorded by something that does not interpret SysEx payloads, the recording will still work). You can also forward signals to other devices; you can have a tree structure of devices and each device can have up to 128 children, selected by the use of the Device Select command (which is an optional implementation; compliant implementations are required to parse the command even if it is otherwise ignored; this is the same with all other commands, which it is required to parse even if it is otherwise ignored). (My own intention of a computer design is using IMIDI for all of the input devices, rather than USB or PS/2 or whatever (I dislike USB). And you can also use the IMIDI to transmit captions along with a television picture (the picture using Digi-RGB, and the sound using ordinary analog audio ports), and/or to control the channel setting of a external TV tuner and to control the VCR, too).
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.
I think most of the use cases you think of are currently covered by the USB Test and Measurement Device standard and/or the instrument control protocols (GPIB, VISA).
I agree. I was watching the first video in the article and thinking there must be similar standard protocols for IoT orchestration. I mean, anything that can be controlled and needs orchestration must have some kind of similar protocol?
What are some cool uses of MIDI you have seen outside music-making?