Re: [abcusers] net-friendly information
For what it's worth, Muse is quite happy with X:0100ABCD Richard Robinson [EMAIL PROTECTED] and probably all the other variant X: lines - Original Message - Richard Robinson wrote that On Thu, 23 Aug 2001, John Chambers wrote that Richard Robinson wrote: I wonder whether the X: line used for this ... and so forth until ... Not exhaustive, but ... I have here, and use, abc2ps, abcm2ps, abc2mtex and yaps. These will all cope OK with an X: line of X:[EMAIL PROTECTED] and, for that matter, with X:0100ABCD Richard Robinson [EMAIL PROTECTED] abc2ps complains, but that's all. They all rip the file ok. But I bet there are other programs that won't ... ? ... etc. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] net-friendly information
Laurie Griffiths wrote: | For what it's worth, Muse is quite happy with | X:0100ABCD Richard Robinson [EMAIL PROTECTED] ... | Richard Robinson wrote that | Not exhaustive, but ... I have here, and use, abc2ps, abcm2ps, abc2mtex | and yaps. These will all cope OK with an X: line of | | X:[EMAIL PROTECTED] ... | abc2ps complains, but that's all. They all rip the file ok. | | But I bet there are other programs that won't ... ? Probably, but rejecting such a tune isn't reasonable, and should be fixed. Giving a warning is reasonable. One idea might be to insert a % after the last digit, and then every abc program should accept it. The worry then would be programs that strip off comments and don't pass them on. There are a lot of examples of software that casually accepts trailing junk in numbers without comment. Strings like 5cm and 17.3km are routinely accepted in a lot of programming languages, for obvious reasons. X:0100ABCD should be ok for the same reasons, though you'd expect programs to treat it as X:100. One thing I oughta check: I have a number of perl scripts that, among other things, renumber the tunes in a file. I should verify that they don't lose such trailing text. Keeping it would be easy, but discarding the old X line and generating a new one is even easier. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] net-friendly information
On Sat, 25 Aug 2001, John Chambers wrote: | | X:[EMAIL PROTECTED] ... | abc2ps complains, but that's all. They all rip the file ok. | | But I bet there are other programs that won't ... ? Probably, but rejecting such a tune isn't reasonable, and should be fixed. Giving a warning is reasonable. One idea might be to insert a % after the last digit, and then every abc program should accept it. The worry then would be programs that strip off comments and don't pass them on. There are a lot of examples of software that casually accepts trailing junk in numbers without comment. Strings like 5cm and 17.3km are routinely accepted in a lot of programming languages, for obvious reasons. X:0100ABCD should be ok for the same reasons, though you'd expect programs to treat it as X:100. Which is an argument against hex numbers, this is only acceptable if X: has no meaning. OTOH, I have no particualr argument _for_ them, except that I want a scheme with a fixed number of characters, and more room. One thing I oughta check: I have a number of perl scripts that, among other things, renumber the tunes in a file. I should verify that they don't lose such trailing text. Keeping it would be easy, but discarding the old X line and generating a new one is even easier. Mmm. I think this convinces me to invent a new %%ID line rather than using X: - what I'm looking for is a way to pin a fixed ID onto each tune in my web collection, so that I can use it to generate a URL that will stay the same regardless of how I might re-organise the files, add in new tunes, etc. Obviously, I'd like that to stay with the tune rather than getting changed by other peoples' re-numbering schemes (or, indeed, my own). -- 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] net-friendly information
On Fri, 17 Aug 2001, Jack Campin wrote: I have been looking round other people's transcriptions on the net over the last few days and I'm getting reminded of a few missing features of ABC that would make web-trawls for music more productive. - universal identifiers, along the lines of the Message-IDs used with email and Usenet postings. These tell you whether you've found another copy of something you've already got, and (if they have some internal structure, as Message-IDs usually do) can help direct you to the human who did the transcription or made it available. I wonder whether the X: line used for this, since I'm not sure what other use there is for it. Does any software currently use the X: line for anything (other than the ease-of-parsing start-of-tune marker) ? I think it was supposed to be a way of giving a unique id to each tune in a file ? Could it not be extended to give each tune a unique id on a system ? (and from there, add in machine info and get net-wide uniqueness ?). As Jack remarks, this would need some sort of local number generator. From a couple of minutes' worth of non-exhaustive poking, it seems that abc2ps and yaps will accept some fairly arbitrary combinations of numbers, letters, brackets, dots, etc, in X: without blowing up, abcm2ps and abc2mtex won't ... This is a top-of-the-head suggestion, please shoot it down ... I need some form of system-wide tune ID's. I can always lash up something peculiar (!) to this system, of course, but if we can agree on something more generally useful, that would be better. -- 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] net-friendly information
Richard Robinson wrote: | I wonder whether the X: line used for this, since I'm not sure what other | use there is for it. Does any software currently use the X: line for | anything (other than the ease-of-parsing start-of-tune marker) ? I think | it was supposed to be a way of giving a unique id to each tune in a file ? | Could it not be extended to give each tune a unique id on a system ? ... | This is a top-of-the-head suggestion, please shoot it down ... I need some | form of system-wide tune ID's. I can always lash up something peculiar (!) | to this system, of course, but if we can agree on something more generally | useful, that would be better. Some people do just this. For example, look at: http://www.capecod.net/~bblack/ He uses a 6-digit X field, with the first two digits a volume number in his own private classification. Several other people have done something similar. This seems to work pretty well for a unique id within a single ABC collection. All that's really needed is a way to also identify the collection. The main thing that shoots this down from the viewpoint of a web-wide id is that other people are incredibly lax about the X index. I've had to add code to my Tune Finder to deal with things like duplicate X indexes and numbers that contain periods. Some people can't be bothered to use X at all, and if your software can't handle that, well, it's your problem, not theirs. So the main problem is the difficulty of enforcing any particular way of doing this, given the obstinacy of many ABC users. The best we can hope to do is to come out with some recommendations. If you want your online tune collection to be maximally useful, here are some guidelines ... One thing I've wondered: While it seems clear that the X header line should have a number (integer?) after the colon, it's not obvious that there should be any problem with following it with some more junk that most software would ignore. That junk could be a more useful id string that might include an email address or URL to lead a reader to the file's owner. Is there any software that would do anything other than give a warning message for such extra X junk? For example, I have online copies of the three O'Neill's books that have been transcribed to ABC. O'Neill numbered the tunes in his books, and that number is the obvious X index. But if it wouldn't bother any software, it would be useful if I could augment it along the lines of: X:123 O'Neill's 1001 T:Young Francis Mooney ... X:123 O'Neill's 1850 T:Old Truagh ... X:123 O'Neill's Waifs T:Jackson's Silver Mines Note that in this case, having X:123 for each tune isn't a problem, as these tunes will never be in the same file - or even in the same directory - in my online collection. But still, it would be useful if the tune id stated right at the start which collection it is from. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] net-friendly information
Richard Robinson wrote: | I wonder whether the X: line used for this, since I'm not sure what other | use there is for it. Does any software currently use the X: line for | anything (other than the ease-of-parsing start-of-tune marker) ? I think | it was supposed to be a way of giving a unique id to each tune in a file ? | Could it not be extended to give each tune a unique id on a system ? ... | This is a top-of-the-head suggestion, please shoot it down ... I need some | form of system-wide tune ID's. I can always lash up something peculiar (!) | to this system, of course, but if we can agree on something more generally | useful, that would be better. Some people do just this. For example, look at: http://www.capecod.net/~bblack/ He uses a 6-digit X field, with the first two digits a volume number in his own private classification. Several other people have done something similar. This seems to work pretty well for a unique id within a single ABC collection. All that's really needed is a way to also identify the collection. The main thing that shoots this down from the viewpoint of a web-wide id is that other people are incredibly lax about the X index. I've had to add code to my Tune Finder to deal with things like duplicate X indexes and numbers that contain periods. Some people can't be bothered to use X at all, and if your software can't handle that, well, it's your problem, not theirs. So the main problem is the difficulty of enforcing any particular way of doing this, given the obstinacy of many ABC users. The best we can hope to do is to come out with some recommendations. If you want your online tune collection to be maximally useful, here are some guidelines ... One thing I've wondered: While it seems clear that the X header line should have a number (integer?) after the colon, it's not obvious that there should be any problem with following it with some more junk that most software would ignore. That junk could be a more useful id string that might include an email address or URL to lead a reader to the file's owner. Is there any software that would do anything other than give a warning message for such extra X junk? For example, I have online copies of the three O'Neill's books that have been transcribed to ABC. O'Neill numbered the tunes in his books, and that number is the obvious X index. But if it wouldn't bother any software, it would be useful if I could augment it along the lines of: X:123 O'Neill's 1001 T:Young Francis Mooney ... X:123 O'Neill's 1850 T:Old Truagh ... X:123 O'Neill's Waifs T:Jackson's Silver Mines Note that in this case, having X:123 for each tune isn't a problem, as these tunes will never be in the same file - or even in the same directory - in my online collection. But still, it would be useful if the tune id stated right at the start which collection it is from. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] net-friendly information
On Thu 23 Aug 2001 at 12:43PM +0100, Richard Robinson wrote: On Fri, 17 Aug 2001, Jack Campin wrote: I have been looking round other people's transcriptions on the net over the last few days and I'm getting reminded of a few missing features of ABC that would make web-trawls for music more productive. - universal identifiers, along the lines of the Message-IDs used with email and Usenet postings. These tell you whether you've found another copy of something you've already got, and (if they have some internal structure, as Message-IDs usually do) can help direct you to the human who did the transcription or made it available. I wonder whether the X: line used for this, since I'm not sure what other use there is for it. Does any software currently use the X: line for anything (other than the ease-of-parsing start-of-tune marker) ? I think it was supposed to be a way of giving a unique id to each tune in a file ? Could it not be extended to give each tune a unique id on a system ? (and from there, add in machine info and get net-wide uniqueness ?). As Jack I think the safest way to extend the X: field would be leave a space after the number and then put your extension in e.g. X:5 fastpolkas.abc abc.sourceforge.net With a bit of luck, most software will read the number 5 and then ignore the rest of the line. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] net-friendly information
I have been looking round other people's transcriptions on the net over the last few days and I'm getting reminded of a few missing features of ABC that would make web-trawls for music more productive. - universal identifiers, along the lines of the Message-IDs used with email and Usenet postings. These tell you whether you've found another copy of something you've already got, and (if they have some internal structure, as Message-IDs usually do) can help direct you to the human who did the transcription or made it available. - checksums. These tell you whether you've got the tune or complete file the way the transcriber or uploader originally had it. - URLs. Not as useful as universal identifiers, because they're relatively transient, but they would usually help in tracing associated material for a few years after being disseminated. - keywords. Currently there is no way to search for music by intended instrument, genre, period, the performer it was associated with, range, or intended function (wedding march, mobile ringtone). Keywords can support that. This is the same sort of thing that HTML does with META tags. I suggest that we now allocate a field to these web-related functions, and like the META tag, specialize that field into subsidiary types later. These fields could occur either on their own in a file or within a tune header. A single file or tune could contain several of them. They would be one- line fields, each containing only information of a single subsidiary type. I suggest the subsidiary type information is represented in a similar way to META tags: typetag = data where typetag is a case-independent string composed of alphameric charcters or _ and the spaces around the = sign and next to the and signs are insignificant. The data field may have its own syntax dependent on the typetag. Examples: E:url = http://www.purr.demon.co.uk/jack/McLennan.abc or E:KEYWORD = accordion, musette, Viseur or E:ID = Evita/DontCryForMeArgentina/FullScore@TheReallyUsefulCompany where Sir Andrew would presumably have registered the part to the right of the @ sign somewhere to guarantee global uniqueness of the ID, with the part to the left being solely his responsibility (as with Message-IDs - this generally means using locally-generated sequence numbers somehow). As the E: field is not used by any currently supported software I propose we reallocate that. G would be another possibility, handily standing for global, but I believe that does still get *some* use, albeit in rather trivial ways. I've never seen either in a tune I've got off the net. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
