On Sat, Sep 11, 2004 at 02:17:00AM -0400, Paul Rosen wrote: > 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.
I've just seen John W's comments - that "nonesssential" information should be preserved, and agree with it. It's conceivable that someone would use this new parser to transpose a piece (or do something else with it - who knows where the parser would end up ?) and then want to feed the transformed piece back through abc2mtex. So itwould have to be possible to carry any contents of this field forward. > > Since the default length can have only a limited number of values an > > int or > > enum would probably be more appropriate? What about the Balkan-style signatures ? > > 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? For stressing purposes, maybe. > I'd still support a specific "copyright" notice. It's definitely a thing that some of us need to be able to write. > > > 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'dlike to see this handled with something like a printf-style format string. I maybe want different fields printed, in different positions with respect to the tune, for different purposes, any attempt by a printer program to place them once and for all would be less than ideal. But I'm not sure this is a problem for the parser ? > 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. Perhaps different folk-musics are simple in different ways ? (if at all). -- Richard Robinson "The whole plan hinged upon the natural curiosity of potatoes" - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
