This paper outlines the participation of OMDN at the C@merata task. It is based on CPNView, a container-iterator encapsulation of a score data structure along with associated tools.
Unlike a natural language document, a music score cannot be represented conveniently as a string of around seventy characters. While natural language may be represented effectively using a linear array, a data structure that captures the relationships between entities in a music score does not readily fit into such, or into any of the simpler computing data structures, such as arrays, lists or trees. While all of the relationships between score entities might be successfully captured within a graph structure, the resulting data structure is likely to prove too unwieldy to be of direct use for music information retrieval and analysis. The solution employed here is one of encapsulating this complexity using the familiar container-iterator approach. This enables the underlying complexity to be hidden. The aim is to provide an abstract view of the score through a convenient set of member functions. These member functions are designed to facilitate access to score data in ways that parallel how we might interact with the score document, while keeping the underlying representational complexity secret.
A human reader may wish to access elements in a monophonic score from some starting point, such as from the score beginning or from the start of a section. Adjoining elements might then be visited in time sequence. Traversing polyphonic or homphonic textures gives rise to more diverse approaches to traversing the score. Any information for a score element is available when the element is visited. In the case of a note, this includes pitch and duration information in various formats as well as articulation values. In addition, contextual information such as key signature, time signature, clef and position within the bar is available.
Some queries posed in C@merata are of a very simple nature and could be readily answered without recourse to a good score model. Indeed some of these are answerable by searching through the MusicXML representation. Locating pitches and durations alone or in sequence are examples of such. More advanced queries involve harmonic and key recognition. These occur in questions that require the identification of perfect cadences. Unfortunately all of the five questions for identifying perfect cadences had additional 'mode' tags present. Such information is foreign to a value-neutral score encoding. If such information is used in answering, the solutions will not work on other valid score representations where such additional information is absent or in error. One such instance occurred in the training sample involving a misleading 'mode' entry. Really complex tasks involved distinguishing between monophony, homophony and polyphony. Monophony can have implied harmonies or counterpoint. Distinguishing homophony from first species counterpoint should prove a very interesting challenge of some complexity. Solutions to such tasks are likely to be greatly facilitated by tools that successfully address score representational issues.
Common Practice Notation View, or CPNView was used to answer a subset of the questions in the C@merata challenge[1]. CPNView formed the main topic of a PhD dissertation[2]. The name CPNView was not used in the dissertation, but appeared in in later publications [3][4][5].
The meaning of symbols in a score depends on their preceding context. Examples are note stress and pitch. The emphasis a performer places on a note is influenced by its position in the bar and by the time signature but such contexts may be modified by an attached symbol such as marcato. Another contextual mechanism is employed in pitch representation in which key signature, clef and accidental alterations play a part. In CPNView, the user is freed from the need to keep track of such scoping concerns, as contexts are made available automatically.
CPNView models a score as an objected-oriented container in a manner similar to that used for other data structures found in computer science textbooks. The CPNView model is designed to provide a value-neutral and objective representation of a score from common-practice notation. The score's internal content is available using iterators. The iterator object keeps track of the context in which an object resides in addition to providing access to the score object itself through its member functions. The iterators and their member functions can be viewed as paralleling the actions of a human reader. Typically, a human might access a score from the start an read through it serially. For some purposes the reading may traverse the score along one of the staffs. Where a harmonic or polyphonic texture is of interest it will be desirable to access it as a sequence of vertical slices in time order.
In CPNView the score object may be created by specifying: Score score(path);
This model requires no user knowledge of how the score is represented in a file. CPNView representation is built from a software component that imports from files in a number of different standard encodings.
Access to the internals of the score is facilitated by an iterator object thus:
ScoreIterator cursor(score); or ScoreIterator cursor(score, 1);
The first instance creates an iterator that initially points to the start and can be used to visit all of the objects in a score in time order. Where the score contains multiple staffs, this is an appropriate iterator for harmonic analysis. The second form has an additional parameter and is used to iterate a single staff that has no polyphony, staff number 1 in this case.
In either case the iterator can be made to step through all of the objects in the score using the step member function. The step function returns a value true as long as a succeeding object exists. The following code skeleton makes all objects available, in sequence to any code that replaces the ellipsis.
while ( cursor.step()) {...}
If it is required to visit only the notes in the score, a parameter may be given to the step function as in the following code to count the notes in a score.
long count = 0; while ( cursor.step(NOTE)) {count++;.}
A locate member may be used to place the score iterator in an arbitrary position. For example the iterator may be positioned at the start of bar 20 by means of cursor.locate(BAR, 200);
The ScoreIterator object has a comprehensive range of member functions to retrieve all of the information that is contained within the score.
A natural language query that searches for all of the D notes and prints details of each note arrived at is achieved by while ( cursor.step(NOTE)) if ( cursor.getAlpha() == 'D' )
cout << cursor << “\n”; (1)
In addition to modelling a score, CPNView has a set of
components that facilitate processing musical information. They
include List, Set objects and an object class for calculating pitch
class sets. The pitch class object is based on a modified version of
the classification system of Alan Forte[
A simple approach was used to interpret the natural language queries. For the identification of single notes or rests, the text is parsed and the specified fields are inserted into a search template. This involved using elementary string processing to recognise the notes or rests in order to form the template. Searches were performed in the manner of (1) above. Where such elements were connected by such phrases as “followed by” or “then” the same recognition was performed repeatedly on advancing the score iterator by one note or rest as required.
Files in the C@merata exercise contain unnecessary 'mode' entries and explicit accidentals that do not correspond to entities on the original score. Scholarly score-based research should be based on value-neutral representations that accurately model the symbols on the score and only those symbols. Additionally the representation should have a one-to-one correspondence between encoded entities and visual entities, stripped of layout details. Developers of tools or algorithms that fail to adhere to this approach, will not create solutions that can be guaranteed to work in a wider context. Score representations that have extra unnecessary content present will be required, and the resulting solutions will not work on valid representations that omit such additional unnecessary detail. This is a severe penalty to pay for what might appear initially to make tasks easier to solve. Participating in C@merata involved developing a software component for importing MusicXML files into CPNView. This is a non-trivial task that did not fit the available completion time. Much of the time during the three day limit for completing the assignment was taken up with getting a very basic subset of MusicXML correctly imported into CPNView. As a result only a tiny subset of the task could be completed. The main lacunae arose from (1) no files that had multiple simultaneous notes on the same staff could be processed, (2) queries were limited to identification of notes or rests, (3) time was not available to check the accuracy of the output resulting in some errors and misinterpretations in the submitted answers. However work is continuing on a re-write of the component for importing MusicXML files into CPNView.
Firstly, solving the more complex challenges in this exercise, such as were raised in connection with distinguishing between homophony, monophony and polyphony, will provide us with a new approach that refines our understanding of the issues involved. Fruitful discoveries may be made when comparing algorithmic with manual approaches to such problem solving. This will help us to reveal the tacit assumptions and intuitions involved in solving such problems manually.
Secondly, we suggest the following for any future runs: • The practice of placing additional contextual pitch information on each note should be abandoned. • Information of an interpretative nature should not be included in sources. • All queries should be based on value-neutral representation of music scores. Any additional music information would best be removed, or if this is not acceptable, dual versions of each score might be issued to participants. • The system of indicating locations in scores should be revised so as to include details of line locations and use a more intuitive form based on rational numbers. • A uniform approach should be taken to bar numbering. • Selected queries might be run on multiple or all scores.
[2] Ó Maidin, D.S. 1984. Computer Analysis of Irish and Scottish Jigs. In Musical Grammars and Computer Analysis, ed M. Barone and L. Callegari (Firenze: Leo S. Olschki, 1984), pp.329-336. [4] Ó Maidin, D.S. and Cahill, M. 2001. Score Processing for MIR. In Proceedings of the International Society for Music Information Retrieval, Bloomington, Indiana 2001, pp.5964. [5] Ó Maidin, D.S. 1998. A Geometrical Algorithm for Melodic Difference. In Computing and Musicology II. Melodic Similarity. Concepts, Procedures, and Applications, ed Walter B. Hewlett and Eleanor Selfridge-Field (Cambridge Massachesetts and London, The MIT Press, 1998), pp. 6572.