Method and Apparatus for Representing Musical Information

The present invention relates generally to the field of music processing devices and methods and apparatus for musical transcription and notation. More particularly, the present invention relates to a method and apparatus for representing within a common data structure in the memory means of a computer data processing system musical information that includes both the graphic or visual attributes of the musical information and the related acoustic or sound attributes of the musical information.

Like human language, musical information is comprised of both aural and written components. The written language of music or musical notation has existed for more than eight centuries, but until the advent of the printing press musicians and composers were required to perform the time consuming task of manual notation in order to memoralize their compositions. Even with the printing press, music notation processing has always been a post composition process usually performed by someone other than the composer or musician. With the introduction of computers, special programming languages have been developed to handle the entry and printing of musical notation. These languages generally use a textually-based user interface that requires the user to enter lengthy sets of computer codes in order to generate a single page of musical notation.

In recent years, music transcription systems have been developed for personal computers in an effort to aid the musician and composer in using musical notation. Some of these transcriptions systems have even attempted to take acoustic musical information recorded as electronic messages and turn this information into standard musical notation or sheet music. Unfortunately, the transcription process of these systems is generally a one-way path and there are no provisions for capturing interpretive musical information, or for recreating the musical information as sound based on the stored music data that are transcribed from the original musical information.

While the music processing devices presently available allow a user to print musical information more efficiently than traditional hand engraving of printing plates, they are far from an ideal music processing apparatus. An ideal music processing apparatus should be able to receive the musical information from its native environment (musical sound), represent the musical information in such a way that it may be automatically converted into its written language equivalent (musical notation), present the musical notation to the user so that it may be manipulated or edited, and then output the musical information, either as musical notation or as musical sound, exactly as it has been composed.

Present music processing apparatus cannot simulate an ideal music processing apparatus in large part because of the limitations imposed by the present methods and systems for internally representing musical information in these systems. The internal representation of musical information for a music processing apparatus is a problem that has challenged musicologists for more than twenty-five years with no single or satisfactory solution. Most music processing apparatus use a code-type representation that stores only the specific musical information needed to achieve the limited objectives of the system, i.e., information about pitch alone, about rhythm alone, or about pitch and rhythm without reference to dynamics or articulation. A few music processing apparatus have attempted to develop language-type representations that would enable the user to encode any element of musical information that is present in common musical notation. For example, the DARMS and MUSTRAN encoding languages were developed for mainframe computers. While flexible and more complete than the code-type representations, current music encoding languages are limited to textual-based entry of musical information and are not structured enough to provide a workable method and apparatus for representing musical information that could be used to create a device approaching the ideal music processing apparatus.

The Directory of Computer Assisted Research in Musicology, Center for Computer Assisted Research in the Humanities, 1987, pp. 1-22, identifies five broad classifications that encompass the current methods and systems for representing musical information: music/machine-readable code; music/logic; music/parametric; music/graphic; and music/acoustic. These classifications provide a background for thinking about the various stages of music data representation as the music data move from the input process to the various output processes of display, printing, analysis and sound in a music processing apparatus.

The first classification, music/machine-readable code, covers music processing apparatus that use a code-type representation, usually in the form of an unstructured character string, wherein each character represents, for example, the pitch or duration of the next role to be played in the sequence. The music/logical classification covers those representations that attempt to organize the musical information into logical records and, in this form, more closely represent the logical meaning or structure of the musical information itself. This is the general type of representation that is necessary for developing an ideal music processing apparatus. The next classification, music/parametric, includes all the information of the music/logical representation but presents this data as a list of objects (notes, rests, beams, etc.) whose attributes are determined by specific parameters. Most current music printing programs process their music data in this form. The last two classifications relate primarily to the output of musical information. The music/graphic classification covers representation forms that are closely related to the actual printing or display of the graphic musical information. Examples might include font-lists with X-Y coordinates or strings of redefined ASCII characters that translate directly into music graphics. The music/acoustic classification covers representation forms that are closely related to the actual generation of musical sound. The best known examples is the MIDI (Musical Instrument Digital Information) standard that is currently used by manufacturers of synthesizers and other electronic musical instruments. For a more detailed explanation of the MIDI format, reference is made to Boom, Music Through MIDI, 1987, Chapter 5, pp. 69-94, which is fully incorporated by reference herein.

Although the various music processing apparatus currently available have enabled music publishers to produce higher quality printed music or enabled hobbyists to enter and print simplistic musical notation, none of these systems has a method or device for representing musical information that enables a musician or composer to easily and accurately transcribe complete musical acoustic information into complete musical graphic information and to reverse this process. Accordingly, there is a continuing need for the development of new tools to assist the musician and composer in the transcription of musical information by providing a method and apparatus for representing musical information that will allow the musician or composer to enter, manipulate and retrieve both the graphic and acoustic attributes of musical information from a common data structure in the memory means of a computer data processing system, whereby changes to one type of information may be automatically reflected in changes to the other type of information.

In accordance with the present invention a method and apparatus for representing musical information are provided, utilizing a programmable data processing means having storage means for representing both acoustic and graphic musical information in a common data structure and input/output means operably connected to the data processing means for entering, editing and retrieving the musical information.

The method for electronically processing and storing musical information involves separating the musical information into a plurality of segments, each representing some portion of a measure, and assigning a sequential time dimension value to each segment and measure. The musical information is also separated into a plurality of channels, with each channel representing a sound source (e.g. an instrument) and having a sound dimension value assigned to it. The musical information for a given channel and segment is stored in a memory array by associating the musical information corresponding to a given channel and segment with the memory array node specified by the time dimension value and sound dimension value assigned to the given channel and measure in which the segment appears.

The method for representing musical information of the present invention may further comprise the steps of identifying a plurality of entries that represent certain rhythmic, melodic, and interpretive aspects of the musical information, with each entry comprising one unit of music data selectively representing a rest, a note or a chord. A set of details comprising further acoustic or graphic features of a rest, note or chord may be associated with the entry. Successive entries for a given instrument or sound source are linked together. The linked entries are then assigned to locations in the memory array by defining a first pointer to the successive entries for a given instrument or sound source to designate the first entry to be included in a measure and defining a last pointer to the successive entries for the given instrument or sound source to designate the last entry to be included in the measure.

A primary objective of the present invention is to provide a method and apparatus for representing musical information that will approach an ideal music processing apparatus.

Another primary objective of the present invention is to represented musical information in a music processing method and apparatus in a manner such that the musical information may be organized according to the rules of musical notation and interpretation as seen and heard by musicians.

An additional objective of the present invention is to provide a method and apparatus for storing music data specifying a composition in a form that readily permits either the output of graphic music notation or acoustic performance.

Another objective of the present invention is to provide a method and apparatus for storing musical at a in which the data structure used for storage permits easy access for editing the composition and facilitates automatic changing of graphic elements of music notation when acoustic information is changed and vice versa.

Another objective of the present invention is to provide a method and apparatus for storing music data in which essentially all forms of graphical symbols and text used in musical notation may be stored with a clear relationship to the corresponding acoustic information.

A further objective of the present invention is to provide a multi-dimensional data structure or memory array in which the music/logic relationship between notes, chords and rests and various interpretive markings is clearly represented.

A still further objective of the present invention is to provide a data structure for music data in which most data is expressed in a common format and pitch, duration and graphic location are all expressed as relative representations for easy transformation.

These and other objectives of the present invention will become apparent with reference to the drawings, the description of the preferred embodiment and the appended claims.

FIG. 1 is a diagram of a music processing apparatus in accordance with the present invention including an electronic instrument keyboard, a MIDI interface, and a programmable data processing means including an alphanumeric keyboard, a pointing device and a graphic display screen.

FIG. 2 is an overall block diagram of a Music Framework for representing musical information in a music processing apparatus in accordance with the present invention, including the Enigma Format of the present invention.

FIG. 3 is a block diagram of the Entry Pool of the present invention showing the relationships among Entries (note, rests, and chords) stored in the Music Framework.

FIG. 4 is a block diagram of the preferred embodiment of the Entry Pool showing the Entries in a two dimensional double link list arrangement for a simple six-entry Entry Pool.

FIG. 5 is a block diagram of the Relative Representation of measured music data in the present invention showing Tone Center Displacement for representing the pitch value of Entries and vertical graphic placement of a note on a staff as this information is stored together in the Music Framework.

FIG. 6 is a block diagram for the Frame Assignment method showing music data assigned to specific instruments and measures on the Music Framework.

FIG. 7 is a notational representation of the Music Framework showing selected measures of a sample composition associated with nodes in the Music Framework.

FIG. 8 is a block diagram of the Music Framework showing the relationship among various elements for the sample composition shown in FIG. 7.

