Gsharp is an interactive, extensible editor for musical scores.
The goal of the project is to provide, as free software, an interactive score editor giving a high-quality presentation on the screen as well as on paper output
This is a very ambitious project that has been going on for years, mainly because I only work on it part time, but also that the design of such a program is very difficult and I have had several bad starts and made several bad design decisions in the past.
This time, things are looking much better, although the program is nowhere near completion. Gsharp is now a pure Common Lisp application using CLIM, the Common Lisp Interface Manager, as its library for managing the graphic user interface.
Our new release is 0.2 as of 2003-09-06 which is available as a compressed tar file. In it you will find some documentation, that you can also download as a compressed PostScript file, or as an uncompressed PostScript file
This feature adds important new features compared to 0.1, but many basic features are still lacking. However, the basic infrastructure feels quite good. The line breaking algorithm seems to work, and is fast despite not being optimized. Calculation of stem lengths and beam slant (single beam at the moment), and beam positions is in place. Automatic placement of accidentals in very complicated clusters also appears to work.
You will find a longer list of what works and what does not work in the documentation.
This screen shot shows the current state of Gsharp. Beam slant, stem lengths, line breaks and spacing have been computed automatically. You can clearly distinguish between the active layer (all black) and the other layer (gray). If you look carefully, you will see the gray-scale (anti-aliased) fonts that are used. If you look even more carefully, you will see that drawing is not perfect yet: for one thing, noteheads that are too close are painted over each other. You can also see that the key signature is not displayed, nor is the time signature.
This screen shot is similar to the previous one, but uses our smallest font, only 6 pixels between two adjacent staff lines. The main defect you can see in this screen shot is that some notes are still drawn AFTER some of the ledger lines, whereas the gray-level font idea depends on the order being reversed.
This screen shot shows a more complicated piece (for piano) in that voices come and go. The clusters are also more complicated than those of a Bach chorale. We have also set the spacing much tighter than in the previous two screen shots. The result of this tightness is that you see some exceptional beaming in the first line. The first line being tighter than the second, similar beam groups on the first line will have a smaller beam slope than the corresponding cluster in the second line. All of this is computed automatically. The score used as a model for this example contains some blatant violations of the rules (beaming in particular) given by Ross, whereas the beaming algorithm of Gsharp does not have that problem.
This screen shot shows the automatic placement of accidentals in complicated clusters. These examples all comply with the rules announced by Ted Ross in his book about music engraving.
Help to improve Gsharp is greatly needed. The documentation contains some hints regarding future directions. However, aside from bug fixes and trivial improvements, it would be highly desirable to contact me before starting to work on a substantial piece of code. It is not always crystal clear what it is that I imagine as the future for this project, and sometimes I do not even know myself.
