MIDI has always been about connection. For more than four decades it has been the shared language that lets instruments, computers, controllers, and creative software understand one another.
The MIDI Association’s Music Accessibility Standard Special Interest Group (MASSIG) is now asking whether that same language can do something new: let a musical instrument describe itself — in words a musician can hear, read in braille, translate, or feel — so that blind and low-vision musicians can work independently with the hardware they love.
We introduced that idea earlier this summer in Assistive Text in MIDI: A New Path Toward More Accessible Music Technology.
Since then, the concept has moved from a proposal to a shared plan.
A three-hour advisory session —hosted by Jay Pocknell of Sound Without Sight — brought together accessibility experts, blind and low-vision musicians, hardware manufacturers, software developers, researchers, and MIDI 2.0 specification editors to pressure-test the idea and shape what comes next. This article revisits the vision and reports on what that group agreed.
Why assistive text matters
Contemporary music hardware — synthesizers, mixers, drum machines, effects units — leans heavily on small visual displays and rows of unlabeled controls. Worse, the meaning of a control often changes with context: a single knob might govern filter cutoff one moment and reverb depth the next. Sighted players read that information at a glance. Musicians who rely on assistive technology usually cannot access it at all, unless a manufacturer has built a bespoke, proprietary solution.
The goal of MIDI Assistive Text is disarmingly simple to state: when a musician touches a control or changes a parameter, the device should be able to say what just happened in a way that can be spoken, displayed, translated, filtered, or adapted. Standardizing how that information travels — across devices, manufacturers, and operating systems — would benefit not only blind and low-vision players but also music educators, multilingual users, and anyone navigating a dense, menu-driven interface under pressure.
A concept that has already been proven in pieces
The advisory session opened from a position of encouragement rather than blank-slate speculation, because several companies and projects have already shown that accessible music hardware is achievable:
- DiGiCo’s DiGiVoice project for accessible mixing consoles
- Ableton Move’s built-in screen reader functionality
- SurfaceReader and related MIDI 1.0 accessibility implementations
- NYU’s SynthAccess (MIDI-to-Speech) research project
- Native Instruments’ NI Accessibility Helper app
- Softube Console 1’s screen reader functionality
Each of these solves the problem in its own way. The opportunity — and the reason the MIDI Association is well placed to lead — is to turn that scattered innovation into a single interoperable standard, so that accessibility becomes part of MIDI itself rather than something every manufacturer must reinvent alone.
The architecture: hardware describes, software presents, the user decides
The clearest point of consensus from the session was also the most important, because it defines the shape of everything else. The group agreed on a clean separation of responsibilities:
- Hardware sends meaning. A device reports semantic information — parameter names, values, units, menu context, control names, LED states, preset names, connection status — without trying to speak or format anything itself.
- Software handles presentation. A receiver utility (or an operating-system service) takes that structured information and turns it into speech, braille, large print, or another output.
- The user stays in control. How much is spoken, when, how fast, and what takes priority are all decided by the listener, not the instrument.
In practice, a synthesizer would emit something like “Filter cutoff, 3012 hertz” and a mixer “Channel 5 mute on.” A text receiver utility would route that to whatever assistive technology the musician prefers. Notably, Native Instruments’ Stephen Penny and Matthew Hines described the internal architecture of their Accessibility Helper app — raw hardware data flows into an application, which makes verbosity decisions before handing text to a screen reader — which independently validated the very structure the group was converging on.
Mike Kent’s four-class model
One of the most valuable outcomes of the session was a framework proposed by Mike Kent of the MIDI 2.0 working group: four “classes” of operation that let the standard deliver value immediately while evolving toward a full MIDI 2.0 profile over time.
Class 1 — Interpreting existing MIDI messages
A utility interprets standard MIDI messages — Note On, Program Change, Volume — and describes them in words. It requires no firmware changes and works with decades of existing equipment, though the contextual detail it can offer is limited. Crucially, this class works today, over ordinary 5-pin DIN MIDI.
Class 2 — Device-specific configuration files
A shareable file (for example JSON) describes how a particular device uses MIDI, so that instead of hearing “CC 74, 92” a musician hears “Filter cutoff, 4.2 kilohertz.” This is ideal for knob-per-function designs and older gear, and it can be authored by the community from a device’s MIDI implementation chart — no manufacturer sign-off required. Class 2 also runs over legacy DIN MIDI.
Class 3 — A native MIDI 2.0 Assistive Text Profile
The long-term standard. Using MIDI-CI, Profiles, Flex Data, dictionaries, and Property Exchange, a device can advertise its capabilities and send meaningful text directly. Short phrases can travel as Flex Data messages; longer content can use other mechanisms. This class requires MIDI 2.0 transports such as USB or network MIDI.
Class 4 — Interpreting other MIDI Profiles
A lower priority, but a powerful one: assistive text working alongside other Profiles — piano, organ, DAW control, macro control — so the utility can generate meaningful descriptions that reflect a control’s current assignment automatically.
The elegance of the model is that it is a progression, not a fork. Class 1 delivers accessibility to existing gear immediately; Class 2 adds rich, community-authored detail; Class 3 makes it native; Class 4 makes it comprehensive.
Meeting the installed base: SynthAccess and legacy devices
https://idmnyu.github.io/synthaccess/MIDItoSpeech
A standard that only helps future hardware would leave most of the world’s instruments behind. One of the session’s most productive threads addressed exactly this. R. Luke DuBois and Madeline Mau of NYU presented SynthAccess, their JSON-based accessibility system for MIDI 1.0 devices, which already provides JSON descriptors, braille overlays, tactile guides, SysEx parsing, keyboard macros, and menu navigation — all in an open-source repository, and already tested with hardware from makers including Focusrite, Novation, and Oberheim.
The overlap with Mike Kent’s Class 2 is substantial, and the group treated that as an opportunity for convergence rather than competition. SynthAccess is, in effect, a working reference for what Class 2 can be — including the harder cases. Legacy synthesizers such as the Yamaha DX7 and Korg M1 report front-panel edits as manufacturer System Exclusive messages rather than as CC or NRPN data, and the SynthAccess schema is being extended with a data-driven SysEx parser so those edits can be voiced too — keeping the manufacturer-decoupled, community-authorable character that makes the JSON approach so attractive.
The hard problems the group tackled
Verbosity. Turning a single knob can generate thousands of messages — far more than any speech engine can voice. The consensus was firm: this complexity belongs in the utility application, not the hardware. Manufacturers should send as much information as they can; the software, guided by user preferences, decides what to speak. Proposed tools included configurable debounce timers, message queues, priorities (a clipping alert, for instance, should be able to interrupt everything else), and subscription models where a user opts in to dynamic values like meters or BPM. Tim Burgess and others noted that skilled users often want the newest message to “rudely” interrupt the previous one, and that speech rate should be configurable — experienced screen-reader users run it fast.
Dictionaries and translation. Rather than transmitting the word “Volume” every time, a device can send a dictionary ID that the receiver resolves to a localized term — saving bandwidth, ensuring consistency, and enabling translation. The group agreed to support both a device-holds-text approach and an OS-dictionary-with-ID approach, since they are complementary: a small built-in dictionary of common terms can cover most cases while a device supplies anything extra. A promising reconciliation raised in follow-up discussion was to let the device reference a dictionary by URL — served, for example, from a CDN — with the instrument’s onboard text as a fallback when the URL isn’t reachable. The strong preference throughout was to lean on operating-system translation where possible, so that small manufacturers are not asked to maintain dozens of language packs or license on-chip text-to-speech.
Bidirectional and remote control. What began as an optional idea grew into an important long-term objective. If a musician can query a device — “what’s the current cutoff?” or “read the current preset” — without touching a control and accidentally changing the sound, accessibility improves dramatically. Stephen Penny observed that you cannot simply keep adding physical buttons to hardware, so remote control should be baked into the protocol from the outset. The group also recognized that this benefits far more than blind and low-vision users: bidirectional control helps players with motor differences, supports alternative controllers, and is useful for general studio management. Property Exchange — a JSON-based subscription model that works over MIDI 1.0 transports — was floated as a natural foundation.
Beyond speech
Because the standard carries structured text rather than audio, the same information can be presented in many ways. Once it reaches a receiver utility it can be routed to screen readers, refreshable braille displays, large-print overlays, accessible web interfaces, and future technologies. The group discussed haptic feedback as well — Jason described customizable haptic alerts in Softube’s Console 1 for events like clipping — and the value of a “training mode” that lets a musician explore a device and confirm control states without sending performance-changing data. That query-without-consequence capability gives assistive-technology users the same reassurance a sighted player gets from a quick glance.
Principles the group committed to
Several values recurred so consistently that they now read as design commitments. The receiver should be open source and, at least initially, a standalone application, so the community can contribute and support modified hardware. There should be no vendor lock-in — as Madeline Mau put it, disabled musicians should not have to choose their instruments based on which proprietary accessibility ecosystem those instruments happen to support. Software plugins should continue to use native operating-system accessibility APIs (VoiceOver, NVDA, Narrator, Orca); the new specification is aimed squarely at external hardware, which has no access to those frameworks today. And Linux must not be forgotten — a point raised repeatedly in the chat. Above all, the work should be done once, well, on everyone’s behalf, so that any product designer can build an accessible product even without being an accessibility expert. In a business that runs on thin margins, the standard has to be the low-cost, obvious choice.
Why MIDI, and why now
MIDI 2.0 arrives with exactly the machinery this problem needs: bidirectional communication, capability discovery through MIDI-CI, Profiles, and structured data exchange. The MIDI Association is also uniquely positioned to convene manufacturers and operating-system vendors around a single approach. That matters more than it might seem, because accessibility is increasingly a matter of law — regulations such as the European Accessibility Act create real pressure to comply, and standards-based mandates are far easier to satisfy when a written industry specification already exists. A specification could later be registered through a larger international body to give it worldwide legal standing, the same path MIDI has taken before.
The road ahead
The session closed with a concrete plan rather than a wish list. A dedicated Assistive Text working group will carry the effort forward, define the scope of version 1, and host the work in a public repository. Near-term development focuses on an open-source receiver utility with Class 1 and Class 2 parsers, a JSON configuration format, and prototyping across Windows, macOS, and Linux with NVDA, VoiceOver, and Orca. From there the group will draft the MIDI 2.0 Assistive Text Profile itself, along with the verbosity, priority, localization, and subscription models that make it usable in the real world.
Several milestones are already on the calendar. Mike Kent is targeting a draft MIDI 2.0 Assistive Text specification for early 2027, with operating-system implementation likely following later that year, and is about to release a public, accessible MIDI 2.0 Monitor tool — complete with CSV export — that plays a subtle tick per message so a blind user can sense the density of a MIDI stream even when only one message is spoken. Native Instruments is exploring internally whether its Accessibility Helper app can be open-sourced. And Jay Pocknell of Sound Without Sight is organizing a follow-up hackathon to prototype the ideas discussed. Throughout, the group committed to user testing with blind and low-vision musicians — including non-technical players — to establish sensible default settings for the receiver app.
Get involved
This standard will only be as good as the range of people who shape it. We need blind and low-vision musicians, accessibility specialists, hardware and software developers, DAW makers, operating-system vendors, educators, and standards experts — and we need the practical questions answered as much as the technical ones: What information is genuinely useful? How should a musician control how much they hear? Where should text strings live? If you build music technology, use it, teach it, or care about making it accessible to everyone, the MIDI Association’s Music Accessibility Standard Special Interest Group would like to hear from you.
The next step may be helping instruments talk to musicians in ways every musician can use.
With thanks to session co-hosts Athan Billias (MIDI Association) and Jay Pocknell (Sound Without Sight), and to everyone who contributed, including Mike Kent (MIDI 2.0 working group), R. Luke DuBois and Madeline Mau (NYU SynthAccess), Stephen Penny and Matthew Hines (Native Instruments), Tim Burgess, Haim Kairy (Arcana), and the many blind and low-vision musicians and accessibility experts whose insight is driving this work.