FIGS. 9a and 9b are block diagrams showing the input and output of music data to the music processing apparatus of the present invention.

FIG. 10 is a depiction of a computer screen showing a Framework Dialog Box for interfacing with the Music Framework.

FIG. 11 is a block diagram showing the format of a transportable version of the music data represented in the Music Framework.

FIG. 12 is a block diagram of a Data Structure intensive Model showing the relationship among the various data structure groups used by the Music Framework.

To understand the nature and scope of the present invention, it is first necessary to define the various types of information that comprise the musical information to be represented by the present invention. The present invention represents all of the musical information for a composition within a common data structure in the storage means of a computer data processing system. The logical relationships that are represented within this common data structure allow changes in one type of musical information to be reflected in all other types of musical information as needed. The various "types" of musical information that are represented within this one common data structure arise out of the natural representations of both graphic (visual) musical information and acoustic (sound) musical information and the logical relationships between the graphic and acoustic musical information (e.g., pitch expressed in terms of frequency and pitch expressed in terms of placement of a note on a staff), as well as the interrelationships among the natural representations of either graphic or acoustic musical information (e.g., duration as affected by a tie or pitch as affected by a slur). Briefly, the types of graphic and acoustic information that are represented in the common data structure used in the present invention are: melodic information, rhythmic information, interpretive information, and textual information.

As with languages, music is a way for humans to formulate, understand, manipulate and communicate information. Accordingly, the various representations of musical information are not dictated as much by the laws and limitations of nature as they are by the conventions and rules of musicians. The present invention attempts to understand and replicate the various interrelationships, conventions and rules that govern the way musicians see and hear music, rather than imposing a new set of rules and standards for how to represent music in a manner that is most convenient for a computer. In this way, the present invention should be viewed as extensible and able to adapt to new interpretations and methods of how humans represent music. The various types of information that are represented by the present invention are not meant to limit human imagination in creating new ways of representing or understanding musical information. Instead, the present invention encourages looking at musical information in a new light and allows for non-traditional methods of representing that information, for example twentieth century notation.

Though the present invention is not limited by any arbitrary division of the types of musical information that are represented in its common data structure, it is helpful to define the types of musical information that will be discussed. Melodic information refers primarily to both the pitch and absolute duration of the individual notes entered by the musician or composer. Pitch refers to the tonal properties of a sound that are determined by the frequencies of the sound waves that produce the individual note. In classical western musical notation, pitch is denoted with reference to a series of half-step intervals that are arranged together in octaves; each octave comprising 12 half-steps or notes. For purpose of defining melodic information as used in this invention, note duration is the length of time a particular note is played. Note duration is sometimes thought of as the relative time value of a given note, e.g., whole note, half note, quarter note, eighth note. For purposes of this invention, however, note duration in terms of melodic information refers only to the absolute time value of a given note, i.e., absolute note duration. It is necessary to distinguish between relative and absolute time value of a note, because relative time value can only be correctly resolved when the proper beat unit is known, i.e., a half note played at 160 beats per minute should be notated differently than a quarter note played at 80 beats per minute, even though both notes will have the same absolute time value.

Rhythmic information, on the other hand, refers to everything pertaining to the time and emphasis aspects of multiple notes as distinct from their melodic aspects. It includes the effects of beats, accents, measures, grouping of notes into beats, grouping of beats into measures and grouping of measures into phrases. For purposes of the present invention, four distinct components comprise the rhythmic information necessary to easily and accurately transcribe music into musical notation: (1) relative note duration--this is the length of time a note is played in terms of the time signature for the measure; i.e., half note, quarter note; (2) beat unit--the base unit of time used to measure the tempo of a piece of music; (3) measure--the organization of beat units into groups corresponding to the time signature of the composition or section of a composition; and (4) accent--the designation of particular emphasized beat units or notes within a measure. The function and importance of rhythmic information or the "beat" relates to the fact that the human ear seems to demand the perceptible presence of a unit of time that can be felt as grouping the individual notes together. In classical western notation, the beat unit and the relation between beat units and measures are designated by the tempo marking, e.g., 120 beats per minute, and the time signature, e.g., 3/4, where the top number indicates the number of beat units per measure (in this case 3) and the bottom number designates the type of note in which the beat units will be measured, i.e., the note value that will receive one beat unit (in this case a quarter note). Though sometimes referred to as the beat, for purposes of this invention, an accent will define which notes, beat unit(s), or sub-divisions of beat units in a measure or group of measures are to receive accentuation or emphasis.

Interpretive information refers to the characteristic sounds that are imparted to a piece of music when it is played with the expressions and feelings of a particular performer. Interpretive marks such as crescendos, staccatos, ritards, as well as information relating to tempo, other dynamics, and even settings for modulation wheels on electronic instruments. Interpretive information relates to the manner in which a particular performer will interpret a given piece of music.

Textual information refers to the language information that is associated with a given piece of musical information. This includes not only lyrics, but also title, related notes and other textual information, such as headers and footers, that are not included in the interpretive information.

While musical information may sometimes be referred to throughout this invention according to these four types, it should be understood that these categories are somewhat arbitrary and are used to convey an understanding of the overall concepts embodied in the invention. For example, some of the interpretive information might be just as easily referred to as textual information or rhythmic information, depending upon the usage and context of the musical information. The fundamental concept behind the present invention is that the musical information represented in a music processing apparatus be organized according to the rules of musical notation and interpretation as seen and heard by musicians.

Referring now to FIG. 1, the functional relationship among selected elements of the music processing apparatus of the present invention can be seen. The music processing apparatus 10 is comprised of a programmable data processing means 12 operably connected to associated input/output means, including an alphanumeric keyboard 16, a pointing device 18, a graphic display screen 20, an instrument means 22 with associated interface means 24, and a printer 26. The preferred programmable data processing means 12 of the present invention is a digital microcomputer having memory means (not shown) for representing the musical information in a common data structure as described hereinafter. In one preferred embodiment, the data processing means 12 is an Apple Macintosh SE computer available from Apple Computer, Inc. 20525 Mariani Avenue, Cupertino, Calif. 95014. The instrument means 22 shown in the preferred embodiment is an electronic keyboard, a DX-7 synthesizer available from Yamaha International Corporation, P.O. Box 6600, Buena Park, Calif. 90622. It will be seen, however, that any instrument equipped with an interface means 24 for encoding the musical information as MIDI or other machine-readable data would be capable of providing musical information to the music processing apparatus 10. It should also be noted that data processing means 12 may include the interface means 24 within the components included in the computer housing. In the preferred embodiment, the Apple Macintosh SE is equipped with an Apple MIDI interface unit and a Laser Writer printer, also available from Apple Computer, Inc. The functioning of the data processing means 12 is controlled by means of control information in the form of a software program that stores and retrieves data utilizing the common data structure described hereinafter. Those skilled in the art will recognize that various software functions utilizing the common data structure could be programmed in a variety of ways or could also be accomplished by equivalent hardware.

The music processing apparatus 10 may be used by a musician or composer to enter, retrieve, edit, analyze and output musical information. In order to accomplish these tasks, the musical information must be stored in a machine-readable format so that it may be processed by the data processing means 12. For purposes of the present invention, musical information represented in this manner will be referred to as music data. The common data structure that the music processing apparatus 10 uses to represent music data in the memory means of the data processing means 12 is a new way of storing musical information in a machine-readable format such that the graphic aspects of the music data are related to the acoustic aspects of the music data in a music/logical type of representation. By accommodating both the graphic and acoustic aspects of the music data as related elements in a common data structure, changes to the graphic information can be automatically reflected in changes to the acoustic information, and vice versa. The common data structure allows the present invention to overcome the problems inherent in the prior art where the graphic and acoustic representations of music data are treated as separate and distinct pieces of information. The particular structure and organization of the common data structure also allow the present invention to overcome the problems inherent in the current systems that attempt to utilize a music/logical type of representation of musical information.

Unlike the prior art, the present invention does not define a specific coding scheme for representing each of the four types of musical information. Instead, a common data structure, a logical array called the Music Framework, is established in which elements of music data for any of the four types of musical information listed above may be represented. Moreover, these elements of music data are preferably represented in the logical array with the same basic format for each element, the Enigma Format. By using the same basic format or various types of music data and storing all of the music data in a common data structure, the storage and manipulation of the music data is simplified and the overall performance of the music processing apparatus is improved.

