Hacker News Reader

Comment by mathnmusic | Hacker News Reader

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?

View on HN

How about controlling a band consisting of robots playing real instruments? [0]

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...

I read the first line of your post and I seriously expected the YouTube link to be this:

https://www.youtube.com/watch?v=evHVh4bqaOQ

All controlled by MIDI, unsurprisingly.

Thank you so much for that rabbit hole.

There are better protocols outside of MIDI like Open Sound Control aka OSC (http://opensoundcontrol.org)

I used to do a lot of experiential retailing experiences and OSC was our preferred control scheme.

what is experiential retailing?

Usually some type of creative interactive retail experience, anything from wall displays or projections that users can interact with to simple kiosks.

"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.

Nah, OSC is just a message format. I see it routinely used across a serial port for instance.

(disclaimer: I develop an OSC-based sequencer, https://ossia.io)

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?

> Does your software support OSC over serial?

not yet, sadly ! I've got a lib for that however : https://github.com/jcelerier/oscour

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.

Midi maze? :)

https://en.wikipedia.org/wiki/MIDI_Maze

I haven't listened in on the data but it seems likely that MIDI Maze only uses the electrical standards, i.e. a proprietary protocol over MIDI ports

It's a midi port. It does midi. Hence the limit of 16 players. Every player is using a dedicated midi channel.

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 stand corrected then I guess. I definitely read before that it uses plain midi messages.

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/.

Is there a reason you chose to do that rather than use something more standard like OSC or ArtNet?

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.

DMX is very standard for lighting control

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.

1: https://github.com/PatternAgents/Electronics_One_Workshop/wi...

I'm not in that industry, but isn't it also used for controlling stage lights in some cases?

Yep, am using QLC+ at the moment and it has profiles for all sorts of midi controllers. https://www.qlcplus.org/

That's DMX512.

MIDI will often be used to trigger the console to change cues which then uses DMX512 to control the lights.

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.

I've used MIDI ports on an Atari ST to control tool changers and coolant pumps on an industrial CAD/CAM station.

They are being use on photography editing software: https://petapixel.com/2019/01/26/using-a-midi-controller-wit...

Back in the 90’s, MIDI was used by some firework detonators to sync the launches and explosions with music, etc.

You could use it for game control having a super low latency midi controller would also work for game controllers

Indeed: Pre-USB "game ports" doubled as MIDI interfaces. https://en.wikipedia.org/wiki/Game_port

I broke multiple joysticks on Wing Commander this way.

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).

There is OSC, which I think is under appreciated. It's super easy to implement, it's literally just UDP.

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?

Lights, Props, Water Fountains, Drones. Anything that can be a show in Las Vegas.

DMX512 does that, too, and it seems even simpler to me.

MIDI is extensively used for stage light control.

not sure if it qualifies as "cool" but i see midi controllers being used a lot for live video mixing in clubs / events

edit: spelling

Reply on news.ycombinator.com