"Wouldn’t it be cool if…"
We’ve all had that thought about something. How do you get from there to a product you can use and share with others? When I found myself playing with an idea that seemed exciting and new, I decided to capture some notes on the process, from the perspective of an Engineering Manager at a company that’s all about implementing people’s creative visions.
After over a decade of work, the final specification documents for MIDI 2.0 have been released to the public!
There’s a fantastic article on the MIDI.org site that explains what the hubbub is all about that I’ll just point you at rather than rewriting — check it here: Details about MIDI 2.0
When MIDI 1.0 was released in 1983, the complete document that detailed all you needed to know about it was eight pages long. Expect to need to read a bit more than that in 2020—the full spec for MIDI 2.0 is five separate documents, each looking at a single part of the system:
M2-100: Overview of the specifications
M2-101: Specification of MIDI-CI, the Capability Inquiry portion of MIDI 2 that’s required to enable devices to query each other and determine how two devices can work together.
M2-102: Common Rules for MIDI-CI Profiles explains how to define and work with MIDI 2 profiles to define controllers and other configuration data to permit devices to automatically adapt to the capabilities present in the currently connected instruments.
M2-103: Rules for Property Exchange, the new provisions for querying current settings and capabilites of connected devices
M2-104: Definition of the new Universal MIDI Packet data structure and the high-resolution MIDI 2 message protocol.
Before you can access these documents, you’ll need to create a (free!) account with The MIDI Association, which is an organization of MIDI users. If you’re not already a member, the link to access the docs will redirect you first to the login/account creation page.
Download everything here and then go make cool stuff with it.
It was August 1, 1981.
I sat on the hotel room floor, surrounded by guitars, keyboards, and gadgets, doodling on a complimentary Holiday Inn notepad. Dad tinkered with a motherboard as his soldering iron glowed, delicately balanced on the edge of an ashtray. The smell of pork chops, rice and beans wafted through the air as mom worked her magic on our portable double burner stove. I sat on the floor, glued to the television. It was that very moment the iconic M came to life and made its beautiful debut. (more…)
Thanks to the blizzard that hit my East Coast home base while I was at the NAMM show this past weekend, I’m currently cooling my heels in a Starbucks near family in San Diego while figuring out how to get home. I’ve been trying to figure this out since the second morning of the show when I got the first email of several telling me that my flight home was canceled, so I ended up missing a significant amount of time on the show floor speaking with clients and checking out new gear — very frustrating.
One unexpected upside of being stranded in Southern California was that I was able to attend a developer meetup hosted by ROLI, the owners of the JUCE C++ framework that’s widely used in the industry. (more…)
Last time we looked at getting a very basic version of an application that can process audio running using the classes provided with the JUCE application framework.
The Scumbler app as we last saw it:
- Could enumerate the installed audio/MIDI hardware on a computer
- Let user select which hardware to use
- Persisted that setup information between invocations
- Created an AudioProcessorGraph object and an AudioProcessorPlayer to stream blocks of audio samples through
- Created AudioGraphIOProcessor objects for performing actual audio input and output, which when wired into the filter graph successfully got audio moving through the application.
A lot of work to basically do nothing. This time, we’ll add some meatier stuff — the ability to add and control VST or AU plugins into the filter graph.