Re: [abcusers] K:none
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. 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. --Steve Bennett John Chambers wrote: Atte asked: | Some tunes are not in any specific key, but it seems abc doesn't have | any way to notate this. If I use K:C the song is shown correctly, but | this opviously is corrupted when transposing it. | | Is there a solution withinn the current abc definition that I overlooked | or should we consider extending the K: to allow K:none? Some abc programs have supported this for several years already. I've used it occasionally, though not very often. It's most useful for notating fragments of music, for example in documentation and tutorial docs. Implementing it is usually trivial, as it maps internally to the same thing as K:C. The only real advantage of K:none is that it doesn't match when you search for K:C (or K:Am or K:Ddor). Of course, just K: alone also works for this. Most software should support that, too, by mapping it to the same thing as K:C internally. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] K:none
On 19 Aug 2004, at 16:37, Steven Bennett wrote: 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. Agreed. The bare K: is most likely to be an error (user couldn't immediately figure out the correct entry, and put it off until later, then forgot about it). Programs should flag it as an error, rather than assuming that it means C. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] K:none
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. | 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. ;-). I do have a few abc template files that contain a list of the most common headers, with nothing after the colons. This saves me a few keystrokes at times. But it's easy to forget to fill them in. I'd prefer software that accepts this, perhaps with a warning, to software that chokes on it. 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. Maybe this just labels me as overly pedantic? To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] K:none
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
Re: [abcusers] K:none
Steven Bennett wrote: | I believe I decided that T: was a valid title field as well -- some pieces | simply don't have a title. Yes; I have a number of examples where I don't want a title. Mostly they're musical fragments, or things like a blank manuscript page. OTOH, one thing my Tune Finder has run across is ABC files that lack a title because they are incorporated in some fashion inside HTML files, and the title is in the HTML. This is frustrating, because it's nearly impossible for software to discover the title. These are mostly songs, it turns out, and they aren't in my index. One example is the collection at natura.di.uminho.pt, where the latest run of my search bot says all the titles just disappeared. I'd known this was a problem with that site, which has hundreds of trad Portuguese songs in ABC. My index showed 72 tunes in 43 files, but only 32 had titles. This time, the file and tune counts dropped by one, but the title count dropped to zero. I checked, and the tunes are still there, but the T lines are all just T:. If you look at the site, you'll see the tunes as GIF images and ABC, but the title is in a different font because it's in the HTML only. I've considered writing special code to deal with several sites like this, but it wouldn't be easy. I don't care if my blank manuscript pages aren't indexed, because there's no music there. Of course, if someone is specifically looking for ABC files that give blank manuscript pages, they won't find it from my Tune Finder. But so far I don't consider that a problem. | 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. Yes, this is useful. I do a fair amount of programming in perl, which is often very sketchy because most of the language has defaults and can be omitted for the most common case. This works pretty well for perl. Part of the reason is that the defaults have been fairly thoroughly discussed in the comp.lang.perl newsgroup, and the user population generally agrees on what the default should be. Whether we could get this sort of agreement from musicians isn't as clear. In conventional staff notation, a lot of things are often omitted, but what is omitted differs for different musical styles. I can think of a number of examples where the best default for omitted notation is different in different styles. | 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. | 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. Yeah, and you see that sometimes in classical music, though usually they let you figure out the key change yourself. It's especially useful in computerized notation, because it lets the computer help you by doing searches for keys, suggesting chords as a few abc apps do, and so on. Of course, its usefulness is limited, as you don't want to bother notating key changes that are only for a few measures. An interesting case where I don't indicate key changes much is in my klezmer collection. You might think that it would be useful, in light of all the different scales and frequent key changes. But frequent key changes is the reason it's not useful. Klezmer music often changes rapidly among a number of closely-related keys, and once you're familiar with this, the changes are pretty obvious. But a key change every 2 or 3 measures rapidly gets obnoxious. So I just pick most common (or initial or final) key, and use that. Irish/Scottish music is different. Some tunes do have transient changes to another key. But more common is to have the different sections of a tune in different keys. I prefer to notate this, even if it's the same signature. That way, if I'm looking for an Em tune, I also get the tunes in G/Em (or maybe D/Edor). Sometimes I decide that one of those tunes will work in the set I'm putting together. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] K:none
| I believe I decided that T: was a valid title field as well --some |pieces simply don't have a title. Yes; I have a number of examples where I don't want a title. Mostly they're musical fragments, or things like a blank manuscript page. None none and Gan Ainm are legal titles, (And not only to John Cage: the last is by far the most common Irish tune) so T:none is ambiguous. T: would seem to be a reasonable way to indicate that a tune doesn't have a title, or that at least that one doesn't want to print a title above it. Cheers, John Walsh To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
RE: [abcusers] K:none
consider extending the K: to allow K:none? What tune has no key signature? I'm confused. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] K:none
On 18 Aug 2004, at 08:07, Atte André Jensen wrote: Hi Some tunes are not in any specific key, but it seems abc doesn't have any way to notate this. If I use K:C the song is shown correctly, but this opviously is corrupted when transposing it. Is there a solution withinn the current abc definition that I overlooked or should we consider extending the K: to allow K:none? It has been suggested before, and seems not unreasonable. Transposition routines would have to be re-written to deal with it though. Currently BarFly's transpose command will only transpose to a named key, so if I wanted to transpose Giant Steps up a whole tone I'd have to tell it to transpose to D, and I'd get a key signature with two sharps, which I suppose is what you mean by corrupted. BarFly's melody analysis thinks it's in Bb Phrygian by the way, although it's not at all sure, and gives two other (equally unlikely) alternatives... Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] K:none
Phil Taylor wrote: On 18 Aug 2004, at 08:07, Atte André Jensen wrote: snip should we consider extending the K: to allow K:none? It has been suggested before, and seems not unreasonable. Ok, so how to proceed? Transposition routines would have to be re-written to deal with it though. Currently BarFly's transpose command will only transpose to a named key, so if I wanted to transpose Giant Steps up a whole tone I'd have to tell it to transpose to D, and I'd get a key signature with two sharps, which I suppose is what you mean by corrupted. Indeed... BarFly's melody analysis thinks it's in Bb Phrygian by the way, although it's not at all sure, and gives two other (equally unlikely) alternatives... Most clever people agree that if Giant Steps is in any key it would Eb. I wouldn't expect any algorithm to figure that out, though :-) -- peace, love harmony Atte http://www.atte.dk To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] K:none
Atte asked: | Some tunes are not in any specific key, but it seems abc doesn't have | any way to notate this. If I use K:C the song is shown correctly, but | this opviously is corrupted when transposing it. | | Is there a solution withinn the current abc definition that I overlooked | or should we consider extending the K: to allow K:none? Some abc programs have supported this for several years already. I've used it occasionally, though not very often. It's most useful for notating fragments of music, for example in documentation and tutorial docs. Implementing it is usually trivial, as it maps internally to the same thing as K:C. The only real advantage of K:none is that it doesn't match when you search for K:C (or K:Am or K:Ddor). Of course, just K: alone also works for this. Most software should support that, too, by mapping it to the same thing as K:C internally. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
