In message [EMAIL PROTECTED], Paul Rosen
[EMAIL PROTECTED] writes
as you might have read in other posts, I would be very interested in any
work on API for accessing ABC file once parsed. I still did not have a
clue
for creating one and I would welcome any suggestion! Just let me know when
you got an idea.
I would break the problem into two parts: first decide what data needs to be
represented, then figure out the physical layout.
Here's my first shot at a comprehensive description of the data:
Have a header section followed by a repeating field section.
The header section contains:
version - (probably either 1.6 or 2.0 or now)
tune number - int
title - arbitrary length string.
area - arbitrary length string.
book - arbitrary length string
composer - arbitrary length string.
discography - arbitrary length string.
elemskip - arbitrary length string.[What does this do?]
group - arbitrary length string.
history - arbitrary length string.
information - arbitrary length string.
notes - arbitrary length string.
origin - arbitrary length string.
source - arbitrary length string.
transcription notes - arbitrary length string.
rhythm - arbitrary length string.[can this be interpreted in any way?]
default length - double?
meter - double?
String. To include C, C| or ยข or 3+3+2/8 or 4 (which is the
same as 4/1). And don't forget that C| is not always 2/2. It can be
n/2 in musical terms.
tempo - [note length and beats per minute] double? and int
or string. To include allegro etc.
parts - array of bytes
starting key - enum
Going from what to what? Are you including minor keys?
Or is this just a list of accidentals? What about
one-sharp-plus-one-flat (etc)
I would suggest an array of [-2..2]
[I'd suggest the following additional fields that aren't in the spec:
clef, copyright and additional lyrics]
Then the header section is followed by a set of repeating fields of one of
three types.
The types are: note element, bar element, formatting element, and header
element.
the HEADER element is one of:
key (as above)
elemskip [What does this do?]
key (as above)
default length (as above)
meter (as above)
part - byte
tempo (as above)
title (as above)
words [how is this supposed to look?]
The BAR element contains:
bar type - enum (single, repeat left, etc.)
start ending - bit field
ending number - int
end ending - bit field
What about fermata over a barline?
The FORMATTING element is one of:
End of line
break beam
How do you handle principal beams? ie
---
| | | | | |
| | | | | |
| | | | | |
The NOTE element contains:
guitar chord unrecognized - arbitrary length string
guitar chord recognized - root pitch (enum), type (enum), base note (enum)
gracings - enum
bowing - enum
staccato/legato - enum
one or more stacked notes, containing:
grace notes - array of pitches
Distinction between acciaccatura and appoggiatura?
How do you handle chords in grace notes?
pitch - enum [includes an enum for a rest]
length - int
what's the unit here?
start tie - bit field
end tie - bit field
start slur - bit field
end slur - bit field
What's a bit field? Is it just an array of 0..1? If so, I don't
understand how a start tie et al is a bit field.
[I'd also recommend the following extension: an array of syllables to appear
as the lyrics under the note.]
[Also, can we add loudness, fermat, and start crescendo, end
crescendo, fingering, retard, a tempo, etc.?]
Fermat?
What about the articulations: accent (), tenuto, legato, staccato,
staccatissimo, martellato and don't forget these can be at the stem end
and the head end.
---
I think the above is fairly complete.
What about 1st/2nd/3rd time endings for repeats. Coda sections and DC
al fine and such like.
What about the type of binding between staves making systems? ie
brackets, simple line, brace, brace+bracket?
What about arpeggiando marks?
Caesura and commas.
Note size (cue sized, grace notes, normal).
Stave size (cue sized or normal)
Fingerings.
Now, to represent it is tougher to
allow ease of use in all programming languages.
No it's not. Make it strings.
The way I'd represent it without using objects is with a stream of variable
length fields. That is, there would be a series of [type length data]
elements.
The overhead would be:
element type - enum
length - byte on some element types, short on some element types, and not
present for some element types.
data - length bytes of data, interpreted differently for each element type.
The beginning of the structure would contain a 2-byte version number and a
4-byte total length, and possibly a signature.
In addition, we could have an array of indexes into the start of each
element. Perhaps another array of indexes into the start of each note
element, so that a MIDI program wouldn't have to wade through non-sounding
elements.
The bit fields would be combined in a byte when possible.
The enums are a byte.
In the note structure, for each field there is a value that