I have come to be convinced that a simple but useful and fully accessible notation editor could be developed with surprisingly little effort using a Python-based music programming toolkit called music21. This toolkit provides routines that can read a MusicXML file and build a set of data structures to represent a score, routines that can process those data structures in various ways including adding and deleting notes and other elements, and routines that can write the data structures back out to MusicXML. So a program written using music21 would need only provide keyboard controls for accessing these functions.
A prototype for such a program was developed in July 2013 as part of Music Hack Day 2013. This prototype had limited editing capabilities but full and robust browsing capabilities featuring use of cursor keys to navigatw a score by element, by measure, by voice, by staff, etc.
Extending this to provide more editing capabilities should not be very difficult because, again, music21 really does all the difficult parts already. It’s mostly just a matter of designing the interface. We welcome feedback on how you think such a program should work.
Here is something I posted to the MENVI mailing list on this subject:
Most notation programs have a keyboard-based input system that really is
essentially just typing text. It’s just that you normally don’t ever
see the text – only the notation that results from typing. For example,
Finale, Sibelius, MuseScore, and Lime all support a note entry system
where you first press a number to set the current duration, then start
pressing letters to enters pitches. When you want to change durations,
you press the new number, then enter more pitches, and so on. So for
example, Mary Had A Little Lamb might be entered like this:
Type 4 to set duration to quarter note
Type E D C D E E to enter those pitches as quarter notes
Type 2 to set duration to half note
Type E to enter that pitch as a half note
and so on. That’s more or less *exactly* how it works in all of those
programs, except the specific numbers and letters you press to set
duration and enter notes differ from program to program.
Well, isn’t this really just a fancy way of saying we’ve defined a text
input system, where Mary Had A Little Lamb is represented as 4 E D C D E
E 2 E? I’m not saying I’d ever care to read that, but that’s what is
going on. It would be trivially simple for a music21 program to allow
you to type that, have it play back each note as you typed it, and most
importantly, to build up its own internal representation of the score
one note at a time as you type. Once you entered your music, it would
then be trivially simple for the program to read your score back in
plain English, “E quarter D quarter C quarter…” or “Quarter E D C D E
E Half D…” or however the program designer decided it should read.
This read-back could be in a plain read-entire-score-aloud-all-at-once
mode, or it could be made interactive, so you’d cursor through the score
and it would read what was under the cursor. music21 also makes it
trivially simple to playback that internal representation of the music
via MIDI – and that includes a “play from cursor position” as well as
“play current measure” or “play current staff” or whatever (all things
very difficult to pull off in a system based on ABC or Mup or whatever
unless you write your own language-aware editor). music21 also makes it
trivially simple to export this internal representation to MusicXML or
ABC, at which point another program could render it as standard notation.
So the program I am talking about would not have to deal with graphical
notation per se at all. It would mostly be about accepting typed input
and feeding it to the music21 system to build an internal representation
from, and conversely, reading the score back in English from that
I am confident that using music21, one could write such a program in a
fairly short amount of time. Like, not years or even months, but maybe
just a matter of a few weeks (for someone with enough time on their
hands) to get something simple but effective up and running. It would be
fully keyboard controllable and screenreader friendly from the beginning
because the program would really be doing nothing but dealing with text
input and output and then calling other programs to convert this to
standard notation as necessary.
I keep emphasizing the phrase “trivially simple”, and I really do mean
it. Developing such a program really would *not* be difficult at all,
since music21 does most of the hard work for you. Whereas taking an
existing notation program and doctoring it up to be more accessible is
*not* necessarily that simple. At least MuseScore is open source, so
it’s logistically feasible if you have the skills. But it’s actually
still a lot of work, and I suspect the results would still prove
cumbersome for most blind users to deal with, just as I hear many report
about trying to use Sibelius with its various accessibility options.
Note entry, after all, is only part of the equation. What about things
like setting and changing key or time signatures, adding articulations,
etc? While traditional notation program may set up keyboard shortcuts
for some of these operations, or provide keyboard control for the
necessary dialogs, it’s unlikely they could be as streamlined as
something designed from the ground up for accessibility. Or, for that
matter, as with a text-based system. If you want to change key signature
to D in the middle of a piece in ABC, you do that by simply typing K:D
where you want the key change to occur. Tough to improve on that from a
usability standpoint. Well, a music21 program designed to take text
input in the manner I am describing could do just as well.
In fact, I’d say the hardest part of building the program I am
describing would be simply agreeing upon how the input system should
work: what specific commands it would need to support, etc. Entering
notes, obviously, entering and changing key and time signatures,
indicating where barlines occur (although this could be done
automatically), a way of specifying dynamics, articulations, lyrics,
chord symbols, etc. All of this could be modeled by first thinking in
terms of how it would be done in a text-based system like ABC or Mup,
and then envisioning how this might translate to a more interactive
program as I am describing. So that’s stuff we could be discussing here.