Here I'll put a copy of the docs that went with last semester's final version, and a screenshot.
December 17, 1999.
The Squeak MusicEditor is a simple system for creating and playing standard music notation.
Installation: There are two important components to install. The first is the Squeak code, which may be filed in as usual. The second is the library of bitmapped image files. These files are to be placed in a "music" subdirectory beneath the main Squeak directory. For example, on my installation, the various .gifs are in the path /squeak6/music/. You should make sure the image files are there before filing in the code.
Running: In a morphic project, choose "new morph" -> "MusicEditor" -> MusicEditormorph". The editor is fairly large, and currently doesn't appreciate being resized, so it will take a lot of desktop space.
What you can do: Generally, you drag components from the toolbox at the bottom of the editor onto the staff. Most components have properties you can edit with their own menus (middle button for me, on NT). Notes and rests can have their length changed, or dots added or removed. Key and time signatures can be altered. Clefs can be changed.
There are 4 command buttons. You can respace notes - this will give a fairly even spacing between components. You can play what you've entered. Playback should properly interpret differing clefs, accidentals, note/rest values, and key signatures. Should you want to end playback prematurely, you can use the "Be Quiet" button. Finally, you can Quit!
The 2 way scrolpane you see had to be adapted from the provided ScrollPane, which only scrolls vertically. Thanks to Yohei Ikezoe for fixing some problems that came up. It still doesn't refresh its scroll bars properly as its contents resize (neither does the standard scrollpane).
Modern music notation is complex, and arbitrarily complex. My biggest concern at the beginning of the project was getting a powerful data structure that would be flexible enough to represent a reasonable set of music. I came up with some great propeller head solutions, and they were all way too complicated. In the end, I decided to take advantage of the structure built into morphic. If bitmapped images are one extreme and vector graphics another, my system is pretty close to the vector idea. A staff's submorphs hold on to most of the various components you can put on it. Context sensitive components such as key signatures, which rely on other information such as the current clef, get this information by querying the staff. Most of the functionality of the editor is in the staff. The editor you see is mostly a visual wrapper to save cumbersome menu operations.
The structure I picked is fairly simple to implement and traverse. For example, playback consists of iterating through a staff's submorphs and taking the right action for each one. State information needs to be kept for keys and accidentals. Such a simple system has a few drawbacks. it isn't possible to have more than one note at a time going on. With the addition of layers this can be alleviated.
The hardest single problem I found was multi-note barring. Its still not finished. The problems include: how does the user select what he/she wants to bar together? How to break or combine bars? Do the stems go up or down? How to represent them? I've settled on using submorphs for a simple tree structure. Submorphs will have to find out how far "down" they are to know where to draw their bars. As for deciding whether to stems up or down... This isn't always obvious, even to a person. I think I'll make a simple decision based on the first and last note, and let the users manually force stem up/down if they want.