Musical Technical Meltdown

I've spent the past 48 hours as a technical User not programmer. My wife, composer Carol Worthey, utilizes a great Music Notation program whose development ceased a decade ago. It's a MAC-based program written by a bunch of MIT grads who were also excellent musicians, so it's got a lot going for it. It was the premier (and only) professional-grade software that was available for quite some time. It was also quite expensive. Today it's showing its age... it contains un-fixed bugs.

Composing and notating music is a very complex task. Performed music only requires a listener, written music although, is an historical system. In other words, as a system, music notation is not clean. The "rules" for its construction vary in many aspects, are in conflict, subject to authority and opinion, extension is arbitrary and terminology extensive and arcane. This is what one would expect from a human communications system... the written document is intended to convey to a human performer how to render the work.

There is another communications system that now enfolds (engulfs?) technical rendition of music best referred to as MIDI (Musical Instrument Digital Interface). This is a data stream of simply: timings, notes (pitches), durations and intensities. Equipment designed to render this notation into sound (a performance) cares not for nuance or interpretation or human qualities. It is dead literal; there is no interpretation involved. Creating such a data stream that mimics human qualities is quite an undertaking and is part of my problem with using the program and system we have set up.

Traditional, hand-written musical scores are great--you get exactly what you want. The computer requires input in the manner in which the programming was created and (usually) only that way. In our scenario we get all of the notation entered (composed) by hand, then the data gets turned into a Conductor Score, Piece Parts and MIDI. The MIDI is transferred to a sampled-sound system where instruments are assigned to parts and the result output by sequencing software as sound. Here's the rub, the grand scheme is flawed, these three elements unintentionally are in conflict with each other and the software will not be fixed!

Work-arounds

Should be called: work, work, work, work, work-arounds. When the Conductor Score is created, the voices of several instruments are combined and displayed as one stave (the 'staff', you know, that group of five horizontal lines that hold 'notes' the little black dots with flags--for you non-musicians out there). This is important for the orchestra's conductor so he can easily see the relationship of several of the same type of instruments playing together, for example: Trumpet I, II & III. Each of the trumpet players--in this example--needs to have printed music that contains their individual part or the Piece Part. For example: Trumpet II, Violin II, Clarinet IV. Now we also need a MIDI data stream or track that has the notes etc. for each of these parts so that later we can assign a sampled sound (like a trumpet) to this track to play (perform) these notes using audio equipment. This last is not a problem. What is a problem is that the piece parts for the musicians usually have extensive performance notes (text) that create the nuances that make real orchestral music a delight. These pieces of text also show up on the highly condensed Conductor Score usually making it unreadable. Finally: if you delete the text notes from the Score, they are removed by the program from the Piece Parts. This is not surprising as both are generated from the same database. What it does mean is now data copies have to be made, one to support the Score, one to support the Piece Parts. Any further changes or edits must be propagated to both sets of data and the program does not facilitate making duplicates of data--it's a very tedious procedure.

Lastly, it may be that there are errors in the way we are entering data into the program. The really well-written manual for the software is 1 1/2 inches thick and I have never read every bit of it. The relevant sections on 'text entry' explain available 'features' but there is no tutorial about why you would use any particular feature.

Being a User is quite difficult. I have never enjoyed being at the end of an effect chain where I cannot correct a problem at the source which is perhaps why I've spent so much of my life writing software.

This week's experience again reinforces the reason open-source software must survive. It really is an issue of freedom. I certainly would not want to have a job that was a work-around, a job ready to vanish or get much worse with the next software "update."