First of all, I was working from the 1.6 document, I probably should have
been using a newer one. I noticed that
http://www.gre.ac.uk/%7Ec.walshaw/abc/abc-draft.txt contains some
interesting stuff. Is that the latest that has generally been agreed upon?
> > elemskip - arbitrary length string.[What does this do?]
>
> It's a hangover from abc2mtex. I don't think it's meaningful to any
> other program.
We could either carry it forward, knowing that no one will use it, but some
will be confused by it, or we can deprecate it. Or we can define it so that
it is useful.
> > rhythm - arbitrary length string.[can this be interpreted in any way?]
>
> Yes. Several programs (BarFly, abcMus, abc2midi) use it to invoke a
> stress
> program when playing. However, it's probably best to leave it as a
> string
> here and let the controlling program interpret it.
If there is a set of acceptable words, I'd think it is in our interest to
put them in the standard as "preferred", while allowing any arbitrary
string. Then playback programs would know which rhythms to emulate. I'd
suggest this:
rhythm-enum: enum of common rhythm markings (apps are encouraged to support
these)
rhythm-other: arbitrary string.(apps don't need to worry about these other
than printing the string)
> > default length - double?
>
> Since the default length can have only a limited number of values an
> int or
> enum would probably be more appropriate?
I was thinking that if we define the duration in a particular way that the
length would use the same units. (see below)
> > meter - double?
>
> No. As you point out below you are going to want to deal with the
> distinction
> between C and 4/4, and at some point deal with complex time signatures
> like 2+2+2+3/8.
> In BarFly I opted for representing it as two integers, representing C
> and C| by
> making the numerator negative, but it's a kludge and I have no sensible
> way of
> extending it to deal with complex metres. It needs some serious
> thought.
I'm not familiar enough with the odd meters to know what they are supposed
to look like when printed. And do playback programs need to be aware of
them?
> > tempo - [note length and beats per minute] double? and int
> > parts - array of bytes
> > starting key - enum
>
> That enum's definition is going to be very large to deal with all
> possibilities.
> It would probably be worth breaking this down into several fields, e.g.
>
> tonic
> mode
> globalaccidentals
> keysignature (an array of seven enums, each of which can represent #,
> b, natural or null?)
OK.
I'd add double-sharp and double-flat to the keysignature array, too.
> There's also some additional stuff which can go in the K: field:
>
> middle
> transpose
> capo
I guess transpose and capo are really flavors of the same thing, which is to
make the playback program play notes other than what's written, and put a
note on notation programs.
What does "middle" do?
> > [I'd suggest the following additional fields that aren't in the spec:
> > "clef", "copyright" and "additional lyrics"]
I found "clef" and "lyrics" are well supported by the document in the link
above, so cancel that and add them to the structure.
I'd still support a specific "copyright" notice.
> > Now, the first thing that I would do is write a C++ class that accepts
> > that
> > structure as input, and puts it into collections, with lots of access
> > functions. We could simulate that with C, where we write a set of
> > functions
> > like:
> >
> > GetNote(struct theData* pData, int iNoteNumber, struct aNote* pNote);
>
> Personally, I'd rather work directly with the data, rather than use
> access
> functions. It's possible that this would pose problems for some
> languages
> though.
I'm a little surprised, but that's ok, the data structure is there. With
variable length fields I'd find it easier to encapsulate finding the data.
> I wouldn't worry too much about overhead, since modern computers have
> vast
> amounts of memory to play with. Much better to plan for the future
> (e.g.
> by including blocks of unused space reserved for future use) than to
> strive
> to keep it as compact as possible.
With the variable length fields that are started by a type-byte, we have
that without adding blank space. We need a clear rule for the length of a
field so that unrecognized ones can be ignored. Perhaps all fields can be
defined the same, that is:
Byte 0: Type (enum of all the field types)
Byte 1-2: length of this field
Byte 3..n: field data
> > The thing that has always puzzled me about ABC is all the header
> > fields. As
> > far as I can tell, not all programs treat the headers the same, and
> > some
> > ignore some of them. Is there a recommended place that each of the
> > header
> > text fields should go?
>
> Apart from X: and K: they can go in any order. What I do in BarFly is
> rather than parsing the header from top to bottom I seek for the fields
> that I actually need, ignoring everything else.
I didn't state that clearly, and two out of two people misunderstood.
Whoops! I meant, where the header fields go on the printed music. In other
words, is there anything that says that "Composer" should go on the top
right hand corner of the music instead of underneath the music? If I put
vital info in the "History" field, will all programs display it somewhere?
---
I just thought of something. Should we make the strings Unicode, or have
some mechanism for other alphabets? Perhaps that needs to be a switch passed
to the parser, or a field in the returned structure or something.
---
> >tempo - [note length and beats per minute] double? and int
>
> or string. To include "allegro" etc.
Just like with the rhythm field, we could create different formats of this
depending on what we find in the tune. Then we would interpret it as best we
can without disallowing anything we can't interpret.
tempo-exact: note length (int), beats per minute (int)
tempo-enum: enum of "allegro" and all those other Italian words.
tempo-other: arbitrary length string.
> >starting key - enum
>
> Going from what to what? Are you including minor keys?
I said "starting" to differentiate it from key changes later on, that's all.
I was including minor keys, but it looks like there are infinite keys, so we
need to expand this.
> >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?
I didn't know it was possible, but, OK.
> >The FORMATTING element is one of:
> >End of line
> >break beam
>
> How do you handle principal beams? ie
>
> -------------------
> -------- --------
> | | | | | |
> | | | | | |
> | | | | | |
I didn't, but I didn't think ABC did either. For completeness, it would be
nice to specify, in case ABC version 3.0 handles it, but that is starting to
make my head hurt.
> >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?
I'm afraid that question is beyond my musical depth.
> How do you handle chords in grace notes?
I didn't think it was possible. If there are multiple notes stacked, then
each one can have an independant set of grace notes.
> > 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.
Sorry about the terminology. I meant that those items can only have the
value "true" or "false". They can be represented by a byte that only
contains 0 or 1, or they can be represented by a particular bit that is
packed with other short fields. It doesn't matter conceptually. It does
matter if particular languages don't support bit fields.
I was thinking that what is important in a tie or a slur is what note it
starts on and what note it ends on. The app would interpret a slur over
three notes like this:
Process note 1. Notice that the "start slur" bit is ON. Remember that.
Process note 2. Notice that the "end slur" bit is OFF. Keep looking.
Process note 3: Notice that the "end slur" bit is ON. Now we have the info
to draw the slur from note 1 to note 3.
This also allows a slur to start and stop on the same note.
> 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.
OK.
> >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.
1st/2nd endings are in the BAR object.
Coda and "DC al fine" and anything else you can think of like that should
probably also be in the bar object.
> What about the type of binding between staves making systems? ie
> brackets, simple line, brace, brace+bracket?
I didn't see anything in ABC that allowed multiple staves, so I didn't
address that, although it bugged me. If we allow multiple staves we should
allow a comment to appear before them, like having four staves marked
"violin" "violin" "viola" "cello".
> What about arpeggiando marks?
>
> Caesura and commas.
Out of my depth, again, I'm afraid.
> Note size (cue sized, grace notes, normal).
I guess that note shape, like using diamonds and x, also. I guess that
should optionally be part of each note, and the default should be in the
header.
> Stave size (cue sized or normal)
Hmmm... I don't understand this one.
> Fingerings.
I had suggested that under the note section. I don't think ABC supports it,
but it would be nice to have.
> >I suggest the following for indicating note length: Let's pick a small
value
> >that is the shortest note length we support: perhaps a triplet of 1/64th
> >notes. That would be indicated by 1. Then internally every length is a
> >multiple of that.
>
> That couldn't express a simple 64th note. It's 1.5 triplet 64ths.
>
> iirc Midi uses 1/9600 of quarter note which is a fairly good idea since
> it handles quintuplets perfectly. A better one is to use a multiple of
> all the prime numbers up to about 29.
I like the MIDI solution. All reasonable lengths fit in 16 bits.
> But imo the best alternative is a pair of integers representing the
> ratio from a given, such as a whole note. Eg 1,4 [=1/4] for a quarter or
> triplets of 64th notes would be 2/192 (2/3 x 1/64) or of course 1/96 or
> a triple-dotted quarter note would be 1/4*15/8 = 15/32.
>
> This formulation might leave room for the distinction between a dotted
> 89th when in a triplet section and an actual 8th.
>
> 3
> ===================
> | ============
> | | | |
> | | | |
> O. O O O
>
>
> ... versus .....
>
>
>
> 3
> ============
> |\ ============
> | \ | | |
> | | | |
> O O O O
>
>
> ... versus ....
>
>
> --- 3 ----
> | |
> ===================
> | ============
> | | | |
> | | | |
> O O O O
>
> Or maybe it doesn't matter?
Now my head is really starting to hurt.
Whenever I see these obscure cases, I want to scream, "But this is for FOLK
music!" But I try to contain myself, because the more complete we make this,
the less likely the first person who tries to use this won't be frustrated.
I wish I had more time to work on this. Thanks Remo for actually doing
something! It will probably be done before I get a chance to roll up my
sleeves.
Paul Rosen
--- Life is a musical, every once in a while
the plot stops and you start singing and dancing ---
http://home.earthlink.net/~catharsis.music/
http://home.earthlink.net/~theplums/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