To further utilize the flexibility and other advantages of the common data structure (the Music Framework) and the basic format for storing music data (the Enigma Format) the present invention also provides for several novel methods and structures for representing the music data within the Music Framework. These begin with the way in which individual music data values are represented and extend to how groups of music data are placed in the Music Framework. First, although the Music Framework provides a method for relating instruments (or other sound sources) and measures (or portions of measures) in time, there is also a need to provide a time relationship among the notes, chord, and rests that are the heart of the music data for each measure. Because musicians and composers tend to create music data in a non-linear fashion, in the present invention the core of the music data (i.e., the notes, chords, and rests) is stored in a flexible, sequentially linked organization, the Entry Pool, that allows for easy insertion, deletion, or modification of the music data. Next, because certain types of music data are physical measured values (e.g., pitch, duration, position) that a musician may wish to systematically modify, as by transposition, rearrangement, or resizing, the present invention chooses to represent the individual value for any type of measured music data as a relative value expressed in terms of an offset or displacement from a user-selected or default absolute value, or expressed in terms of relative units multiplied by a base resolution value. This Relative Representation method allows for quicker manipulations and additional flexibility in representing the individual measured values of the music data, particularly for representation of pitch values by the Tone Center Displacement method. Finally, because composers often use the same music data in different measures and for different instruments, the present invention facilitates this reuse or tieing together of music data by using a Frame Assignment method to associate individual measures of music data for a particular instrument with nodes or intersection points in the Music Framework. This method also leads to certain storage and processing efficiencies in the music processing apparatus 10.

As shown in FIG. 2, all of the music data in the common data structure is organized within a Music Framework 30, a multi-dimensional array having Time 32 as its first dimension and Sound 34 as its second dimension. The Music Framework 30 is a kind of time-based organizational chart in which the method and apparatus of the invention places all the various types of musical information the music processing apparatus 10 must manage. Conceptually, the musical information is connected to the various Framework Intersections 36 created by the intersection of discrete values of the two dimensions, Time 32 and Sound 34, of the Music Framework 30. All of the music data represented in the memory means of the data processing means 12 is organized according to a music data hierarchy defined in association with the Music Framework 30. The hierarchical categories of music data represented in the Music Framework 30 include: Page-Related Data 40, Instrument-Related Data 42, and Measure-Related Data 44 represented in the Framework Margin 35, and Frame-Related Data 46 and Entry-Related Data 48 represented at the Framework Intersections 36.

Page-Related Data 40 includes all information about any specific page of a composition, including the dimensions of the page size, the page margins, and the system margins of any staff system that appears on the page. Also included in this category of music data are page, staff system, and individual staff reduction or enlargement parameters. Page-specific text blocks, arbitrary music, and headers and footers also are contained in the Page-Related Data 40 category.

Instrument-Related Data 42 is the musical information that is unique to a particular instrument or sound source (including a voice). This includes the name of the instrument, its transposition, and starting clef. In the Music Framework 30, when an instrument is assigned to a particular staff in a composition it is referenced by an instrument ID number. An unassigned instrument slot is simply a blank staff that is part of a staff system, but has not yet been assigned any frame records.

Measure-Related Data 44 is the information related to each measure in the composition. For purposes of the present invention, the term "measure" applies to the particular measure number common to the music played by all of the instruments in the score during a specified time period. Included in this category is time dilation information, score expression information, repeat information, measure attribute information, measure number information, and key signature and time signature information.

Frame-Related Data 46 is very much like Measure-Related Data 44. The difference between Frame-Related Data 46 and Measure-Related Data 44 is that the term measure is used to refer to specific measure for all instruments up and down the sound dimension of the Music Framework 30. By contrast, the term frame refers to just one measure or one portion of a measure for a particular instrument identified with a single Framework Intersection 36. Many of the Measure-Related Data 44 types of information, such as key and time signatures, are more easily thought of as frame-specific, because they may be varied among different instruments of the same measure. In the Music Framework 30, such data may be represented in either or both categories. For example, data relating to the basic key signature of a measure may be stored in the Measure-Related Data 44, and data for a special key signature for a particular instrument for that measure could also be stored in the Frame-Related Data 46. The Frame-Related Data 46 category includes data that are exclusively related to one frame, as opposed to a group of frames on different instruments. It includes MIDI expression information captured from a live performance, measure specific text blocks, and measure specific arbitrary music.

Entry-Related Data 48 refers to the most basic elements in a composition. An entry may be either a note, a rest, or a chord. The music data that comprises the Entry-Related Data 48 represents the vast majority of the musical information to be processed by the music processing apparatus 10. Stored in the Entry-Related Data 48 is the rhythmic and melodic information for the entry, including the duration of the entry and the number of notes contained in that entry. Also stored here are attributes that are peripheral pieces of information attached to the entry. These may be lyrics, chords, staff expressions, or grace role definitions. A subset of Entry-Related Data 48 contains the displacement and accidental amount of the note, as well as tie information and key velocity information. A more complete definition of all the types of attributes found in the Entry-Related Data 48 category is provided in the explanation of the Entry Pool below.

FIG. 2 also shows the Enigma Format 50 that is the basic field format by which virtually all of the music data is stored in the memory means of the data processing means 12. The Enigma Format 50 is used to represent music data of all five of the hierarchical levels of music data and allows the data processing means 12 to break the musical information down into discrete segments of music data. Each segment of music data can be thought of as a data element that represents some definable portion of the musical information that has certain characteristics and attributes, as well as defined relationships with other data elements. The advantages of the Enigma Format 50 is that it does not limit what those data elements must be, nor does it limit how two or more data elements will be related to one another. Instead, the Enigma Format 50 provides a common basis for defining what each data element will represent and how that data element will relate to other data elements. In this sense, the Enigma Format 50 is truly extensible because a musician is not limited to the current way of defining or interrelating segments of music data and new ways of defining or interrelating music data elements may be easily and quickly incorporated into the common data structure for the music processing apparatus 10.

For each data element that is defined in the Music Framework 30 of data processing means 10, the Enigma Format 50 for that data element is comprised of three fields: a comparator 52, a tag 54, and an associated data field 56. The tag 54 is a code that identifies the type of data element. Each unique code to the tag 54 defines a unique type of data element, what the data element represents, and how the data element will relate to other data elements. For example, a `MS` tag identifies the data element as a Measure Specification tag having a defined data field associated with it. The particular combination of a comparator 52, a unique tage 54, and a defined data field 56 will be referred to hereinafter as a tag structure. The tag structure for a `MS` tag is based on this data element role as a part of the Measure-Related Data 44 and might include, for example, data defining the height and width of the measure when it is displayed on the graphic display 20 or printed on the printer 26. The comparator 52 is a numeric value that identifies how this data element is related sequentially to other data elements having the same type of tag 54. For example, a `2` comparator for a `MS` tag identifies the particular data element as the Measure Specification data element for the second measure of a particular composition. The data field 56 is a fixed-length packet of data whose content depends on the type of tag structure. For example, the data field 56 for an note may contain bit-mapped information that defines how to position a note on the staff, or for an element of Instrument-Related Data 44 it may contain ASCII codes representing the name of an instrument for a staff.

In the preferred embodiment of the Enigma Format 50, the comparator 52 may occupy two bytes of four bytes. The comparator 52 may be either a sixteen bit number with a maximum value of 65,535, or may be divided a 32 bit number divided into two 16 bit numbers each with a maximum value of 65,535. The tag 54 is a two character ASCII code. The length of the data field 56 is fixed, its length depending upon the tag structure identified by the two character tag 54.

Because the bulk of the music data represented by the music processing apparatus 10 is comprised of Entry-Related Data 48 that must be accessed quickly and efficiently, the present invention uses a unique method and structure by storing the rhythmic and melodic music data associated with entries (notes, rests or chords). As shown in FIG. 3, the Entry-Related Data 48 is represented on the Music Framework 30 as an Entry Pool 60 comprised of rows of Entry Streams 62, 64, 66 and 68, each row made up of a plurality of Entry Elements 70. The Entry Streams 62, 64, 66 and 68 represent a sequential, time-based linking of the Entry Elements 70 that correspond to the Instrument-Related Data 42 for that row. These Entry Streams 62, 64, 66 and 68 are independent of one another. The Entry Pool 60 makes no stipulations on the concurrency or sequentially of the Entry Elements 70 as they are physically represented in the memory means of the data processing means 12. The key to understanding the structure of the Entry Pool 60 is that each Entry Element 70 in the Entry Stream 62 is linked to the next sequential Entry Element 70, as well as to any Entry Elements that belong to the same time interval, e.g., the individual notes of a chord. By using the sequential linking concept of the Entry Pool 60, the music processing apparatus 10 is able to represent the Entry-Related Data 48 as a series of threads or streams of entries that do not need to be stored in an exact physically sequential arrangement in the memory means of the data processing means 12.

