Re: [abcusers] Re: abcusers-digest V1 #364
On Thu, 12 Oct 2000, Jack Campin wrote: We already have several header fields like this, all of them wildly ambiguous and interpreted in every possible way by some transcriber somewhere. What do you want your new field to do, exactly? What *kind* of class? - I can think of class divisions like: [impressive list] Two letters isn't going to do it, we need something extensible. Putting keywords in N: fields is a stopgap you can use meanwhile. Yes. Or invent your own %%private_keyword: fields, is another way round it. -- 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
Re: [abcusers] Re: abcusers-digest V1 #364
Incidentally, I would like to see a 'class' code, that would include one or more characters, each of which would represent a class of music to which the tune belongs. Then, if there is a large archive of tunes, you can pipe it through a filter to extract all those in the archive that belong to the class of music of interest to you, whether you know the names of the individual tunes in the class or not. We already have several header fields like this, all of them wildly ambiguous and interpreted in every possible way by some transcriber somewhere. What do you want your new field to do, exactly? What *kind* of class? - I can think of class divisions like: - transcription from live performance vs recording vs print - raw transcription vs edited version - final version vs draft - fiddle vs pipe setting - transposition for soprano vs alto voice - grade V vs grade VIII difficulty level - melody vs four-part harmonization - copyright vs public domain - laid out in portrait vs landscape format - Gaelic vs English lyrics - requires standard vs DADGAD guitar tuning - banned or permitted under German anti-Nazi laws - standard vs extended vs archaic ABC - original copy or from a mirror site - clean vs bawdy version Two letters isn't going to do it, we need something extensible. Putting keywords in N: fields is a stopgap you can use meanwhile. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Re: abcusers-digest V1 #364
At 09:26 AM 10/11/00 -0700, Bryan wrote: One final point I have to make. I am worried by phrases like "if we permit" and "should force people" and comparisons with speeding laws (For goodness sake! Nobody's going to die here.) Are WE (who like it the way it is) becoming WE (who must be obeyed)? Couldn't we borrow a few words from modern business speak like enable, provide, facilitate? I honestly can't see why this whole discussion is such a great problem. Why not simply have two separate key signature codes, one, K:, that can contain the key/mode, and the other, k: (say), that can contain the key signature. That way you maintain compatibility, nearly, with old abc files, but have full scope for exercising personal preference. Any tune can have either or both fields filled. Incidentally, I would like to see a 'class' code, that would include one or more characters, each of which would represent a class of music to which the tune belongs. Then, if there is a large archive of tunes, you can pipe it through a filter to extract all those in the archive that belong to the class of music of interest to you, whether you know the names of the individual tunes in the class or not. Derek To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
