On 16 Oct 2003, [EMAIL PROTECTED] wrote: > > I do not like the unnecessary proliferation of inline fields of > > ABC2.0. > > I don't think its unnecessary. If you want to change clefs in mid > line, for instance. I don't like using the K: field to indicate cleff > since most of the tunes that use the V: field to date don't specify a > K: for each V: (as I mentioned in the documentation of iabc). That > is, most people expect voices to 'inherit' the key specified in the K: > field. To subscribe/unsubscribe, point your browser to: > http://www.tullochgorm.com/lists.html
My major objection to inline fields is encapsulated in the statement from ABC2.0 rev IV ------------------------------- To avoid ambiguity, inline fields that specify music properties should be repeated in each voice. For example, ... P:C [V:1] C4|[M:3/4]CEG|Gce| [V:2] E4|[M:3/4]G3 |E3 | P:D ... ------------------------------------- the need to align the meter change in every voice seems a great problem in parsing. What action does the program take when one voice out of eight does not align. ABC 2.0 states ---------------------------------------- For backward compatibility, it is still allowed to notate tune fields on a line by themselves, between the music lines: ed|cecA B2ed|cAcA E2ed|cecA B2ed|c2A2 A2:| M:2/2 K:G AB|cdec BcdB|ABAF GFE2|cdec BcdB|c2A2 A2:| ---------------------------------------- If we are considering multivoice notation, this seems a far more sensible way to notate global key and meter changes than having to match inline fields in all voices. Barry Say To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