In the preferred embodiment the structural foundation of the Entry Pool 60 is a two dimensional double link list. The two dimensional double link list structure for the Entry Pool 60 solves the problem of requiring an absolute identifier to access the Entry-Related Data 48. Because double link list data structures do not rely on physical sequentially for data access, this type of structure is well suited to the non-linear quick access requirements for real-time entry and manipulation of music data. Once an Entry Element 70 is defined as beginning at a certain offset, it need not shift physically in the memory means due to array manipulations because the double link list array manipulations do not move data, but merely rearrange links. Because only the links are manipulated during edits, the double link list provides a flexible structure in an interactive environment that meets the requirements for real-time entry and manipulation of music data. While a two dimensional double link list is described as the preferred embodiment for the Entry Pool 60 of the present invention, it should be recognized that other types of data structures permitting expression of sequential relationships may also be used to achieve similar sequential linked access to the Entry-Related Data 48 and are intended to be within the scope of the present invention.

Referring now to FIG. 4, the preferred embodiment of a two dimensional double link list structure for a single Entry Stream 62 of the Entry Pool 60 will be described. The first dimension is a time dimension (horizontal in FIG. 4) and the second dimension is a sound packing dimension (vertical in FIG. 4). The time dimension delineates the time relationship among sequential Entry Elements 70 in the Entry Stream 62. The sound packing dimension delineates the sound relationship among Entry Elements 70 in the Entry Stream 62 that occur during or start at the beginning of the same time period. The time dimension allows the Entry Element 70 to be sequentially linked to the Entry Stream 62. The sound packing dimension allows two or more Entry Elements 70 to be grouped together to form, for example, a chord.

In the example shown in FIG. 4, the individual Entry Elements 70 each have an associated Entry Number 71 (represented in the shaded ovals as Entry Nos. 1-5 and 8), although the Entry Number 71 is not actually a part of the data stored for the Entry Element 70. The Entry Number 71 is used to physically locate the Entry Element 70 in terms of a displacement or offset from a base value that represents the beginning of the Entry Pool 60 in the memory means of the data processing means 12. As described in conjunction with the section entitled Data Structure Intensive Model, the Entry Number 71 is also used as a comparator value to identify other tag structures that contain additional Entry-Related Data 48 that must be associated with the particular Entry Element 70 identified by the Entry Number 71.

The shaded rectangle in the top portion of FIG. 4 shows the data fields that are defined for each Entry Element 70, in this case by Entry No. 2. In essence, the Entry Pool 60 is comprised of an array of Entry Elements 70 that are each 32 byte elements containing these data fields. In the preferred programming language `C`, the data fields of the array consist of the following declared structure:

The first four data fields defined in an the array (Last 72, Next 73, Up 74, and Down 75) are four byte values used to implement the preferred embodiment of the two dimensional double link list structure of the Entry Pool 60. Last 72 and Next 73 define the previous and succeeding Entry Elements 70. Up 74 and Down 75 provide for the construction of multiple notes or chords in the same time segment. Each of these variables contains the value of an Entry Number 71. By pointing to the next linked Element 70 in this manner, the Entry Elements 70 do not need to be stored contiguously in the memory means.

The two byte data field Duration 76 holds the relative duration of the entry in terms of relative duration units. For example, a quarter note might be represented as "1024", meaning 1024 relative duration units. The two byte data field Position 77 holds the relative positional displacement value of the x origin of graphic representation of the entry from the start of the measure. Each Entry 70 is graphically represented as a specified figure (e.g. quarter note, half rest) displayed or printed with respect to an horizontal origin for that Entry 70. The displacement value is specified in terms of virtual page horizontal units. Only the relative horizontal position of an Entry 70 need be specified, as the vertical position will be calculated by the positioning of the Entry 70 on the staff as defined by the Tone Center Displacement method, described hereinafter in the section entitled Relative Representation.

The four byte data field Effect 78 primarily controls the graphic attributes of the Entry Element 70. The four byte data field Notation 79 primarily controls the acoustic attributes of the Entry Element 70. Both Effect 78 and Notation 79 are bit mapped with each data bit defined to indicate a particular attribute of Entry-Related Data 48 associated with that entry. The definitions for each of the data bits for Effect 78 and Notation 79 are set forth hereinafter in the section entitled Data Structure Intensive Model.

Any music data value that is a physically measured value (e.g., pitch, duration, position) is represented in the music processing apparatus 10 in terms of a Relative Representation method by specifying the measured value as a user-defined or default base value plus an offset or displacement (e.g., horizontal origin plus offset), or by specifying the measured value in terms of relative units multiplied by a base resolution value (e.g., 3200 relative duration units per second times the relative duration value), or by a combination of both. The Relative Representation method makes the manipulation of measured music data more flexibly available for the composer. For example, if a composer wanted to copy and transpose one frame of music data from one instrument to another, Relative Representation of the pitch information allows the transformation to be performed very simply by changing the base value. The Relative Representation method also makes the measured music data much easier to manipulate for the data processing means 12. For example, resizing a page of printed score is easily accomplished if the music data relating to page position of the entries is stored as relative virtual horizontal and relative virtual vertical units having a user or system definable relation to actual size.

The representation of the pitch of a note has been a tricky problem for music processing apparatus. One particular problem, for instance, is the correct handling of transposed instruments and key signature changes. The present invention solves the problem of pitch representation through a unique method called Tone Center Displacement, as shown in FIG. 5. Using the Tone Center Displacement method, the pitch and accidental of each note are related back to the key signature, which is related back to an absolute frequency called the Harmonic Reference 80. This allows for the pitch of all notes to be expressed relative to a Tone Center 81, as opposed to being a fixed frequency value or key letter. The advantage is that if any part of the hierarchy is changed, the pitch information "under" the change will automatically adjust accordingly without any recomputation whatsoever. Transposition becomes instantaneous with guaranteed accuracy.

Harmonic Reference 80 and Tone Center 81 have to do with the key signature. Tone Center Displacement 82 and Accidental Amount 83 have to do with the relationship of a note to the key signature (or tone center) in diatonic steps and accidentals. Harmonic Reference 80 is a movable zero point, best thought of as the "middle C" of all key signatures. All key signatures are related to this point, instead of being fixed independently of each other. Tone Center 81 is the tonic, or center, of the key signature, and is almost always the same as the key signature (E is the tone center of E minor). The Tone Center 81 is related to the Harmonic Reference 80 by a number of diatonic steps and an alteration amount. For example, if the harmonic reference were "C" (the default), a tone center of "D" would be represented by a diatonic step amount of 1 since that tone center is one diatonic step away from "C". An Alteration Amount (not shown) is used to signify non-diatonic step deviations from the diatonic displacement. The tone center of "A-flat" is 5 diatonic steps from "C" with an alteration amount of -1, which accounts for the flat and differentiates it from the tone centers of "A" and "A-sharp". Tone Center Displacement 82 is the distance of a note, in diatonic steps, from the tone center. A "B" in the key of D major would have a displacement value of 5 (5 diatonic steps away, or a major sixth). Accidental Amount 83 is the amount of accidental on a note. Like the alteration amount for the tone center, it is used to represent non-diatonic step differences from the displacement value. In general, an accidental amount of 1 equals 1 sharp, 2 equals 2 sharps, -1 equals 1 flat, -2 equals 2 flats, and 0 equals a natural. A "B-flat" in the key of F would have a displacement of 3 and an accidental amount of -1, while a "B-double sharp" would have a displacement of 3 and an accidental amount of 2.

Representing music data using the Tone Center Displacement method greatly simplies transposition, both for acoustic and graphic representation of the music data. Because all note pitches ae related to a Tone Center 81, changing the Tone Center 81 (i.e., the key signature) automatically results in correct transposition of all notes. Additionally, because only one value is being changed, transposition becomes almost instantaneous. For example, a key signature (or tone center) of E-flat is represented by a diatonic displacement of 2 (2 steps from middle C) and an alteration amount of -1 (to account for the flat). The note G-flat in this key signature would be represented by a displacement amount of 2 (2 diatonic steps from the tonal center) and an accidental amount of -1 (to account for the flat). If the user changed the key signature to G major (a displacement from middle C of 4 and an alteration of 0), the pitch of the note is now 2 diatonic steps from G major with an accidental amount of -1, resulting in the note B-flat, which is the correct transposition.

It should be noted that the Tone Center Displacement method is not tied to a seven diatonic step scale, such as is common in Western music. The transition to quarter tone or eighth tone scale can be made fairly easily. Furthermore, the accidental amounts are relative distances, meaning that, although a value of 1 usually stands for a sharp, the user may reconfigure the key format so that 1 may stand for a quarter-sharp, 2 a sharp, 3 a three-quarter sharp, etc. As a result, Tone Center Displacement provides a very flexible, musically-intuitive system for these type of linear key formats.

