COMUSPRINT

Potted History

Way back in the 70s, I was plagued with orchestral parts created freehand and copied, often unreadably,  by the then ubiquitous Banda spirit duplicator. Since I was then in the process of writing a text processor for the GEC 408x series computers, I thought I might have a go at a music printing program. Having already done a literature survey of the field as a short M.Sc. project,  I homed in on the DARMS coding system for data entry.

The DARMS (Digital Alternate Representation of Music Scores) system, developed in the 1960s by Eriksson and documented in 1975 is a comprehensive, mnemonically based, QWERTY system for describing a music score which is relatively easy to pick up, and requires no hardware other than a text processor for data entry. Some suitable graphical output device is of course needed - the first working program used an incremental plotter for hard copy. The current version is device independent under Windows.

Although there are traces of DARMS' punched card origins, I resisted the temptation to tamper fundamentally with the 1975 specification, although I did add a few features and omitted some obscure codes for things I had never seen before, while attempting to write code to make it easy to add them if required. There are now many dialects of DARMS, unfortunately, with varying interpretations. If you want to see how many  music printing programs there are around, go to  http://www.music-notation.info/en/compmus/notationformats.html

The original program was written in Babbage and ran on a GEC 4082 machine, then migrated into "C" on a DEC machine (UNIX - mid 1980s), and accompanied me into early retirement (1991) and an early IBM AT machine.  When I got into Windows, the code eventually switched to C++. The current version is labeled COMUS99, following versions in '95 and '97.

Program Philosophy

Being simple minded, I try to compartmentalise program functions, with well defined actions, and resist the temptation to go for whizkid graphics and clever data entry. The target user will probably still be working with manuscript paper or have a clear picture in his or her mind's eye of the arrangement of dots on the staff systems. The data entry window is a simple text editor, with the interesting property that the system is usable, and is being used, by sight impaired composers. The User-DARMS version of the coding system is designed for efficient entry with many defaults; simple music can often be entered with one keystroke per note. Using Eriksson's nomenclature, the resulting score description is "canonised", or converted into an internal machine form, as the next step. Many errors can be caught at this stage and corrected. Once canonised, various things can be done with the result. The obvious one is to produce a printed score and extract parts, but another is to generate a MIDI file, from either the full score or  selected instruments, and listen to it. In principle, a properly canonised file can be used for any conceivable musical or musicological application.

As an alternative to QWERTY keyboard entry, direct entry from a MIDI clavier keyboard is implemented, on one instrument at a time, and converted to the equivalent DARMS code.  I like to think that it can be used without a metronome by a competent pianist; the  conversion software can track smooth variations in tempo. In addition it knows a few musical rudiments; given an initial key of the piece, and a key signature, it can have a shot at getting accidental spellings correct, and might even recognise simple modulations. 

A separate standalone program can import a multi instrument MIDI file and convert it to a DARMS code file. There are quite a number of free sheet music scores available on the internet, with accompanying MIDI files, and this program allows you to transpose if necessary.

The DARMS system is based on the idea of "Instruments"; each instrument is coded as a sequence of "events". In the drawing phase of a project, the user specifies the required layout of any combination of instruments, including the possibility of more than one instrument on one staff. Several different staff styles are possible; in addition to the normal 5-line staff, you can have percussion, 6-line lute tablature and text underlays, which are treated as a virtual instrument connected to a real "buddy" instrument. Staff heights can be individually controlled.

 The current COMUS system uses a multiple document window, so that in addition to the DARMS text editing window, any or all of the extracted parts can appear as well. This facilitates correction; by selecting an erroneous drawn "event" the user can return directly to the original DARMS code.

At this point, with a score or part displayed on  the screen, some limited editing operations are implemented, mainly as final cosmetic tweaking. For example, pieces of text or bar numbers may require moving slightly. It is very easy to redraw the score, which overwrites any edits one has done, so major editing, such as the addition of non-musical or non-DARMS glyphs is expected to take place more safely in the separate editor program.

While many operations are carried out by the software, it is usually possible to override the default behaviour. For example, it is possible to organise a sensible turnover point and change the number of systems per page.

Having got a good score it can of course be printed, but pages can also be merged with other scores, or copied to the clipboard in whole or in part and dropped into another document.

Click to see some sample output examples

which were copied from the clipboard into Open Office and exported as a pdf file.

If you would like to try this system, email me at comusprint.co.uk