The problem of music modeling in computer systems has been addressed several times in the literature for different purposes. Typical computer-based applications of music modeling are:
On the basis of the above list, it can be seen that a music-based software application may use a music model having multiple interpretations and different manipulation mechanisms. In fact, publishers of music scores, composers, musicians, conductors, and computer music analysts, all regard music notation with different interests and use it for different purposes. In general, the elementary operations that can be performed on a music score are: editing, saving, loading, visualizing, executing, coding grabbed sounds, printing, analyzing, etc. In order to provide these capabilities, a specific music model must be defined.
The complexity of the music model needed obviously depends on the application
for which the model is produced.
The music symbols available in professional editors (e.g., Score, Finale, Sibelius, etc. for publishing music are: the basic symbols (notes, rests, beams, etc.), instrumental and execution symbols, (symbols for describing the behavior of the musicians in playing a specific instrument -- e.g., up or down bow, with mute, without the mute, etc.) for: strings, harps, drums, flutes, etc.; orchestral and complete repeat symbols , etc. These symbols, and many others, are needed when main scores and parts for classical music, operas and ballets have to be produced, and absolutely essential when scores are used in music schools to train students to perform specific executions and interpretations. In commercial editors used to prepare music scores for publishing, the number of elementary symbols is close to 300. These are frequently used as components for building more complex symbols. Typically, musicians have to personalize/prepare a score for the execution; thus, even this great number of symbols is not enough to satisfy all needs. For these reasons, some music editors provide a font editor for adding symbols; these, unfortunately, are treated as simple graphic entities.
The organization of many detailed symbols is frequently left to the
user. Typically, music symbols (excluding notes, rests and a few other
symbols) are mainly considered by music editors as graphic elements that
can be placed in any position on a score page without addressing the problems
related to the music notation; e.g., the visual and syntactic relationships
among symbols. Most music editors even allow the placement of several
notation symbols in incorrect positions, resulting in the production of
strange, incorrect music scores. These music editors give no support to
the users. These incorrect music scores cannot be played by musicians,
or correctly interpreted by style analysis algorithms, or correctly used
to generate sound, and are, thus, professionally unusable. In several cases,
only those symbols having a counterpart in the MIDI language are considered.
For these reasons, professional music editors are powerful, but are difficult for non-expert users in music notation to employ. Typically, musicians are capable of reading music, but are not familiar with the exact rules for arranging symbols (e.g., when symbol A is associated with symbol B symbol C has to be moved up one-half unit). On the other hand, musicians have no problem correctly reading a correctly annotated score, but can be perplexed when non-perfect visual constructs are proposed. These musicians are artists, not music engraving and notation technicians. Conductors and composers are frequently more sensitive to problems of music notation and visual expressiveness. Archivists in music theaters, music engravers, and teachers of music notation are the experts to relied on for problems of music notation.
The above-mentioned problems also exist in general languages for storing/coding music. Concerning definition of relationships among symbols, the most flexible and complete languages are NIFF (Notation Interchange File Format) and SMDL (Standard Music Description Languages). Even these languages do not model all the relationships described above and allow placement of symbols in any point in the staff. There are several languages for coding music, as described in SField97 , but unfortunately all of these languages suffer from the same problems.
In order to solve these problems, music notation should be considered a formal visual language in which errors in the placement of symbols are totally unacceptable because they are out of syntax - e.g., Chang87a . Music editors must provide support for the verification of the visual syntax. Moreover, a visual editor has to help the user to easily produce only correct music scores that are based on the visual grammar among symbols. These very important features can be easily obtained if the syntax and the relationships between the notational entities are formally defined. In the case of music, the definition of the visual grammar is a highly complex task that is not yet formalized. However, the existence of a formal model is a great improvement with respect to the state of the art.
To model all relationships of music notation is quite a complex task.
In music, justification involves the placement of symbols both along
the staff and the transversal of the staff, and can be performed on the
basis of several different algorithms. These rules together with those
for the justification of music have not yet been formalized. Several books
have been written to solve this problem, but inconsistencies and incompleteness
Currently, even in very mature music editors, the positioning of music
elements on the score presents many critical conditions. These music editors
should provide a type of auto-correction, as is done for words in modern
Recently, with the diffusion of computer technology into the artistic
fields, new needs for computer-based applications of music have been identified.
In 1994 in our research group in Florence, we began to research about a
network of computer-based music lecterns oriented to musicians. These were
studied for editing/showing music scores by means of a suitable video device,
with the goal of totally removing the paper scores from musician stands
(lecterns). Computerized music lecterns can be used by musicians to avoid
transporting many kilograms of paper music scores, to save their work,
to manage version, control, etc.
In the last three years, these problems have been studied by our research group, focused on the premise that the orchestras could be supported by a set of computer-based lecterns. If the lecterns are connected each other by means of a network, information shared among lecterns can be used to define some new and very interesting applications, such as:
A distributed system with the above features must be capable of showing music in different formats and at the same time must support cooperative work of editing on different formats, showing the changes of one operator to the other in real time. Therefore, a model of music is needed to define and implement algorithms for the automatic:
We started with the definition of an object-oriented model and framework. This was initially used for building music editors for musicians and conductors. The present version is used as a basis for two main projects: