In the course of working on my Fractal Music software in the 1980s, I developed a pretty detailed understanding of how the MIDI File standard worked, whereby a piece of music recorded in MIDI form in one sequencer can be exported to and read by a different one. As a user of the Finale music notation package, it occurred to me that it might be possible to do something similar for notation, although with many differences of detail from MIDI data. During 1992–3 I set to work on the idea and came up with what I called NotaFile (which a waggish friend immediately dubbed ‘Not a File’ — with some historical prescience as it turned out).
Once I’d developed something like a complete standard I wrote it all up in a detailed document which I sent off to various software houses and computer music organisations. Although I got some serious interest, it was never taken up, for reasons which were never made entirely clear to me. Perhaps others had similar irons in the fire at the same time, and had better connections in the business. Nevertheless, I’m presenting it here as a historical curiosity for those with a sufficiently nerdish interest in such things.
All my files for this document were in the old PageMaker format, so the original layout exists only in my printed copies. Nevertheless, I have managed to extract the readable text from among the acres of garbled PageMaker code and more or less replicated the original using Apple’s Pages software. Fortunately I did have most of the original music examples in a usable form (EPS). I did think of presenting the whole thing here in web form, but that seemed a conversion too far, so the complete document is available to read on line or download as a PDF, with just the introductory explanation below as part of this page.
Although I have corrected the occasional obvious typo, I have kept almost everything as it was, complete with mistakes, as well as what seem now positively quaint historical references to computer hard- and software. I’m painfully aware that I left out a huge number of possible musical expressions, both text and symbols — but it’s potentially endless, so where do you stop? A few of the more obvious omissions and errors are, in no particular order:
- No one- or two-measure repeat marks
- No pictograms for percussion instruments
- No mention of rf, rfz, etc.
- No way of setting preferences for beamed rests, flattened beams, etc.
- In Appendix I on page 28, for the second item down, I had the symbol (a big, square fermata for a long pause) in the original document, but can no longer find it in any of my music fonts!
- The third symbol in the same list, a staccato heavy accent, is misidentified as some type of fermata.
- And, I’m sure, many more...
So here, for your edification, is the Introductory section of NotaFile v 0.5, A Proposed Standard File Format for Music Notation:
Like sequencers, word-processors and many other kinds of application software, music notation or scoring packages vary widely and are available on several different types of computer. For this reason there is a good case for a file standard (equivalent to ASCII for text or MIDI File for MIDI data) for transferring information between them—NotaFile is a suggestion for a working title. Compatibility with such a standard could also be incorporated into sequencers as a far more appropriate means than MIDI Files for transferring data into scorewriters.
Work may need to go through several different stages, possibly at different locations, using different hard- and software. Music may be developed, by means of a sequencer (on, say, an Atari ST) in a studio, from which a score and parts would be required. A NotaFile could be prepared, which would then be taken to a bureau or other suitable firm who would import it into a scoring package (on, say, an Apple Macintosh). The same file (possibly modified by the first scoring package) might be imported into a second scoring package (on, say, an IBM PC) with superior facilities for part extraction. There are many other possible combinations for which NotaFiles could be useful. NB: no reference to specific hard- or software here is intended to imply any preference on the part of the author.
This document consists of four main sections: the rationale and overview which follows below, a detailed specification, appendices containing tables of byte values and, finally, three pieces of “real” music manually encoded into NotaFile format in order to demonstrate that this standard could work—references to these examples are made at a few points in the main text.
Why not just use MIDI Files?
Although the MIDI File standard has, in a few respects, become somewhat muddled, and rather less standard than it should be, it is in principle an excellent way of transferring MIDI data between programs that process it. It is, however, inappropriate for scoring software...
- MIDI Files include (or may include) a great deal of information which is irrelevant to such applications, such as Program Change, Pitch Bend, System data, some of the “meta-events” and much of the controller data (see below for a suggestion as to how some of this could be translated by sequencers), as well as channel information for every event. Some of this data also makes very intensive use of memory and disk space.
- MIDI Files omit certain essential information which could easily be included in NotaFiles, such as clefs, enharmonic information (eg D sharp/E flat—taking double-flats/sharps and quarter-tones into account, allowance should be made for 70 different note names in an octave), beaming of eighth (and shorter) notes, slurs, etc.
- Much of the potentially useful information in MIDI Files is in a form which is inappropriate to the purposes of a scoring program: all timing values are expressed in absolute numbers of “ticks”, giving rise to quantization problems with all but the simplest rhythmic usage (very few scoring packages can interpret a quintuplet correctly when importing from a MIDI File, and when they do it has to be by means of mathematical approximation, which is not ideal), and completely ignoring “rogue” elements such as grace notes; information about dynamics is also in an inappropriate form, or more correctly, in several inappropriate forms, such as key-velocity, aftertouch, breath control or volume.
- MIDI Files, when implemented correctly, provide an extremely compact way of transferring data. However, serious notation software is less likely than MIDI software in general to be used on small, floppy disk-based systems, and it would be worth accepting a somewhat larger type of file in order to transfer the right data.
NB: NotaFiles are not intended in any way to replace MIDI Files, but to be complementary to them, and many programs would be expected to implement both standards.
What kinds of software package would implement NotaFiles, and how?
There are three main categories:
Sequencers which do not include any notation facilities. These would most likely use NotaFiles for export only (if importing from a scoring program, it would probably be better to use MIDI Files), and would be able to implement the standard in only a fairly limited way—much of the information would be absent, eg beaming information, and it might be hard to define phrase marks, etc. without adding considerably to the program’s facilities (eg in a graphic or event editor there could be some way of flagging notes or other data with extra information, such as this very short note should be interpreted as a grace-note, not a 64th note).
Such programs could well offer an option as to which data is to be interpreted as dynamic (loudness) information—some of these are listed at the end of point 3 above—and the user could perhaps set ranges of values for each dynamic mark, eg 72–88 for mf. Another possibility would be for pitch bend data to be interpreted as notated glissandi—in this case the user would have to specify the pitch bend range of the voice patch for which the part is intended.
- Sequencers which do include notation facilities. This is an increasing trend amongst sequencers, and these programs are in an ideal position for implementing NotaFiles. They would still be most likely to use the standard for exporting data, but it is certainly conceivable that they might offer import facilities also. Even packages which offer only fairly basic notation facilities would usually cover all the types of data envisaged for the NotaFile standard.
- Scoring packages. These would certainly import NotaFiles, and very likely export them as well, as described at the start of this document.
These are merely suggestions, and the details of how NotaFiles were implemented would be up to the programmers (and users, hopefully) of this software. The possibility is not excluded that other types of music software, such as those that generate music in various ways other than from a MIDI instrument (even some which have nothing to do with MIDI), would implement NotaFiles.
The general concepts behind NotaFiles
The overall framework of a NotaFile, and several of the more “internal” principles, would be somewhere between those of a format 0 and a format 1 MIDI File. This includes the notion of allowing for possible future developments—even to the point of amalgamating the two at some point (though this may, after detailed consideration, prove to be impractical). The suggestions which follow, therefore, are designed with this in mind and conform fairly closely to the existing syntax of MIDI Files.
- There should be a header or “master” chunk which would identify the file type and include any information which applies to the whole score: the number of staves, initial clef for each staff, time signatures, tempo marks, rehearsal marks, title, etc. There is no reason why many of these data types could not appear in the music chunk (to follow), but it would be up to the software (and the user) to avoid conflicts, because any events found in this chunk should be assumed to be global. Unlike format 1 MIDI Files, however, there should not be the option to include music in this chunk—it would make no sense to do so.
- The music chunk would make up the bulk of the file, containing the information necessary for a program to produce, automatically, a fairly basic “scroll view” of the music. It is not envisaged that any aspects of layout would be included in this type of file: that, again, would be up to the programs and their users.
It should be borne in mind that there are two fundamental differences between MIDI Files and NotaFiles:
- The MIDI File is based on an existing standard form of digital data transmission (MIDI) whereas the NotaFile is not.
- The MIDI File works in a necessarily sequential way (in terms of time)—in keeping with the aurally perceived nature of music—whereas this need not, and often cannot (as will be seen below), be the case with the NotaFile, which deals purely with the visual aspect of music “on the page”. It would be difficult to over-stress this last point.
NB: We should learn from the mistakes of the MIDI File, and ensure that there is one file format, and that it is strictly adhered to—especially with regard to some of the potentially vaguer types of event involving various sorts of text.
How NotaFiles work (with reference to MIDI Files for comparison)
In the rest of this document, bit 0 means the least significant bit of a byte, and bit 7 the most significant. For convenience, the wording will be as if the NotaFile standard were already established.
Unlike the MIDI File, in which MIDI events and timing bytes are two quite distinct entities (and alternate strictly), all elements in the NotaFile are considered as events, including those which concern time.
In a MIDI File, MIDI events are always separated by “delta times” which represent the time that elapses between the two events. In a NotaFile, for reasons which will become apparent, all timing information is independent of the preceding event, and is required only when there is a change—not between every pair of adjacent non-timing events. These timing events should more properly be regarded as “position in score” events, since we are dealing with a visual medium.
There are three sorts of positioning events, the values of which are always absolute:
- Change of measure. This occurs whenever the next piece of notation is in a different measure from the previous one, whether earlier or later.
- Change of position in measure. This occurs whenever the next event is in a new place within the measure (again, whether earlier or later): eg if a note, an accent, a dynamic mark and a piece of text all occur at the same point, this event is required only once, and not between them.
- Change of staff. This allows, among other things, groups and phrases (especially in keyboard music) to cross from one staff to another. It also opens up the possibility of taking a “vertical” approach to music of a chordal nature (see the Mussorgsky example at the end). It is why the NotaFile is not organised in “tracks” like a format 1 MIDI File.
Any event can occur in the music chunk, including time signatures and tempi. This allows music of great rhythmic complexity to be included in a NotaFile, with different time signatures and/or tempi on different staves simultaneously. The Change of Staff event in such cases has to be handled with great care by the software, since measure 47 on one staff may be at a very different point in time from measure 47 on another, and it is at this new point that the next event will be expected.
This system allows considerable freedom in the way events are ordered in the file. In principle almost any order is possible (even backwards, from bottom to top), except that certain types of grouped events must appear contiguously in the file, such as beamed groups of eighth (or shorter) notes and tuplet groups, thus allowing overlapping groups on a polyphonic staff to be included correctly. (This applies only to the order of note events in such instances—other information such as expression marks can come in between note events in groups, as indeed change of position events must.)
In general, greater flexibility requires greater care on the part of those (mainly programmers) handling the data.
It is, of course, assumed that for the sake of coherence most programmers would prefer to create their files in a reasonably logical order, though that order could well simply be the order in which the user has input the data.
There is, intentionally, nothing in the standard which provides any checks for musical “correctness”—in particular, correct numbers of beats in measures (for instance, there would be nothing to prevent a Change of Position in Measure event from indicating the fifth quarter note in a 4/4 measure). As with so many other aspects, it is a matter for programmers to decide whether their individual products should do this, but the idea here is to allow for unorthodox notational usage if it is desired.
Apart from the events which concern position in the score, there are three other broad groups of events:
- Events which have a duration. These include notes, rests, slurs, octave marks, crescendi/diminuendi, trills, pedal marks, etc., though the way the duration is treated varies according to the event type.
- Events which have no duration. These include tempi, time signatures, key changes, clefs, dynamic and expression marks, etc.
- Text events. There are only a few types of these, but they should be used correctly.
Finally, there are three other events:
- A Screen message event for special purposes,
- A Software-specific event similar to the “sequencer-specific meta-event” in the MIDI File standard; and the obligatory...
- End of Chunk event to provide programs with a means of double checking this information.
As will be seen in the Appendices to this document, there is a far greater need, on the part of programmers, for extensive reference tables than is the case for MIDI Files. These should always be provided as part of the specification. This inevitably leads to many more of the
case type of statement in the program routines which handle NotaFiles than is required for MIDI File handling routines, but the results should justify the effort.