[abcusers] RE : tune finder
John Chambers wrote - But if the software doesn't agree on what pieces of the notation mean, it can sorta interfere with getting the music across. I've been thinking along the same lines myself for quite a while. And abc has a quandary that's common in all other kinds of computer communications: You find something that can't be expressed using the standard language. What do you do? Discuss it with as many interested people as you can. Listen to their ideas and objections. Modify your proposal accordingly. Arrive at a consensus and only then implement your ideas. Isn't that what this list is for? Start with a rule Any notation you don't understand should be ignored (perhaps with a warning but not a fatal error message). Not always possible when different sets of non-standard notation impinge on each other such as the use of ! and the various incompatible versions of the V: command. When a small crowd finds something that seems to solve the problem, they present what they've done to the general population. And a lot of people like it so it gets used and becomes part of the system. Unfortunately it screws things up for other people who may cry Wouldn't it have been better if But it's too late. The damage is done. Eventually most of the new ideas get incorporated into the standard language Not any more they don't. The standard hasn't been updated for several years and there is no mechanism to do so. Alternatively, they don't get incorporated, and you get a collection of dialects or a family of very similar but incompatible languages. Yes, that's what's happening. Bryan Creer To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE : tune finder
On 16 Jul 02 4:00 am, John Walsh wrote: John Chambers writes: One of the cuter illustrations of this: There's an old test for telling whether someone is a scientist/engineer or one of those humanities types. You ask them If you call a tail a leg, how many legs does a dog have? The answer, of course, is Four, because calling a tail a leg doesn't make it one. (At which point the humanities types all get indignant. ;-) If a tail is DEFINED to be a legthen 5 but still only 1 tail not 5 since we have not DEFINED a leg to be a tail -- RJP - [EMAIL PROTECTED] http://www.sedric.co.uk. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE : tune finder
John Walsh writes: | John Chambers writes: | | One of the cuter illustrations of this: There's an old test | for telling whether someone is a scientist/engineer or one | of those humanities types. You ask them If you call a tail | a leg, how many legs does a dog have? | | The answer, of course, is Four, because calling a tail a | leg doesn't make it one. (At which point the humanities | types all get indignant. ;-) | | Unless they're historians, in which case they say, | Yep, that's a good ole Abe Lincoln story. Yeah, but there are plenty of older attributions, including (of course) Ben Franklin. Because he published them, he got credit for lots of clever sayings that he took from others. I remember it being used in classes in both mathematical logic and linguistics as an introduction to a serious topic in both fields, the confusion over whether language is arbitrary (which is obviously true) or whether words can have a precise meaning (which is also obviously true). This all comes together in the growing field of computer communications. It's basically true that the languages that computers use to exchange information are inherently arbitrary. But as with any other language, you need agreement on the syntax and semantics, or you can't have communication. We've seen this occasionally in abc, of course. We've had a few suggestions of alternative ways of encoding music. People have posted pseudo-abc to a few lists that do things like putting the lengths before the notes, using '/' or 'I' for bar lines, and so on. And some programs implement variants such as using '!' for staff breaks. All of these would work just as well as the (semi)standard way that abc does it. But if the software doesn't agree on what pieces of the notation mean, it can sorta interfere with getting the music across. And abc has a quandary that's common in all other kinds of computer communications: You find something that can't be expressed using the standard language. What do you do? What we've done in abc is actually what has been done in lots of other computer standards. Start with a rule Any notation you don't understand should be ignored (perhaps with a warning but not a fatal error message). Then new ideas can be tried out in isolation, and the new things shouldn't bother existing software (aside from users seeing a few warning messages). When a small crowd finds something that seems to solve the problem, they present what they've done to the general population. A debate ensues, usually settling down to Who needs it? versus We do. Eventually most of the new ideas get incorporated into the standard language. But, since this requires cooperation among a group of humans, it usually happens slowly. Alternatively, they don't get incorporated, and you get a collection of dialects or a family of very similar but incompatible languages. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE : tune finder
One of the cuter illustrations of this: There's an old test for telling whether someone is a scientist/engineer or one of those humanities types. You ask them If you call a tail a leg, how many legs does a dog have? The answer, of course, is Four, because calling a tail a leg doesn't make it one. (At which point the humanities types all get indignant. ;-) Unfortunately for that reasoning, this riddle (given the same answer) comes from the _Sophismata_ of Jehan Buridan (d.1358) which a fair number of your humanities types will know of. Buridan used donkeys rather than dogs for his examples. The idea of distinguishing conditional from categorical definition possibly comes from Ockham; Ockham's _Summa Logicae_ at one point talks about definitions of non-existent things, like chimaeras - as he says, what these amount to is saying what a chimaera would have to be if there were such things, and are to be distinguished from the type of definition that is seriously intended to imply that what it defines exists. He anticipated Russell's theory of descriptions here. In turn, Ockham credits Priscian with this part of the theory of definition; I've never read either Priscian or an account of his work. Whether (or which) definitions had ontological consequences was a hot issue for early mediaeval philosophy as a result of Anselm's Ontological Argument for the existence of God. I don't think Ockham or Buridan would have been very impressed by it (there's no surviving comment on it by either) but it must have put them on the spot and they'd have had to come up with some sort of theoretical framework to deal with it. The dog/donkey riddle isn't much of a refutation in itself, but it might be used as part of one. As John Walsh says, the riddle is often attributed to Lincoln. It's quite possible that Lincoln heard it in law school, since the law continued to use the analytical methods of mediaeval logic and semantics long after the philosophers had forgotten about them. (The philosophers changed their minds sharpish in the twentieth century when they realized they'd got themselves into a variety of semantical messes that a bit of mediaevalist precision might have obviated). It's odd that mediaeval Western philosophers did so little work on the conceptual structure of music. Their methods should have been able to deal with it, and the history of music might have been substantially different if they'd tried. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE : tune finder
Yes, it would be 'better and less misleading' for the abc user community that understands: 1. 2 sharps 2. they are in the 'standard' place 3. E Dorian means E is the tonic. Me, personally, just speaking for myself, I can play in (for example) G Dorian without having to remember which flats are there, but I have to puzzle it out if I see a tune written out with one flat and try to figure out which of the possible tonics I should be thinking about. But that's just me, personally, just speaking for myself. So therefore my, personal speaking for myself selfish little opinion clearly shouldn't count. sigh A a positive comment, I don't have any objection to a notation that allows the number of flats or sharps to be explicitly notated without tonic information, I just have an objection to the statement or implication that that is somehow wrong or misleading to the entire abc user community to allow tonic and modes to be specified as a a first order definition. Skink allows Dmaj or Dion as synonyms for D, if you like. wil [EMAIL PROTECTED] wrote: Eric Forgeot wrote - I thought it was a good idea to use 2 K: fields to write both the mode and the key, but this solution of K:D % EDorian is maybe better. Will you forgive me if I use it in the future ? :) Wouldn't it be better and less misleading to be able to say K:^f^c % EDorian or better still have separate actual fields rather than a comment to hold the tonic and mode? Just a thought. Bryan Creer 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
[abcusers] RE : tune finder
Wil Macaulay said - Yes, it would be 'better and less misleading' for the abc user community that understands: 1. 2 sharps Good. 2. they are in the 'standard' place Not sure what you mean. 3. E Dorian means E is the tonic. Of course it does but does K:D mean D is the tonic or just that the writer wanted two sharps? Me, personally, just speaking for myself, I can play in (for example) G Dorian without having to remember which flats are there, but I have to puzzle it out if I see a tune written out with one flat and try to figure out which of the possible tonics I should be thinking about. So, presumably, you never use books of conventional music notation which (apart from a few baroque pieces I've come across) never tell you the tonic. Very few of them give the mode either, certainly none of the collections of English traditional music that I have and not many of the Irish collections (Krassen's edition of O'Neill for instance). Those that do give the mode give it AS WELL AS not INSTEAD OF the key signature. If you have trouble working out the tonic from the notes of the tune does that mean we shouldn't rely on the accuracy of any tune you post? Of course, a lot of people know less than you do about modes so their postings will be even less reliable. So therefore my, personal speaking for myself selfish little opinion clearly shouldn't count. Everybody's opinion counts but it would always be nice to know the reasons behind that opinion and that that opinion was open to modification in the face or a reasoned argument. A a positive comment, I don't have any objection to a notation that allows the number of flats or sharps to be explicitly notated without tonic information, Thank you. That's all I've ever asked for. (In this context.) I just have an objection to the statement or implication that that is somehow wrong or misleading to the entire abc user community to allow tonic and modes to be specified as a a first order definition. I wasn't aware that anybody had made such a statement. There are those (fortunately a diminishing number) who do not wish to allow the use of an explicit key signature and feel that the use of the tonic should be compulsory. I have an objection to that. Skink allows Dmaj or Dion as synonyms for D, if you like. You are assuming D means D major which in the case of K:D % E dorian it clearly did not. Bryan Creer To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE : tune finder
Bryan Creer wrote: | Wil Macaulay said - | | 2. they are in the 'standard' place | | Not sure what you mean. Well, I do have a few tunes that are written with two sharps, but they are ^g^c. (Actually, I'd usually write them K:^G^c to make it obvious that it's not the classical signature. And I might also add =F into the signature, just to make sure that nobody can misread it.) | 3. E Dorian means E is the tonic. | | Of course it does but does K:D mean D is the tonic or just that the writer | wanted two sharps? Well, it *means* that D is the tonic. People often say something other than what they mean. But the fact that someone misuses terminology doesn't necessarily mean that they're right. One of the cuter illustrations of this: There's an old test for telling whether someone is a scientist/engineer or one of those humanities types. You ask them If you call a tail a leg, how many legs does a dog have? The answer, of course, is Four, because calling a tail a leg doesn't make it one. (At which point the humanities types all get indignant. ;-) The reason that technical types tend to agree with this is that they usually appreciate that language isn't entirely arbitrary. Sure, it's artificial and invented. But its primary function is communication. If you misuse it and use your own meanings for terms, you lose the ability to communicate. This gets even more critical when computers get involved. They have maybe the intelligence of a fruit fly, and aren't very good at decoding misuses of language. In the case of abc notation, it's clear what K:D means. It means that the key is D major. Anything else is a misuse. Yes, you can do that, just as you can make up your own private language for any other topic. But you won't be communicating with others, humans or computers. You'll be misleading them. Now, this is understandable with people who don't quite understand the difference between, say, K:G and K:Em. We all understand that children and newbies can be excused for their misuse of a language. But the right response to this isn't to say that it doesn't matter. The right response is to try to educate them. We do want them to grow up able to communicate with the rest of us. | Me, personally, just speaking for myself, I can play in (for example) G | Dorian | without having to remember which flats are there, but I have to puzzle it | out | if I see a tune written out with one flat and try to figure out which of the | possible | tonics I should be thinking about. Yeah; I'm the same way. I tend to read new tunes slowly, in part because they don't make sense until I've got the key. Once I've figured that out, I can read much faster, because the music makes sense. This is the reason that I like to use non-classical key signatures. Thus, if a Macedonian tune is in hejaz scale, being told that it's Bb or Gm causes problems until I figure out that that's a lie and the tonic is actually D. Then it makes sense, and my fingers know where the notes of the scale are. A signagure of _B_e^F is useful, even without the tonic, because I know right off that it's not a classical scale, and I go right into find the tonic mode. It could also be C, and I know within a bar or two which it is. | So, presumably, you never use books of conventional music notation which | (apart from a few baroque pieces I've come across) never tell you the tonic. | Very few of them give the mode either, certainly none of the collections of | English traditional music that I have and not many of the Irish collections | (Krassen's edition of O'Neill for instance). Those that do give the mode | give it AS WELL AS not INSTEAD OF the key signature. I've often thought that the classical tradition of giving the kay (tonic and mode) in the title developed in part because that is valuable information to the musician. The notation doesn't provide any way to give the reader this information, so you give it in a different manner. | If you have trouble working out the tonic from the notes of the tune does | that mean we shouldn't rely on the accuracy of any tune you post? Of course, | a lot of people know less than you do about modes so their postings will be | even less reliable. That's already true. Bad K lines are a fact of life in the online abc collections. It's one of the main reasons for wanting abc to include explicit key signatures. True, this is less valuable than the tonic+mode. But it's better than an incorrect tonic+mode. Correct information is almost always better than incorrect information. | I just have an objection to the statement or implication that that is | somehow | wrong or misleading to the entire abc user community to allow tonic and | modes to be | specified as a a first order definition. | | I wasn't aware that anybody had made such a statement. I don't think so, either. I think it's a common sort of
Re: [abcusers] RE : tune finder
John Chambers writes: One of the cuter illustrations of this: There's an old test for telling whether someone is a scientist/engineer or one of those humanities types. You ask them If you call a tail a leg, how many legs does a dog have? The answer, of course, is Four, because calling a tail a leg doesn't make it one. (At which point the humanities types all get indignant. ;-) Unless they're historians, in which case they say, Yep, that's a good ole Abe Lincoln story. Cheers, John Walsh To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE : tune finder
Eric Forgeot wrote: Someone at http://www.terra.es/personal8/niltoni/ made a copy of many tunes found everywhere, and if most of them had the original url somewhere in the tune, it would help to find the rest again. Why not tell him directly? His e-mail is on the web page: [EMAIL PROTECTED] He understands English. I know, because he proudly announced his new site to me. I looked at it and found he had copied my entire collection, not just once, but twice... I told him this was a copyright infringement, and he said he would remove them, but they're still there... I had better remind him... Henrik Norbeck, Stockholm, Sweden [EMAIL PROTECTED] http://home.swipnet.se/hnorbeck/ My home page http://home.swipnet.se/hnorbeck/abcmus/ Abcmus ABC program http://home.swipnet.se/hnorbeck/abc.htm 1000 abc tunes http://surf.to/blackthorn Irish trad music band http://www.rfod.se/folklink/ Links to Swedish music To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] RE : tune finder
John Chambers wrote - For example, recently I saw a line like: K:D % EDorian It could be that the author was using software that only allowed the tonic as shorthand for the key signature and didn't support modes (such programmes have been known to exist). He should be praised for adding the extra information in the only way available to him. Henrik Norbeck wrote - Getting back to the abc, I would prefer to have the notation K:^f ^c to K:D because it simply means what it says and does not imply anything else. Then you're free to place whatever you like in a comment afterwards K:^f^c % Irish e minor I would just like to say that the summer here in England has been wet, grey and miserable so far but today the sun is shining which is just as well since I'm playing out of doors. I shall do so with a song in my heart. Bryan Creer To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] RE : tune finder
That depends. Do you just want the information to be present somewhere in the headers? Or would you like software to be able to use the information sensibly? both if possible. I want pple to be able to find again this tune if they had only the tune somewhere else, or to come back later to find new tunes in the tunebooks I'm making. But on the other side, if it can enable software to be more efficient, I'll try to follow the rules. I may use this F: field in the future Someone at http://www.terra.es/personal8/niltoni/ made a copy of many tunes found everywhere, and if most of them had the original url somewhere in the tune, it would help to find the rest again. K:D % EDorian This made it clear that the transcriber knew the correct key and mode, and was intentionally giving incorrect information. Presumably I think that the transcriber wanted to help people like me reading D key ? oh, so there is 2 sharps in it. If I read EDorian I have to find my table with all the modes, find the right one, and then the number of accidentals etc. ( but it's true with abc software displaying the notes, you have all that immediately... ) I don't think the transcriber was a sort of musical terrorist whose aim was to puzzle softwares related to mode. this was to defeat people using software to look for things by key. Isn't the problem for mode instead ? We have the right key, but the right mode is after the % The problem with the Key/Mode issue is that the ionian mode corresponds to the key, so if I intentionally decide to write the key and don't care about mode, there is always someone saying : hey, you're wrong, it's not in the ionian mode, it's in dorian/phrygian etc. In the C key there is a specific notation for the aeolian, we had a small m to have Am, for mixolydian we add Mix to have GMix etc. Why isn't there any specific notation for the ionian ? With CMaj for example, we would be sure it's in the ionian mode, and there whould be no confusion with the C key. When people do things like this, there's a real temptation to throw up your hands, and go play some tunes to cool off. I thought it was a good idea to use 2 K: fields to write both the mode and the key, but this solution of K:D % EDorian is maybe better. Will you forgive me if I use it in the future ? :) If it generalizes, it will be maybe easier for a cleaver script to understand it, and better than to give a bad result for a bad choosen mode in the K: field. ___ Do You Yahoo!? -- Une adresse yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] RE : tune finder
Eric Forgeot wrote - I thought it was a good idea to use 2 K: fields to write both the mode and the key, but this solution of K:D % EDorian is maybe better. Will you forgive me if I use it in the future ? :) Wouldn't it be better and less misleading to be able to say K:^f^c % EDorian or better still have separate actual fields rather than a comment to hold the tonic and mode? Just a thought. Bryan Creer To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE : tune finder
1. search for 'Lady Ann Montgomery' oops - 30 returns. six are were transcribed by Henrik Norbeck, and of those, three have a more recent date. I know Henrik's been reliable in the past, so I'll pick one of those. John, you can reduce the number of duplicates by removing some of the aliases for my abc page from your search engine. Now you have: http://home.swipnet.se/hnorbeck/abc/ http://home.swipnet.se/~w-11382/abc/ http://home1.swipnet.se/%7Ew-11382/abc/ http://home1.swipnet.se/~w-11382/abc/ Just keep the first one! But maybe you should add my mirror site http://hem.passagen.se/hnorbeck/abc/ Henrik Norbeck, Stockholm, Sweden [EMAIL PROTECTED] http://home.swipnet.se/hnorbeck/ My home page http://home.swipnet.se/hnorbeck/abcmus/ Abcmus ABC program http://home.swipnet.se/hnorbeck/abc.htm 1000 abc tunes http://surf.to/blackthorn Irish trad music band http://www.rfod.se/folklink/ Links to Swedish music To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] RE : tune finder
It's maybe possible for your tune finder to use this code to archive the tune (I don't know exactly how the tune finder works) and if there is no replicant of the tune (i.e. if the original website where the tune has its origin is down) to use it nevertheless, so the code would mean only it's not an original tune, you've been warned, and then if there is allready several tunes with the same name and code, don't display it. For example I've made a set of tune I play with my folk band, I transcribed some and there is a copy elsewhere on my homepage, and copied others available on internet, but I want to present this abc file nevertheless. But it's really no use for the tune finder, and I guess there is several other homepages and tunes in this case. | Could we directly insert a little code at the beginning of an abc | file to exclude it from your tune finder, like for the robot | exclusion header in html files? Actually that's not a bad idea. I've been a bit busy lately; not time to answer much email. But I'll try to get arount to it. But there are the contra-indications ... I use the Z: field to write I made the transcription, and give then only the email adress. I found conveniant to write the Url after it, so I don't use the F: field for this because I would have been redundant. Do you think we should generalize the use of the F: field for this purpose ? We've had occasional suggestions that we use the F: header line to contain a tune's original URL For example, all the tunes by Marin Marais (there is some on the web). Wouldn't anybody transcribing stuff that complicated put it into a separate file or identifiably distinct site and advertise the fact? yes, but we can find the main theme for some pieces : X:1 T:Alcyone T:Menuet pour les bergers et les bergeres C:Marin Marais B:XVIIIeme M:3/4 L:1/4 Q:C4=60 K:C a f g | a2 d | g/f/ e d/^c/ | d2 A | a f g | a_b a | g fe | e3 :| |: fg f | cd c | A_B A | A F G | A f A | B B^c | d ^cd | d3 :| There is also available by Marais in abc the famous Airs des Matelots, which can be found in the english tradition under the title : The female sailor, or Matelotte. I don't know where this great tune finds its spring... ___ Do You Yahoo!? -- Une adresse yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE : tune finder
| I use the Z: field to write I made the transcription, and give | then only the email adress. I found conveniant to write the Url | after it, so I don't use the F: field for this because I would | have been redundant. Do you think we should generalize the use of | the F: field for this purpose ? That depends. Do you just want the information to be present somewhere in the headers? Or would you like software to be able to use the information sensibly? If you only care that information be present, and don't care that it be usable, then it's fine to put it anywhere you like. If you would like the information to be useful (so that not just a human, but also a piece of dumb software can understand it), then it's a good idea to consistently put the same information in the same place in all the tunes. This is one of the reasons that I haven't bothered having my tune finder keep track of a lot of the fields that people would like to ask about. If you look at much online abc, you'll soon see that people are supremely sloppy about where they put what information. The C field is routinely used to hold place names, years, publishers, and other information. The O field is used for just about any information you can imagine. Titles contain composer names and html blink tags. And so on. In some cases, this is clearly intentional obfuscation. For example, recently I saw a line like: K:D % EDorian This made it clear that the transcriber knew the correct key and mode, and was intentionally giving incorrect information. Presumably this was to defeat people using software to look for things by key. When people do things like this, there's a real temptation to throw up your hands, and go play some tunes to cool off. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE : tune finder
It occurs to me that one of the problems I would like to solve as a user of a search engine of any kind, the tune finder being just one of them - is some indication (no matter how slight) of the quality of the result. If even a small number of content providers consistently use the Z field to provide their name and the date of transcription , and the tune finder returns it as part of the search, I think users will quickly do something like this: 1. search for 'Lady Ann Montgomery' oops - 30 returns. six are were transcribed by Henrik Norbeck, and of those, three have a more recent date. I know Henrik's been reliable in the past, so I'll pick one of those. 2. search engine quietly adds to the ranking of the one picked. This could be per tune, or could be per site, which makes for a smaller amount of processing. 3. next person comes along and asks for a tune, the higher ranked sites get presented first. Over time, the more often a transcriber's tunes get picked the more likely they are to be presented at the top of the list to the subscriber. Tunes which don't use the Z field will still be presented, but will be unlikely to be picked unless there are few others presenting the same content. It's not necessary to parse any given field, simply present what is likely to already be there for tune collectors who've been doing it for a while. If there are a large number of duplicates, only the first N could be presented without major harm. Thoughts? John Chambers wrote: | I use the Z: field to write I made the transcription, and give | then only the email adress. I found conveniant to write the Url | after it, so I don't use the F: field for this because I would | have been redundant. Do you think we should generalize the use of | the F: field for this purpose ? That depends. Do you just want the information to be present somewhere in the headers? Or would you like software to be able to use the information sensibly? If you only care that information be present, and don't care that it be usable, then it's fine to put it anywhere you like. If you would like the information to be useful (so that not just a human, but also a piece of dumb software can understand it), then it's a good idea to consistently put the same information in the same place in all the tunes. This is one of the reasons that I haven't bothered having my tune finder keep track of a lot of the fields that people would like to ask about. If you look at much online abc, you'll soon see that people are supremely sloppy about where they put what information. The C field is routinely used to hold place names, years, publishers, and other information. The O field is used for just about any information you can imagine. Titles contain composer names and html blink tags. And so on. In some cases, this is clearly intentional obfuscation. For example, recently I saw a line like: K:D % EDorian This made it clear that the transcriber knew the correct key and mode, and was intentionally giving incorrect information. Presumably this was to defeat people using software to look for things by key. When people do things like this, there's a real temptation to throw up your hands, and go play some tunes to cool off. 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] Re: Tune finder, collections, header fields
Hello, Jack Campin wrote: (...) there are some out there where the collection information is only given in non-ABC text at the beginning, and it's easier to simply add a dummy tune header there than go through the whole file putting S: and B: lines into each tune. On the long term, for maintaining the correct source and not the least copyright information it will be necessary anyway to store it with each tune. About the tune finder itself: * It files single tune files first, so this X:0 info is an endangered species anyway. * It is desiged to extract tunes from files so again X:0 info will get lost. The problem is not a solution that is o.k. for the next month, target in all efforts of collections and catalogues should be the useability at least for the next in five to fifteen years (in scientific terms much longer). (...) I'm not suggesting we change anything - this is a convention using the existing spec. The worst case is that we end up with a few incomplete tunes; what would that break? The worst case is that people get used to this X:0 info and in five years we can discuss solutions for clearing up files where some of this info is lost completely,some in X:0 titles and W: fields other is in the X:field, and some is in the B: and S: fields. So to all programmers out there: find ways to include all (at least source and copyright relevant) header information into your notation/other output (by default)! So nobody can say he did not know or did not see this info in the abc text. In the specific case of Atalanta Fugiens I haven't done *anything* nonstandard here - the extra T: line is something like T:Atalanta Fugiens (cantus firmus) a legitimate title which exactly describes the tune in the body that follows. (...) It might also be a bit too late, as the ambiguity has already taken you and I in different directions in the way we use these (and other people have still different interpretations). It is never to late to establish a standard if we are talking about abc as something with a future. (...) I often transcribe things from rare printed sources. So for me it's important to have a way of identifying the specific copy; often there may only be one copy in the world with a particular tune in it, because of an undocumented variant print run or hand-written annotation. So I've ended up with a convention where S: identifies the book generically (title, edition) and B: gives the details needed to identify the exact bit of paper I was looking at, e.g. a library catalogue number. I don't expect everybody to make this distinction, usually it doesn't matter. So why this way? it would fit to the standard much better to store the general generic info - title edition - in the B:field and the specific info into the S:field. And your example shows that we need some amendment to the standard. There's another situation (already out there on the web) where getting a bunch of related tunes together matters but where they don't all come from the same book: when you want a set of tunes for a specific country dance. If you type Hamilton House into a search engine you might want the tune of that name, but you might also want an entire set for the corresponding dance. There is no unique source for such sets; different bands have different ones. There's no standard ABC field to put in the header saying which dance the tune is for, and even if there were it wouldn't help much, because some sequences of tunes work and others don't, you can't just put any tunes associated with the dance together in any order and expect to get a playable result. You are right, there is no satisfying solution for it and this is a shame. On the other hand it could simply and instantainously be done by implementing a DA: = dance field into the header. Since there is no such field, it cannot make any existing abc's outdated, and since it is not active, I belive it could be used from now on. In the moment the only problem to discuss is to allow double letters for fields. I know this is serious because its new but in principle I do not see a problem. So for the draft standard this would be: Field name header tune elsewhere Used by Examples and notes == == = === == $ DA:dance yesno archive DA:Hamilton House, DA:Maraichine index $DA - dance; sometimes it is helpfull to specify the dance which $the music is meant for more than the R:rhythm field allows, $like with musik compiled for a certain country dance. by the way I do not know about the exact use of the F: field, can someone show me. Maybe this would be a better place to store the information in question. Nobody seems to be using it; whatever usage gets agreed on, it'll be years before there are enough files containing it for it to be worthwhile for the Tune Finder to search on it. We are talking about info that cannot be stored
Re: [abcusers] Re: Tune finder, collections, header fields
There's another situation (already out there on the web) where getting a bunch of related tunes together matters but where they don't all come from the same book: when you want a set of tunes for a specific country dance. If you type Hamilton House into a search engine you might want the tune of that name, but you might also want an entire set for the corresponding dance. There is no unique source for such sets; different bands have different ones. There's no standard ABC field to put in the header saying which dance the tune is for, and even if there were it wouldn't help much, because some sequences of tunes work and others don't, you can't just put any tunes associated with the dance together in any order and expect to get a playable result. You are right, there is no satisfying solution for it and this is a shame. On the other hand it could simply and instantainously be done by implementing a DA: = dance field into the header. Since there is no such field, it cannot make any existing abc's outdated, and since it is not active, I belive it could be used from now on. In itself, this doesn't completely meet the requirement: the same tune may be used for many dances, and in a specific dance set it has to occur at a specific point in the sequence. So your DA: header field would need to point to multiple instances of sequences of tunes or (more concretely) multiple segments of files; this would need a rather complex syntax, and you can't expect a danceband arranger to think in terms of database schema design when typing up a few sets for new players. Surely it's better just to have a way of identifying dance sets in their own right and saying what individual tunes comprise them and in what order? - this is what the people who put a header like X:0 T:dance set title at the start of each set are doing. Doesn't existing software already complain on encountering an unknown header field more often than it does on encountering an instance of the zero-index no-tune-body convention? James Allwright wrote: : Sorry, this won't work. You can only have 1 character before the : colon, otherwise you are going to have lots of parsers complaining. This has surely *got* to be fixed, or ABC is going to keep on banging against that limit over and over again for years to come. The header namespace is too darn crowded. Comaptibility with existing software isn't a very serious consideration. Nearly every ABC tune you download off the web needs some sort of editing before you can use it the way you want to. How difficult can it be to just remove a header field your program doesn't understand? It only takes a few seconds and it'll take far longer than that to make any real use of the music. There's quite a bit of useful ABC out there that no currently supported program can use directly, and the proportion's going to keep growing. But you have to locate it before you can massage it, so tweaks that help the Tune Finder do its thing have to receive higher priority than compatibility with players and formatters. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
