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.
Audio processor graph
Several times we’ve worked on projects in the pro audio/music instrument industries that have used a very useful C++ cross-platform application framework called ‘JUCE‘. It was originally developed as part of the ‘Tracktion‘ digital audio workstation, and later extracted out as a standalone framework (in much the same way that Ruby on Rails was extracted from 37 Signals’ work on Basecamp). For open source projects, JUCE is licensed under the GPL, and for commercial projects it’s licensed under a very reasonable per-company license (not per-project, or per-year). Applications written using the framework can be deployed on Windows, OS X, Linux, iOS, and Android.
For audio developers, it’s an incredibly useful framework that contains solid and well-conceived classes to deal with many of the lower-level tasks that any application processing audio will need to deal with — opening and configuring multichannel audio devices (which may involve dealing with numerous different driver stacks), finding and loading audio effects plug-ins (again — several different formats exist in the wild, including VST and Apple’s AudioUnits), accepting and generating MIDI data, implementing audio effects algorithms, reading and writing audio files, and so on.
I’ve worked on a few projects that used JUCE, but was never involved in any of the work that touched that audio layer. I’ve been considering writing the next version of a long-standing personal music software system over to JUCE, and after spending some time poring over the documentation and sample code, I decided that it would be best for my sanity to start with a smaller project as a learning experience, and document what I learned as I go.