The Tone Center Displacement method is also useful in conjunction with the Relative Representation method for positioning music data, for example, when printing or displaying a staff system with the associated musical notation. The horizontal position of an Entry Element 70 on a virtual page is determined by the horizontal (x) components of the position of page, Page Adjustment 85, and the position of the staff system on the page, Staff System Adjustment 86. Then the position of the particular frame on the particular staff, Frame Origin 87 is added to the horizontal position of the particular Entry Element 70 within that frame as defined by Position 77. Consequently, the horizontal position of an Entry 70 in relative positional units on a virtual page is calculated as: x=Position 77+Frame Origin 87+Staff System Adjustment 86+Page Adjustment 85. The vertical position of an Entry Element 70 on a virtual page is determined by the vertical (y) components of the position of page, Page Adjustment 85, and the position of the staff system on the page, Staff System Adjustment 86. Any adjustment to the size of the staff, Staff Adjustment 88 or adjustment to the clef, Clef Adjustment 89, is determined. Finally, the note is placed in its proper position on the staff by using the Tone Center Displacement method. Consequently, the vertical position of an Entry 70 in relative positional units on a virtual page is calculated as: y=Tone Center 81+Tone Center Displacement 82+Harmonic Reference 80+Clef Adjustment 89+Staff Adjustment 88+Staff System Adjustment 86+Page Adjustment 85.

Referring now to FIGS. 2 and 6, the Frame Assigment method will be described. The Frame-Related Data 46 is represented on the Music Framework 30 by an Assignment Record 90 and at least one associated Frame Record 92 for each frame for which there is Entry-Related Data 48. The relationship between the Assignment Records 90 and the Frame Records 92 provides the link between the Music Framework 30 and the individual Entries 70 in the Entry Pool 60. For each Framework Intersection 36 that has Entry-Related Data 48 associated with it, an Assignment Record 90 is created. Conversely, if there is no music data associated with a particular Framework Intersection 36, then no Assignment Record 90 is created and no music data is stored for that frame.

In the preferred embodiment, each Assignment Record 90 contains a Frame Number 91 that points to a Frame Record 92. The Frame Record 92 contains a Start Entry 93 and an Stop Entry 94 variables that together define the beginning and end of a segment of the Entry Pool 60. All of the Entries 70 with Entry Numbers 71 between the values for Start Entry 93 and Stop Entry 94 are in the frame that is assigned to the particular Framework Intersection associated with the Assignment Record 90.

The Assignment Record 90 is stored in the Enigma Format 50 and is comprised of a comparator 52 split into an instrument comparator 96 and a measure comparator 97, a tag 54 defined as `GF` (short for graphics file assignment record) and a data field 56 containing at least a Frame Number 91 of a Frame Record 92 that will point to the music data that is to be associated with the particular Framework Intersection 36. By referencing the Frame Record 92, instead of incorporating either the music data itself or pointers directly to the music data, the Assignment Record 90 allows for maximum flexibility and optimization of the music data contained in the Music Framework 30.

In the preferred embodiment, the data field 56 for the `GF` tag is defined as a four word data array having the following structure when programmed in the preferred programming language, `C`:

One of the software routines that is used to implement the Frame Assignment method is called `dt2serch()`. It is passed the two comparators 96 and 97, a tag, `GF`, and an incidence number. If the routine is passed an incidence number of four, it will search through the tag structures for the Entry-Related Data 48 looking for the fourth instance of a record which matches the comparators and tag. An example of this routine in `C` is as follows:

The routine is passed an instrument number and a measure number. It calls dt2serch() to fetch the base address of the data array element of the record which has the comparators equal to the instrument number and the measure number and a tag of `GF`. If dt2serch () returns greater than zero, an Assignment Record 90 exists for the particular Framework Intersection 36.

Because each Entry Stream 62 in the Entry Pool 60 is continuous as a result of the sequential links, some mechanism is needed to break an Entry Stream into smaller pieces without imposing an artificial hierarchy on the Entry Pool 60l The Frame Record 90 accomplishes this by holding in its data a starting entry number, Start Entry 93, and an ending entry number, Stop Entry 94. These two numbers `frame` a piece of a stream in the Entry Pool. As can be deduced, it is easily possible that two frames will overlap or that one frame might enclose another. Although there are no stipulations on the interweaving of frames, by convention the frame which encompasses the largest portion of the overlap is referred to as the `original`. The other frames are `mirrors`. There is no duplication of the material in a mirrored frame. It is simply another way of viewing the original material.

It will be seen that there are many advantages to representing musical information as a series of Assignment Records 90 pointing to music data and associated with Framework Intersections 36 in the manner described. First, because the Music Framework 30 and the Assignment Records 90 are not storing the musical information, but only pointing to it, the parameters of the Music Framework 30 are not fixed by the limitations of the particular computer 16 that the software program may be running on. The Music Framework 30 may have as many instruments or measures as a composer desires. Second, because the Music Framework 30 does not store any information when there is no musical information for a particular instrument for a particular measure, there is no need to represent whole rests in a musical composition stored in accordance with the method and apparatus of the present invention. Consequently, a significant amount of computer memory is conserved by not using a whole rest or other type of place-marker to signify the absence of musical information for a particular measure and instrument. The software program places a whole rest in the output for a particular instrument and measure on the Music Framework 30 if there were no Assignment Records 90 that had a matching instrument comparator 96 and measure comparator 97. Finally, it will be seen that retrieval of the musical information using the method and apparatus of the present invention is not limited to a sequential or serial system for accessing the music data. This allows for random access to the musical information, as well as increased performance in accessing the information, including allowing for the hocketing or mirroring of music data as will be discussed below.

An additional advantage of representing the musical information as Assignment Records 90 is that multiple Assignment Records 122 may be assigned to the same framework intersection 36 on the Music Framework 30 by storing multiple Assignment Records 90 having the same instrument comparator 94 and measure comparator 95. Concepturally, this may be though of as adding a third dimension to the Music Framework 30 for separating the musical information into multiple renditions of a particular segment as played by a particular instument. There may be several variations of interpretive information that could be stored for a given measure for a trumpet solo and even small variations in the notes themselves, i.e. grace notes, but the musical notation for that measure might be the same. In other words, the way that Louis Armstrong played the first measure of solo could have different interpretive, rhythmic and melodic information than the same measure as played by Doc Severensen, even though both were reading the same sheet music. The method and apparatus of the present invention allows both renditions of the same measure to be stored together in a common data structure, thereby allowing, for example, the playback of the first eight measures of a song using Louis Armstrong's style and then switching to Doc Severensen's version of the last sixteen measures. Using the Assignment Record 90 of the preferred embodiment, the musical information for multiple renditions of a given measure and instrument is easily accommodated by having multiple Assignment Records 90 with the same instrument comparator 94 and measure comparator 95, but with different Frame Numbers 91.

Referring now to FIGS. 2, 7 and 8, the Music Framework 30, Enigma Format 50, and Entry Pool 60 and the Frame Assignment method of the present invention will be described in operation in terms of a sample composition 100. FIG. 7 shows the sixteen measures of the sample composition as they would be logically placed on the Music Framework 30. FIG. 8 shows a block diagram conceptural representation of the sample composition 100 as stored in the Music Framework 30. The Page-Related Data 40 consists of the title of the composition and any other pertinent page information, such as page layout, etc. The Instument-Related Data 42 consists of the music data for the four instruments used in the sample composition, First Trumpet 102, Second Trumpet 104, Snare Drum 106, and Piano 108. The Measure-Related Data 44 includes all of the music data relating to the four measures of the sample composition 100 that are shown, i.e. key signature 110, time signature 112. Finally, the Frame-Related Data 46 and the Entry-Related Data 48 hold the majority of the musical information presented in the sample composition 100. It will be seen that the placement of all five categories of music data on the Music Framework 30 allows for a logical organization of the musical information that provides for an efficient access to the musical information.

A couple of interesting aspects of the musical information conveyed by the sample composition 100 shown in FIG. 8 should be noted. In Measure 3, for example, all of the instruments except the Snare Drum 106 have no music data to be played for that measure, i.e. each measure is a whole rest. The Music Framework 30 represent such whole rests as the absence of an Assignment Record 90 of that Framework Intersection. Often times, a composer will want more than one instrument to play essentially the same musical information, or will want the musical information in a frame to be repeated by the same instrument. In music terms this correspondence between frames of music data, either for the same instrument (horizontal) or for different instruments (vertical), is sometimes referred to as hocketing or mirroring. Examples of vertical hocketing are shown at First and Second Trumpet, Measures 1 and 2. An example of horiztonal hocketing is shown in Meaures 1 and 2 of the Snare Drum. If a composer wants a second frame in a composition to be identical to a first frame, the same musical information for that frame is repeated in the composition. To maintain this identity if the musical information in the first frame should change, the information in the second frame should also change. The Music Framework 30 allows for mirroring or hocketing to be used by the composer, or by the program itself, to make the most use of the musical information.

