>>This is not a big deal. Actually there are two very different issues with the output >>format.
1) What data belongs in it, and what is the relationship to other data? For instance, a rhythm needs to be associated with a note, because if there are three notes playing at the same time, they could all have different rhythms. However, a bowing mark needs to be associated with the entire vertical set of notes. This is a pretty big issue, and is crucial to get right. This has nothing to do with the physical representation of the data. << How about this as a first approximation: A score consists of': Name Author Tempo A number of systems A system consists of A number of staves A stave consists of Instrument name MIDI patch number Number of lines in stave (normally 5) Size (normal or cue sized) An array of musical objects A musical object consists of Type (Clef, time sig, key sig, chord, text, barline) A clef consists of type (F,G,C, neutral) position (with respect to centre line) A time sig consists of type (normal, C, C/) number on top number on bottom A key sig consists of an array of accidentals An accidental consists of a type (bb,b,n,#,x) and pitch Text consists of Function (chord name, lyric syllable, general text) Text string Barline consists of type (single, double, final, repeat left, right, both) Size (full, half, dotted) Other (such as fermata over) Chord consists of Staccato type (none, staccato, staccatissimo) Accent (none, >, -, fermata, ...) Start to play time (in crotchets from an agreed point) array of notes Beam ID Number of beams (including any stubs) to the left Number of beams to the right Note consists of Rest (true or false) Duration (4,2,1,0.5,0.25... in crotchets) Duration modifier (eg 2/3 for triplets) Number of dots (0,1,2,3) Pitch (octave and name) Accidental (none, bb,b,n,#,x) Stem direction (up, down, none) (In most abc works a chord consists of a single note) How's that for a start? I can see holes in it such as whether chords should have stem direction or notes should. Now converting abc to and from a format like that would be a useful and non-trivial exercise. The midi player can use the parts of relevance, the notation writer can use almost all of the data. >>2) The physical representation of the data. There are a number of issues, including >>extensibility and ease of use in other languages, but in general, I see this as >>easier to deal with. There is no reason why we couldn't support multiple output >>formats. In fact, I could implement the population of the data as a templated class, >>so any C++ programmer could extend it. Perhaps there is a way to take that idea >>further and allow programmers of non-OO languages to create their own formats. << Multiple formats is interesting. Presumably you'd stipulate things like this either with command switches or an initialisation file which the program reads on starup. However for me there is no real contest. Producing ascii allows the programmer to check for errors in the program with greater ease, and allows the format above to grow as development moves from single part music up to full information. And if anyone says that MXML is better than my list then that's fine by me. I have no quarrel at the present time with MXML. I simply don't know enough about it yet. Bernard Hill Braeburn Software To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
