John Chambers wrote: > Steven Bennett writes: > | "K:none" is already defined in the ABC 2.0 draft spec, although there's a > | slight ambiguity in that spec, since "none" is also shorthand for > | "clef=none". When I implemented that section of my parser, I resolved that > | in favor of the key, and required the full "clef=none" if you want no clef. > > Sounds reasonable. K:none should mean that you don't want a key > signature; clef=none should mean that that you don't want a clef. I > use both in a few abc files I have that generate pages of blank > manuscript paper. I also made sure that "T:" alone works for a title, > since I don't want those on such pages, either. And all of these are > useful for producing musical fragments, as examples in a document.
I believe I decided that T: was a valid title field as well -- some pieces simply don't have a title. > | "K:" by itself is not documented in ANY version of the ABC spec as a valid > | sequence, and cannot be assumed to work in any program. In my own parser, > | again, that would cause an error on the field, which would cause the field > | to be ignored (in an attempt to recover), which would then cause all kinds > | of havoc. Stick with "K:none" instead. > > What I think I've seen is a few comments to the effect that C is the > default key. Since most abc software requires a K line, the only > thing this could be talking about is a bare "K:" without any key > information. Of course, I'd prefer to say that "K:" means "K:none", > not "K:C" (or K:Am" or "K:Ddor", for the benefit of anyone who > understands the difference. ;-). Maybe we should add a few comments in the ABC 2.0 spec that discusses what the behavior of a blank field line should be. That way we don't get a zillion different behaviors. > This does remind me that I've got a few funny questions about why I > sometimes do things like putting "K:G" at the start of a tune and > then "K:Em" or "K:Ador" before a later phrase. They usually say that > the second K line doesn't change anything. It does, of course, but > how do you explain that simply to someone who doesn't already > understand it? I'll usually say something like "Well, the key does > change, and I thought it would be useful to document this, even > though it doesn't effect the printed output." But this doesn't seem > to be very convincing. Until recently, I would have found such fields confusing as well. But having recently absorbed a lot of chord theory, it becomes almost necessary to have such fields where the key actually does change, because the chord progressions for "K:G" and "K:Em" are different, even though the key notation looks the same on the staff. That's also why I now prefer to display the key as a text string above the staff in addition to the on-the-staff notation. -->Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