The use of pointers within the common data structure of the present invention allows for maximum flexibility and optimization in representing the musical information. For example, at Measures 3 and 4 of the Snare Drum, it will be seen that the last pointer of the Frame Record 92 for Measure 3 overlaps the first pointer for the Frame Record 92 for Measure 4. By examining the sample composition in FIG. 7, it will be apparent that the last note in Measure 3 is, in fact, the identical note as the first note in Measure 4. By representing the music data in this manner, computer storage can be conserved and the composer is given ultimate control over all of the music data in a composition so that he or she may identify any entry, or group of entries, in an entire composition and copy that entry, or group of entries to another location in the composition.

Referring now to FIGS. 9a and 9b, the method and apparatus of the present invention is explained in terms of how music data is placed in and retrieved from the common data structure. For purposes of this explanation, it will be assumed that the music data to be processed is MIDI data from a keyboard instrument 22 and MIDI interface 24, although it will be clear that other forms of electronically coded acoustic or graphic music data may be used as input. Briefly, when music data comes into the music processing apparatus 10 in the form of a MIDI data file 105, it is transcribed into a node file 152 that contains all of the melodic, rhythmic, and interpretive information associated with the MIDI data file 150. At this point, either the user enters user-selected values 154 for Page-Related Data 40, Instrument-Related Data 42 and Measure-Related Data 44 data elements (e.g., time signature, key signature, instrument list), or the music processing apparatus 10 uses prescribed default values 156 for the data elements for these categories of music data as stored in the Music Framework 30. Next, the measured music data is translated into relative data values and stored in a temporary file 158. For example, the melodic data (which is in absolute pitch value) is translated into relative pitch values using the Tone Center Displacement method and the rhythmic data (which is absolute duration values) is translated into relative durational values. The interpretive data and other non-measured values for the rhytmic and melodic data are translated into the appropriate tag structures and also stored in a temporary file 160. The result is a sequential file of Entries 70 (temporary file 158) and associated tag structures (temporary file 160) that are not yet differential into measures or organized into the format of the Music Framework 30 and Entry Pool 60 as shown in FIGS. 3 and 4, although the tag structures that have been generated in the Enigma Format 50 will now permit the differentiation and organization of the music data to occur. Finally, the Frame-Related Data 46 and the Entry-Related Data 48, including the Entry Stream 62, the Assignment Records 90, and the Frame Records 92 are generated by examining the Entries 70 for each channel of music data and identifying the starting and ending points for each frame. A more detailed explanation of the transcription process is presented in the related application entitled, METHOD AND SYTEM FOR TRANSCRIBING MUSICAL INFORMATION INCLUDING METHOD AND SYSTEM FOR ENTERING RHYTHMIC INFORMATION, filed in the United States Patent Office on Jan. 14, 1988 and identified by Ser. No. 143,861, a copy of which is attached as Appendix A and incorporated herein by reference.

Outputting music data from the common data structure is, to a certain extent, the reverse of the input process. First, all of the music data on the Frame Margin 35 of the Music Framework 30 is collected in a temporary file, including the Page-Related Data 40, Instrument-Related Data 42 and Measure-Related Data 44. Using the music data in the temporary file 160, the music data in the Entry Pool 60 is sequentially added to the temporary file 160 measure by measure, starting with the smallest instrument number. Finally, a transformation 162 of the music data is performed to output the music data either as graphic data 164 to the graphic display screen 20 or the printer 26, or as acoustic data 166 to the electronic keyboard 22 or to an external speaker 28 in the data processing means 12. When a graphic output is intended, all of the music data is converted into pixels with coordinates on a virtual master score that includes all instruments and measures. This master score is then partitioned into pages of an appropriate size either for printing or screen display. When acoustic output is intended, the music data is converted to electronic signals corresponding to notes of the specified frequencies, duration, and volume with the specified relationship to adjacent notes. The acoustic data 166 may drive either an instrument with sound reproducing capability or an external speaker.

The preceding are typical input/output applications for which the method and apparatus of the present invention may be used. In the next sections, two specific methods of accessing the common data structure of the present invention will be described: the Framework Dialog Box and the Enigma Transportable File. The former is a user interface that permits a user to view and specify many of the music data values, primarily Entry-Related Data values, that are stored in the common data structure. The latter represents an article of manufacture that is produced by the present invention as another potential form of output whereby all of the music data in the Music Framework 30 may be transported from one music processing apparatus 10 to another without losing any of the music data or any of the information about its structure in the Music Framework 30.

Referring now to FIG. 10, a Framework Dialog Box 180 is shown as one of the preferred ways of allowing the user direct access to the Entry Element 70 data structure in the hierarchy of data structures outlined above. With the music processing apparatus 10 operating on the data processing means 12, the user would select the screen display of the Framework Dialog Box 180 by using either the keyboard 24 or the mouse 26 to designate a particular Framework Intersection 36 to be examined. The Framework Dialog Box 180 gives relevant information about the Entry Elements 70 for that Framework Intersection 36 (as identified by an Assignment Record 90), as well as the ability to alter the music data relating to those Entry Elements 70. All of the information displayed in the Framework Dialog Box is for one Entry Element 70, although the rest of the Entry Elements 70 may also be accessed by using Prev Entry or Next Entry buttons as described below. Each of the action items on the computer screen for the Framework Dialog Box 180 is described as follows:

Frame is the Frame Number 91 of the Frame Record 92. This identification number has not so much to do with the frame's position in the score as it does the order in which it was created. A new frame is allocated each time one is needed to hold new information (i.e. new entries). This happens when the user adds additional music data to the score or when the user copies or replaces segments of the score from one location to another.

Start and End are the numbers of Start Entry 93 and Stop Entry 94 that point to the Entry Elements 70 in Entry Pool 60 associated with the Frame Record 92.

eEntry Number is the number of the current Entry Element 70, relative to the order in which it was drawn from the Entry Pool 60.

Entry Slot refers to the position of the current entry in the Framework Dialog Box 180. A value of 0 indicates that the current entry is the first entry for this Frame Record 92. Greater values indicate subsequent entries.

Duration is the duration of the current entry in relative units.

Position is the horizontal positioning offset of the current entry, relative to its normal position. This number is also in relative units.

OK will return the user to the score, saving any changes he or she has made.

Cancel will return the user to the score, cancelling any changes.

Prev Entry and Next Entry switch the display to the previous and next entry slot for this Frame Record 92.

Create creates a new entry before the current one. All values will be set to the default values. If the user wants to the new entry to be a note, instead of a rest, he or she must also create a new note as explained below.

Delete deletes the current entry.

Prev Note and Next Note move the display to the next note slot on that entry. Create creates a new note before the current one. All values will be set to the default (0 in all cases).

Delete deletes the current note.

The 32 selection boxes under entry slot 182 represent 32 bits that are part of the data structure for each Entry Element 70. Selecting or deselecting these boxes will after the appearance and functionality of that particular entry, removing or adding "detail" as the options indicate. In many cases, deselecting a selected box will permanently remove that type of detail from that entry, and that particular type will need to be re-entered.

Legality means that this entry is part of the data in the current Frame Record 92. The last entry slot for a Frame Record 92 always has legality turned off. Turning legality off on any entry will establish that entry as the end of the current frame--clicking OK will result in any entries after this entry being removed.

Note/Rest when turned on, dictates that this entry is a note, as opposed to a rest.

V2 Launch marks this entry as the start of a string of voice two entries (although this entry is still a voice one). All subsequent notes will be treated as voice two entries until an entry with the Voice Two bit turned off is reached.

Voice Two signifies that the current entry is a Voice 2 entry.

Chord is turned on if there is a Chord Symbol linked to the entry. Turning this bit off will permanently unlink the chord symbol from the entry.

Clef Change is used for multiple clefs in the Frame Record 92. The program uses it in redrawing the screen to determine where clef changes fall.

Float Rest dictates that this entry, if it is a rest, should float to the pitch of the middle line. If left off, the height of the rest will be determined by the displacement value in Note Slot 0.

Grace dictates that this note is a grace note.

Note Detail means that there is some type of note specific detail attached to this entry. This includes all adjustments made with by the user on the computer screen 18 and any reduction or enlargements made to the notes on this entry. Deselecting this bit will permanently unlink any such detail from this entry.

Mark Detail determines if there are Expression markings associated with the current entry (Note Expressions or Staff Expressions). Deselecting this bit will permanently unlink any such detail from this entry.

Text Detail determines if there are lyrics associated with the current entry. Deselecting this bit will permanently unlink any such detail from this entry.

Tuplet is used to link the current entry to a tuplet definition. Deselecting this bit will permanently unlink any such detail from this entry.

V2 Tup Para is for the special case where a tuplet definition is attached to a series of voice two entries within a tuplet definition on a voice one entry. If the user desires that the temporal spacing of the voice two tuplet be relative to the spacing of the voice one tuplet, this bit must be set on the voice two note that is linked to the voice two tuplet definition.

Ignore makes the current entry invisible. It is used when doing a Horizontal Hocket, and the current entry is not selected for display. It is also used for split measures. The measure is actually drawn in both staves except the ending notes (after the split point) are invisified in the top stave and the beginning notes (before the split point) are invisified in the bottom stave. In a normal measure, selecting this bit will simply "invisify" that entry. All subsequent entries will be drawn in their normal place, but ignored notes will not sound in playback.

Beam Ext dictates that beam extension detail is attached to this entry. Deselecting this entry will permanently unlink any detail from the entry.

Beam/Beat determines where the beams will break. If this bit is left off, and this entry and one before it have a duration of an eighth note or less, the two entries will be beamed together. This bit also affects playback. If this bit is selected, the entry will have a slightly harder attack.

Sec Beam dictates that there is Secondary Beam Break information tied to this entry.

V2 Beam allows voice two entries that are not launched off the same voice one entry to be beamed together. If this entry is an eighth note or shorter, and the last voice two note launched off of the previous voice one entry is an eighth note or shorter, and the Beam/Beat bit is deselected on the current entry and this bit is selected, the two entries will be beamed together.

Freeze Stem allows you to freeze the stem up or down. It works in conjunction with the Up/Down 402 box next to it in the dialog box.

Stem Detail dictates that there is a stem detail linked to this entry. Deselecting this bit will permanently unlink any detail attached to this entry.

Cross Up dictates that there is cross staff beaming detail attached to this entry.

Cross Down is used to indicate that there was cross staff detail linking part of the current entry to the staff below the current frame.

Reverse Up indicates that the entry has a reverse upstem.

Reverse Dn indicates that the entry has a reverse downstem.

Double Stem indicates that the current entry is double-stemmed.

Split Stem indicates that the current contains a split stem. The Upstem Split box in the Note Slot section may be set in conjunction with this bit.

Up/Down determines the direction of the stem if the Freeze Stem bit is also set. If selected, the stem direction will be frozen up, otherwise, it will be frozen down.

Note Slot refers to the different notes and their details that lie resident on each entry. An entry may have up to sixteen notes.

Note ID is a number used to reference the note in that particular note slot. The number here denotes the order in which the notes were entered. Changing this number after the note has been entered has little effect on the note in that slot.

Displacement is the distance of that particular note from the Tone Center 82 in diatonic steps.

Raise/Lower is the Accidental Amount 88 distance of that note from the diatonic displacement.

Legality is similar to Legality in the entry slot. If turned on, it signifies that the current note is part of the current entry. If turned off, it signifies that this note marks the end of the notes on that entry.

Tie Start denotes that the start of a tie is present on that note.

Tie End denotes that the end of a tie is present on that note. This will only graphically appear if the current entry occurs at the beginning of a new staff system or a new page. In playback, the current note will not sound if this bit is set.

Cross Note signifies that this note is displayed in another instrument, and is used in conjunction with Cross Up in the entry slot.

Upstem 2nd if set and the entry has an upstem, will result in the current note being placed on the opposite (right) side of the stem.

Dnstem 2nd if set and the entry has a downstem, will result in the current note being placed on the opposite (left) side of the stem.

Upstem Split is used in conjunction with the Split Stem bit in the entry slot. It signifies that the current note is "split" to the upstem, as opposed to the downstem.

Accidental determines if the Accidental Amount 88 is displayed on the note or not. If set, the accidental will appear.

Referring to FIG. 11, a block diagram showing the format for a transportable data file 190 embodying the common data structure of the present invention is shown. To preverse the music data in a format that can be most easily reconstructed into the common data structure of the present invention, the transportable data file 190 stores the music data essentially according to the Data Structure Intensive model of the Music Framework as discussed below. In the preferred embodiment, the transportable data file is stored as ASCII and hexadecimal codes with the music data for the different groups of tag structures separated by header records that identify the current group of tag structures. The headers are: Others Header 191, Details Header 192, Entries Header 193, Text Header 194 and Lyrics Header 195. Each header is followed by the ASCII and hexadecimal codes associated with the music data for the particular tag structures or other variable under those headers.

A listing of the Enigma Transportable file 190 generated by the preferred embodiment of the present invention for the sample composition 100 shown in FIG. 7 is attached hereto as Exhibit B and is fully incorporated herein by reference.

The software program and common data structure that control the functioning of data processing means 12 may be further explained based on two alternative conceptual models: (1) an Algorithmic Intensive Model, and (2) a Data Structure Intensive Model. The Algorithmic Intensive Model views the software as a collection of routines or "communities" that are executed according to the entry points, subroutine calls and return points specified within their code. Each community is dedicated accomplishing a specified task. For example, the Playback Community is responsible for assembling a performance from the musical data for audio playback. A community receives or has access to certain musical information contained in various data structures and will pass back selected information to the overall program when the community has accomplished its specified task. Using the Algorithmic Intensive Model, the software is viewed as control means for executing a series of specific music data processing functions, each function operating on musical information stored in a common data structure.

The Data Structure Intensive Model views the software as establishing a set of data structure groups. Each data structure group is responsible for storing selected, related parts of the musical information, for example the relative time duration of all notes. Some data structure groups are more oriented toward acoustic data; others are more oriented toward graphic data. The data structure groups are extensively interlaced by various links with other data structures. These links can be viewed as information requests and/or execution path instructions, because a link to another type of data may require a subroutine call to handle that type of data. Using the Data Structure Intensive Model, the software program is viewed as defining a set of data structure groups, each with a collection of routines to service that group. These routines are then conceptually grouped by manager or supervisory routines that store, link, and provide access to common or interrelated types of musical information.

The software for the music processing system 10 of the present invention can be thought of as four communities: Transcription, Graphics, Playback, and Editing. Each community can be thought of as a group of software routines that performs a specific function. Each Community breaks into smaller groups of software subroutines known as Districts. Some Districts break down further into sub-subroutines called Townships. Some Townships break down further into sub-subroutines called Blocks.

The Transcription Community is responsible for the conversion of mass music data input that specifies a composition into useable data for the Graphics Community. A master note file would be the normal input to the Transcription Community. The Transciption Community takes this note file and converts it into Graphic File Records. The Graphics Community is responsible for assembling a visual score from the musical data. Responding to certain information found in the data, the Graphics Community selects execution paths. During the execution of these paths a score is created. The Playback Community is responsible for assembling a performance from the musical data. Responding to information found in the data, the Playback Community creates a playback list and calls a routine to output the information to a playback channel. The Editing Community is responsible for manipulating the musical data in accordance with the user's desires. After the manipulation is complete, the supervisory program could call the Graphics Community to update the visual score of the edited composition or the Playback Community to perform the composition as changed by editing.

The Transcription Community breaks into four districts:

The Transfer District is responsible for packing an internal data structure with a measure's worth of information. It is the Transcription Community District which deals with the outside world. Two hardware specific routines called getkey() and putkey() provide the interface.

The Filter District is responsible for arranging the music data for the Krunch District. It insures that the notes are in the Protocol Note File Format and performs any necessary data manipulation including quantization.

The Krunch District converts the sanitized data into a Graphic File Record. In the process it performs duration analysis, harmonic analysis, stem assignment and harmonic rest assignment.

The Record District places the Graphic File Record into mass storage. The actual destination of the record is program dependant.

The Filter District breaks into three Townships:

The Protocol Township insures that the music data is in the correct protocol. It is called at the beginning and the end of the Filter District.

The Justify Township justifies the left and right edges of note groupings. It also checks for quick succession of notes with small durations and small overlaps. It eliminates these overlaps. The Justify Township breaks into three Blocks: Right Justify, Overlaps and Long Durations.

The Resolve Township quantizes the music data with the resolution (time base) set by the user. The Resolve Township breaks into two Blocks: Resolve Start and Resolve End.

The Krunch District breaks into four Townships:

The Duration Analysis Township sweeps through the music data and compiles entries. It assigns these entries Primary Voice and Secondary Voice status. It interleaves any necessary rests. The Duration Analysis Township breaks into four Blocks: Next Rest, Entry Grouping, Voice Assignment and Entry Log.

The Harmonic Assignment Township takes the new entries and the current key signature and assigns harmonic content to the notes. The Harmonic Assignment Township breaks into two Blocks: Harmonic Level Assignment and Seconds Status Assignment.

The Stem Assignment Township sweeps through the entires and assigns stem directions.

The Rest Harmonic Assignment Township sweeps the entries and assigns harmonic content to the rests.

The Graphics Community is unique in that three governors or supervisory routines rule this community. The Score Governor, The Part Governor and the POSTSCRIPT Governor. Each of these can rule the Graphics Community for it own type of output. The Graphics Community breaks into three districts:

The Page District is responsible for driving a page of music to the output device. The Stave District is responsible for a stave of music to the output device. The Measure District is responsible for driving a measure of music to the output device.

The Page District breaks into four Townships:

The Stave Township is the same as the Stave District. This township is elevated to the level of a district, because it can serve as an alternate entry point for the Graphics Community.

The Page Text Township prepares for output any text blocks assigned to the page.

The Arbitrary Page Music Township prepares for output any arbitrary music assigned to the page.

The Header Township prepares for output any headers for the page. The Header Township breaks into two Blocks: Global Headers and Local Headers.

The Stave District breaks into eight Townships:

The Staff Creation Township draws the stave system to the output device. The Staff Creation Township breaks into three Blocks: Draw Staff, Draw Bracket, Draw instrument Name.

The Measure Allocation Township determines the number of measures to pack on the present line.

The Signature Township draws the time and key signatures for the piece as needed. The Signature Township breaks into two Blocks: Key and Time.

The Dynamic Township draws dynamics to the output device. The Dynamic Township breaks into two Blocks: Text Dynamics and Object Dynamics.

The Repeat Township draws repeats to the output device. The Repeat Township breaks into three Blocks: Bar Repeats, Bar Endings and Text Repeats.

The Measure Number Township draws measure numbers to the output device.

The Measure Township is the same as the Measure District. This township is elevated to the level of a district, because it can serve as an alternate entry point for the Graphics Community.

The Measure Text Township outputs any text blocks assigned to the measure.

The Arbitrary Measure Music Township outputs any arbitrary music assigned to the measure.

The Barline Township draws barlines to the output device.

The Measure District breaks into three Townships:

The Beam Township draws beam groups to the output device. The Beam Township breaks into three Blocks: Beam Calculation, Entry Drawing and Beam Drawing.

The Entry Township draws entries to the output device. It is the same as the Entry Drawing Block under the Beam Township however it is an alternate entry point in the Measure District. The Entry Township breaks into nine Blocks: Clef Change, Interpretive Mark, Entry Dynamic, Lyric, Rest, Chord, Note, Stem and Accidental.

The Grace Township drives the Beam and Entry Townships to create grace notes.

The Playback Community breaks into four districts:

The Interpretive Mark District is responsible for altering the start times, end times and amplitudes of notes through interpretive marks.

The Dynamic District is responsible for deciphering the dynamics and logging them in the output stream.

The Grafile District converts the frame record into acoustic data and logs it in the output stream.

The Repeat District tracks the progress of playback through the measures of the piece and redirects flow as necessary.

The Edit Community provides access to and the ability to change all elements of the music data that a composer would desire to change. It is analogous to a word processor for word-oriented text, but must be able to handle all the data in the common file structure set forth above.

A simplified block diagram of the interrelationships among the primary data groups that are stored in the common data structure of the Music Framework 30 is shown in FIG. 12. The primary data groups represent a conceptual scheme for bringing together data that are either functionally related for purposes of computer processing or conceptually related in the mind of a composer-user of the present system or both. Related data elements having the same comparator structure for their tag structure are stored together in one of the data groups in the memory means of the data processing means 12 and operated on by common software routines. Though the various categories of music data, i.e. Page-Related Data 40, Entry-Related Data 48, are each represented in district tag structures, the music processing apparatus 10 stores certain of the tag structures together in these data groups so that they may be accessed and manipulated more easily.

The common data structure for the Music Framework 30 may be viewed as comprising several data groups: The Global Group 200, the Entries Group 210, the Detail Group 220, the Text Group 230 and the Other Group 240. In the preferred embodiment of the present invention, the data structure for the Music Framework 30 is defined by declaration statements in the preferred programming language C, and each of the declaration statements for each of the data groups includes declarations for all of the tag structures that will be associated with that particular data group. An extensive and detailed explanation for each of the tag structures, as well as the relationship between the tag structures and the data groups and the tag structures and the software routines is set forth in Appendix C, entitled "Discussion of the Enigma Data Structures", which is fully incorporated herein by reference. Appendix C provides specific programmer-level information on the preferred embodiment of the present invention.

Briefly, the Global Group 200 contains the data that should be available as a common resource for all of the remaining data groups. Because the present invention is designed to store music data in a form that is both transportable and extensible, there are many composition-wide defaults and control values that may be assigned by the user. Some of these defaults and control values are stored in the Global Group 200 and are available to all of the remaining data groups. Data elements in the Global Group 200. Some of the global variable are not expressed in the Enigma Format. They are programming language variables that are globally defined.

The Entries Group 210 contains the actual individual units of music data or Entry Elements 70. These are identified by the Enigma format tag "eE" in the Enigma Transportable File 190. An entry contains the basic melodic and rhythmic information necessary to represent the individual unit of music data. An entry also contains the interpretive information needed for stylistic variations in graphically representing the individual unit of music data, such as stem direction, type of beaming and voice status.

The majority of the music data for an Entry Element 70 is stored in the bit-mapped data fields Effect 78 and Notation 79. The bit maps for both Effect 78 and Duration 79 are set forth below in hexadecimal format. For each bit field identified, a brief description of the function of the bit field is provided. The parenthetical references in the description are to the tag structure definitions that are set forth in Appendix C.

The Detail Group 220 operates primarily with the Entry Elements 70 and the Assignment Records 90. As discussed in more detail later, the Assignment Records 90 are used to place Frame-Related Data 46 at particular Framework Nodes 36 of the Music Framework 30. A great deal of additional music data may be associated with each of the Entry Elements 70 by using a variety of tag structures shown in the Detail Tags 124 to handle, for example, the modification of stems and beams, alteration of size of entries, assignment of interpretive marks, assignment of interpretive text, construction of tuplets, assignment of lyrics, construction of chord symbols, assignment of records to particular instruments and measures, assignment of text blocks to measures, control of floating key and time signatures, and assignment of arbitrary music to measures, among other things. In short, the Detail Group 220 contains the tag structures that handle all of the complex details associated with the musical information. The tag structures defined for the Detail group 220 are listed by tag 54, structure name as identified in Appendix C, and a brief description of the function of the tag:

The Text Group 230 is a data structure that may store either of two types of textual information: lyrics or text blocks. Lyrics are strings of characters that are linked to individual entries that will be displayed along with the entries when the musical information is graphical displayed. Text blocks are all other types of textual information that may appear on a piece of sheet music, but do not convey musical information. For example, the composer's name, the title of the composition, or a copyright notice.

All other data not encompassed by the Global Group 200, the Entries Group 210, the Detail Group 220, or the Text Group 230 are found in the Other Group 240. The Other Group 140 is a data structure that controls the layout of the music information and the assignment of repeats, dynamics, arbitrary music format and placement, headers, text blocks, measure numbers, shape definitions and alternate key and time signature formatting. The Other Group 240 includes the tag structures that define music data for the time and sound dimensions of the Music Framework 30, in the form of the Instrument Usage `IU` tag structure and the Measure Specification `MS` tag structure. The tag structures defined for the Other Group 240 are also listed by tag 54, structure name as identified in Appendix C, and a brief description of the function of the tag:

The tag structures of the Detail Group 220 and Other Group 240 are both defined to provide for representation of most of the visual and acoustic attributes that might be associated with the musical information at the note, rest and chord-level that will be processed by the music processing apparatus 10. However, the flexibility and extensibility of the Enigma Format 50 allow for any number of additional tag structures to be defined to accommodate any visual or acoustic musical information that a composer or musician might want to have represented in a music processing apparatus. When the Enigma Format 50 is combined with the Music Framework 30, the Entry Pool 60 and the Relative Representation and Frame Assignment methods, the present invention is capable of representing musical information in a method and apparatus that approaches an ideal music processing apparatus.

Although the description of the preferred embodiment has been quite specific, it is contemplated that various changes could be made without deviating from the spirit of the present invention. Accordingly, it is intended that the scope of the present invention be dictated by the appended claims rather than by the description of the preferred embodiment. ##SPC1## ##SPC2##