Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
| > I would like to see in BarFly is a "Save as standard abc" menu | > command. A text file would be saved (and displayed) that preserves | > as much of the active file as possible without using any features | > not found in the current standard. V: lines and whatever else | > would either be stripped or "commented out" (%). What would remain | > would be readable by any program that adhered to the standard, and | > would therefore be suitable for posting publicly. | | How would this command know, when dealing with a four-part harmonization | of a hymn, whether the tune was in the soprano or tenor line? | | I would have no use for this. When I violate the standard I know why | I'm doing it, and the "standard" version wouldn't express what I want. | I would rather post what I mean and leave it to the user to decide how | to handle it. It's not like these "violations" are easy - using the | "w:" feature is a hell of a lot of work and someone who's managed to | get a text underlay right is not just going to throw it all away again. | | The following is nonstandard in only one respect, the variable-length | gracenotes (I think fermatas are standard now?) They're an essential | part of the music and if ABC can't represent them, well, as Schoenberg | said when somebody told him his violin concerto was too difficult to | play, "I want the little finger to grow longer. I can wait." That's a great quote. Anyhow, I've added your example to my test directory. I've been seeing places where I'd really like to use lengths on grace notes, and I've been thinking of hacking this into abc2ps. It's hard to do Baroque music without long grace notes. But it probably won't be working tomorrow. I've looked at the code a bit, and it seems to me that what is needed is to just eliminate the current code that handles grace notes, and instead just treat them as ordinary notes that happen to be drawn smaller. Then of course we'll want an option to say how much smaller. This all could get a bit tricky, especially when you consider things like the alignment of notes in voices, where only the big notes would be aligned. Meanwhile, now that I have a sourceforge account, there's this little temptation to grab every version of abc2ps that I can find and look into merging them into a single source. I suspect that this might not be all that easy ... Your ``I know why I'm doing it, and the "standard" version wouldn't express what I want'' is a nice, clear summary of why so many of us are looking for extensions that others consider worthless. If you don't need something, then of course it's useless to you. But if you need it, the fact that someone else doesn't isn't much consolation. I now have quite a lot of files with w: lines. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
Laurie wrote: >I suspect that a greater problem lies in the finer detail. For instance >(not saying BF, Muse or any particular package does or does not >accept any of these things, they are just to give a feel) > I think BarFly will reject all of those, except for the long title, where it will simply ignore the second line. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
I suspect that a greater problem lies in the finer detail. For instance (not saying BF, Muse or any particular package does or does not accept any of these things, they are just to give a feel) instead of [K:] allow [K :] or [ K:] or [k:] or [ k : ], instead of [M:2/4] [Q:160] allow [M:2/4 Q:160] instead of [M:2/4] allow [M:2 / 4] instead of T:Imagine a title that's very long allow T:Imagine a title that's very long (and should that be formatted as 2 lines or 1 when printed?) instead of abc abc abc abc :|: def def def def allow abc abc abc abc :| :def def def def or abc abc abc abc : |:def def def def instead of ABC:|: DEF allow A B C: || : D E F or (with a much more interesting "false" scent) A B C: |: D E F and so on. These details have the potential for allowing music created by hand and "checked" by one package to be unacceptable to another. Believe me, I found *lots* of them out there on the web. Laurie - Original Message - From: Phil Taylor <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 18, 2000 12:17 AM Subject: Re: [abcusers] Modes, democracy and benevolent(?) dictatorship David Barnert wrote: >Just a little earlier in this thread, it occurred to me that what >I would like to see in BarFly is a "Save as standard abc" menu >command. A text file would be saved (and displayed) that preserves >as much of the active file as possible without using any features >not found in the current standard. V: lines and whatever else >would either be stripped or "commented out" (%). What would remain >would be readable by any program that adhered to the standard, and >would therefore be suitable for posting publicly. > It's an interesting idea. To guarantee* acceptability to all the other programs you need to go back to version 1.6. In order to reduce an abc to v1.6 the program would have to: * Remove any macro definitions from the tune headers. * Convert any notes with multiple slashes e.g. a// -> a/4 * Change M: none to M:4/4 (even if it's wrong). * Remove any clef specifications from the K: fields, and if that leaves a K: field in the tune empty, remove the field itself. * Convert any inline fields in the tune, placing them on a separate line. * Convert any w: lines to W:, removing any asterisks or underlines. * Remove any annotation text written as "^text" or "_text". * In multi voice abc, remove any V: fields in the header, strip out all voices other than V:1 and remove the V:1 field identifier from that. * Remove (or %comment out) any text between the tunes. (Well, the abc 1.6 definition doesn't mention that, but it does cause trouble for some programs.) Have I forgotten anything? The trouble is that if a file was made using all those features it probably really needed them, and stripping them out will result in a travesty of the original. I think the real trouble is not with the traditional dance tunes for which abc was invented, but with more complex music for which abc v1.6 is simply inadequate. * Actually not even v1.6 guarantees acceptability, since there are several ambiguities in it. I have a test file of 45 tunes which all conform to v1.6 AFAICS, but includes many examples of complex and difficult abcs. None of the programs I have tested (including BarFly) gets them all right. Phil Taylor 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] Modes, democracy and benevolent(?) dictatorship
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote: > Of course, this does run contrary to the other common approach, which > might be summarized "If the ABC has even a tiny error, you should > reject it, lest people be encouraged to keep making errors." The consequence of this is to support a »loose mode« as well as a »picky mode«. You use loose mode for stuff that comes in from elsewhere that doesn't pass in picky mode, and picky mode for stuff that you are going to send out that you want to be 100% conforming to the standard (or whatever). Anselm -- Anselm Lingnau . [EMAIL PROTECTED] Giving money and power to government is like giving whiskey and car keys to teenage boys. -- P. J. O'Rourke To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
> I would like to see in BarFly is a "Save as standard abc" menu
> command. A text file would be saved (and displayed) that preserves
> as much of the active file as possible without using any features
> not found in the current standard. V: lines and whatever else
> would either be stripped or "commented out" (%). What would remain
> would be readable by any program that adhered to the standard, and
> would therefore be suitable for posting publicly.
How would this command know, when dealing with a four-part harmonization
of a hymn, whether the tune was in the soprano or tenor line?
I would have no use for this. When I violate the standard I know why
I'm doing it, and the "standard" version wouldn't express what I want.
I would rather post what I mean and leave it to the user to decide how
to handle it. It's not like these "violations" are easy - using the
"w:" feature is a hell of a lot of work and someone who's managed to
get a text underlay right is not just going to throw it all away again.
The following is nonstandard in only one respect, the variable-length
gracenotes (I think fermatas are standard now?) They're an essential
part of the music and if ABC can't represent them, well, as Schoenberg
said when somebody told him his violin concerto was too difficult to
play, "I want the little finger to grow longer. I can wait."
X:1
T:Salute on the Birth of Rory Mor MacLeod
S:Kilberry Book of Ceol Mor #35
M:C
L:1/8
Q:1/4=80
K:Hp
P:Ground
{ge4d}B>{G}HB {G}B2 c3 B|{g}f>{e}f {e}Hf2 {g}f4 |\
{g}e2 {fege}f2 a3 e|{g}f>ea>e {g}f4 |
{g}B>f {g}e>B {GBG}c3 B|{g}f>{e}f {e}Hf2 {g}f4 |\
{g}e2 {fege}f2 a3 e|{g}f>ea>e {g}f4||
{g}fa {eAfA}e2 f3 c|{g}e2 {fege}f2 {ag}a4 |\
f>e a>e f3 c|{g}e<{A}He {A}e2 {g}He4||
{g}e2 {fege}f2 a3 e|{g}f>ea>e {g}f4 |\
{g}fa {eAfA}e2 f3 c|{g}e>f {g}e>f {ag}a4|]
===
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
David Barnert wrote: >Just a little earlier in this thread, it occurred to me that what >I would like to see in BarFly is a "Save as standard abc" menu >command. A text file would be saved (and displayed) that preserves >as much of the active file as possible without using any features >not found in the current standard. V: lines and whatever else >would either be stripped or "commented out" (%). What would remain >would be readable by any program that adhered to the standard, and >would therefore be suitable for posting publicly. > It's an interesting idea. To guarantee* acceptability to all the other programs you need to go back to version 1.6. In order to reduce an abc to v1.6 the program would have to: * Remove any macro definitions from the tune headers. * Convert any notes with multiple slashes e.g. a// -> a/4 * Change M: none to M:4/4 (even if it's wrong). * Remove any clef specifications from the K: fields, and if that leaves a K: field in the tune empty, remove the field itself. * Convert any inline fields in the tune, placing them on a separate line. * Convert any w: lines to W:, removing any asterisks or underlines. * Remove any annotation text written as "^text" or "_text". * In multi voice abc, remove any V: fields in the header, strip out all voices other than V:1 and remove the V:1 field identifier from that. * Remove (or %comment out) any text between the tunes. (Well, the abc 1.6 definition doesn't mention that, but it does cause trouble for some programs.) Have I forgotten anything? The trouble is that if a file was made using all those features it probably really needed them, and stripping them out will result in a travesty of the original. I think the real trouble is not with the traditional dance tunes for which abc was invented, but with more complex music for which abc v1.6 is simply inadequate. * Actually not even v1.6 guarantees acceptability, since there are several ambiguities in it. I have a test file of 45 tunes which all conform to v1.6 AFAICS, but includes many examples of complex and difficult abcs. None of the programs I have tested (including BarFly) gets them all right. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
For what it's worth, when I wrote Skink I decided to accept the 1.6 standard plus W: and w: and the Barfly decorations (T for trill, H for fermata, etc) as my first pass, and then add V: for the second release. Why? they seemed the most useful to me, as a user with fairly "non-esoteric" needs. wil Bob Archer wrote: > At 02:28 AM 17-10-00 +0100, Richard Robinson wrote: > > >Yes. I think we're both saying "six of one, half a dozen of the other", > >really, and the old "be liberal in what you accept and strict in what you > >output". And maybe that what's generated is more of a key to the situation > >than what's accepted. > > I am obviously not getting my point aross correctly. I've always been > slightly suspicious of the "be liberal in what you accept and strict in > what you output" rule, particularly when what you're accepting is, in many > cases, human generated. I agree that what is generated is the key, however > in the case of human generated abc, what is generated will be directtly > influenced by what the programs will accept, so being liberal in what you > accept leads to lots of non-standard abc. > > At 10:50 AM 17-10-00 +0100, Laurie Griffiths wrote: > > >Right - programs should accept the widest choice but generate standard ABC. > >BUT > >Think about Barfly. It doesn't generate at all. > >If it accepts mangled syntax then it encourages and legitimises such > >mangling > >If it refuses to, then it is "broken" - so it needs careful thought. > >And any other "input only" ABC program (e.g. one that just converts to > >tadpoles, or one that just plays) it has the same characteristic. > >I don't know what the answer is. > > This is exactly my point, and why I asked the question about what superset > of abc a new program writer would be advised to support. I notice that > nobody has answered that yet. > > Bob > > To subscribe/unsubscribe, point your browser to: >http://www.tullochgorm.com/lists.html -- Wil Macaulay email: [EMAIL PROTECTED] voice: +1-(905)-886-7818 xt2253FAX: +1-(905)-886-7824 Syndesis Ltd. 28 Fulton Way Richmond Hill, Ont Canada L4B 1J5 "... pay no attention to the man behind the curtain ..." To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
David Barnert wrote: | Just a little earlier in this thread, it occurred to me that what | I would like to see in BarFly is a "Save as standard abc" menu | command. A text file would be saved (and displayed) that preserves | as much of the active file as possible without using any features | not found in the current standard. V: lines and whatever else | would either be stripped or "commented out" (%). What would remain | would be readable by any program that adhered to the standard, and | would therefore be suitable for posting publicly. In particular, you can convert V: lines to P: lines fairly cleanly. The result doesn't look nearly as nice as what can be done with V: lines, but it does preserve the information, and is usable for playing the music on multiple instruments. Similarly, w: lines can be converted to W: lines with a small amount of editing, though this does lose the information of alignment with notes. Some other things, such as clefs, should probably be added as symbols to pass over without even a warning. Printing bass or alto as treble clef isn't ideal, and it's no way to impress your neighborhood bass player, but it is usable and does preserve the information. Hmmm ... Maybe I should try writing yet another small perl program. I have been considering augmenting my tune finder with some pages that give people several ways of trying to recover from strange ABC that the local tools (abc2ps and abc2midi) don't grok. The main issue is figuring out a good design for the web pages. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
Laurie wrote: >Right - programs should accept the widest choice but generate >standard ABC. >BUT >Think about Barfly. It doesn't generate at all. >If it accepts mangled syntax then it encourages and legitimises >such mangling If it refuses to, then it is "broken" - so it >needs careful thought. And any other "input only" ABC program >(e.g. one that just converts to tadpoles, or one that just >plays) it has the same characteristic. >I don't know what the answer is. Just a little earlier in this thread, it occurred to me that what I would like to see in BarFly is a "Save as standard abc" menu command. A text file would be saved (and displayed) that preserves as much of the active file as possible without using any features not found in the current standard. V: lines and whatever else would either be stripped or "commented out" (%). What would remain would be readable by any program that adhered to the standard, and would therefore be suitable for posting publicly. __ /\/\/\/\ <__> | | | | | David Barnert <__> | | | | | <[EMAIL PROTECTED]> <__> | | | | | Albany, N.Y. <__> \/\/\/\/ Ventilator Concertina Bellows Bellows (Vocation) (Avocation) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
Bob writes: | I am obviously not getting my point aross correctly. I've always been | slightly suspicious of the "be liberal in what you accept and strict in | what you output" rule, particularly when what you're accepting is, in many | cases, human generated. ... | | This is exactly my point, and why I asked the question about what superset | of abc a new program writer would be advised to support. I notice that | nobody has answered that yet. Well, if we combine the two ideas, we come up with a useful approach: Since one of ABC's major features is its accessibility to mere humans, easy to type and all that, you could examine the ABC that's Out There, especially tunes being posted to assorted mailing lists and newsgroups, and write your programs to understand (and if possible, silently correct) the common mistakes. Of course, this does run contrary to the other common approach, which might be summarized "If the ABC has even a tiny error, you should reject it, lest people be encouraged to keep making errors." It's really a question of how user-friendly you want to be. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
> "Bob" == Bob Archer <[EMAIL PROTECTED]> writes: Bob> This is exactly my point, and why I asked the question about Bob> what superset of abc a new program writer would be advised to Bob> support. I notice that nobody has answered that yet. I'd recommend the draft standard plus doing something with V: that looks like some widely used program. I wouldn't use a program that only implemented the standard -- too much of what I do uses either words or multiple voices or both. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org ) (Note the email and homepage address changes; please update your address book, bookmarks, and links.) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
At 02:28 AM 17-10-00 +0100, Richard Robinson wrote: >Yes. I think we're both saying "six of one, half a dozen of the other", >really, and the old "be liberal in what you accept and strict in what you >output". And maybe that what's generated is more of a key to the situation >than what's accepted. I am obviously not getting my point aross correctly. I've always been slightly suspicious of the "be liberal in what you accept and strict in what you output" rule, particularly when what you're accepting is, in many cases, human generated. I agree that what is generated is the key, however in the case of human generated abc, what is generated will be directtly influenced by what the programs will accept, so being liberal in what you accept leads to lots of non-standard abc. At 10:50 AM 17-10-00 +0100, Laurie Griffiths wrote: >Right - programs should accept the widest choice but generate standard ABC. >BUT >Think about Barfly. It doesn't generate at all. >If it accepts mangled syntax then it encourages and legitimises such >mangling >If it refuses to, then it is "broken" - so it needs careful thought. >And any other "input only" ABC program (e.g. one that just converts to >tadpoles, or one that just plays) it has the same characteristic. >I don't know what the answer is. This is exactly my point, and why I asked the question about what superset of abc a new program writer would be advised to support. I notice that nobody has answered that yet. Bob To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
Laurie Griffiths wrote: >Right - programs should accept the widest choice but generate standard ABC. >BUT >Think about Barfly. It doesn't generate at all. That's true in a sense, since BarFly is a text editor, and accepts any text you type into it and saves it without qualms. >If it accepts mangled syntax then it encourages and legitimises such >mangling >If it refuses to, then it is "broken" - so it needs careful thought. >And any other "input only" ABC program (e.g. one that just converts to >tadpoles, or one that just plays) it has the same characteristic. >I don't know what the answer is. I think the answer here lies in a graded response: BarFly offers several levels of error checking. It won't recognise abc tunes within the text unless they conform in a basic way - start with an X: field and contain a K: field followed by at least one line of music. In order to play a tune a whole lot of other features are required, and to display it as music a separate but similar set. Finally, there is an error checking mode which does things like making sure the bars all add up and catching minor infringements of syntax which don't prevent the tune from playing otherwise. With error checking off, it will play almost any abc you find on the net. Many of these tunes will display errors when you try to display them as music, and many more will fail the error checking mode. Users are advised to do all checks on tunes which they intend to upload. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
Right - programs should accept the widest choice but generate standard ABC. BUT Think about Barfly. It doesn't generate at all. If it accepts mangled syntax then it encourages and legitimises such mangling If it refuses to, then it is "broken" - so it needs careful thought. And any other "input only" ABC program (e.g. one that just converts to tadpoles, or one that just plays) it has the same characteristic. I don't know what the answer is. Laurie - Original Message - From: Richard Robinson <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 16, 2000 8:10 PM Subject: Re: [abcusers] Modes, democracy and benevolent(?) dictatorship On Mon, 16 Oct 2000, Bob Archer wrote: > To finish off with, I am going to restate my basic premise: > > The more variants of abc programs accept, the less useful abc is as an > exchange mechanism. Reductio ad absurdum: if abc programs accept no variants of abc they'll be universal exchange mechanisms. I don't have to re-edit (primarily) abc2win-generated abc because abc2ps _accepts_ the abc2win variant. I have to re-edit them because it _doesn't_. I think you must mean 'generate' ? -- 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 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
On Mon, 16 Oct 2000, Bob Archer wrote: > We have to be at some point on the sliding scale between the two extremes, > and that involves balancing things off against each other. In particular we > seem to have "usefulness as an exchange mechanism" pitted directly against > "allows programmers to innovate" at the moment - the classic dilemma for > all standards. I cant help thinking how thinks are working over at the GNU/LilyPond people. They have a language that seems to be in quite heavy evolution. The programmers change the language at will while working on the development version (this sounds chaotic, it's not at all that bad). So to fix that they have a language-converting-script included in that distribution which can convert files between version (or maybe only to newer versions??). Anyway for this to work you need to use the \version construct in you music code. Maybe it has been said before, but this suggest another approach to the multible version of on language problem. I don't know much about the implementation of the available abc prgrams. but one solution could be that each abc programmer supplied conversion to and from some central feature rich language (like lilyponds "mudela"). These algoritms could be fitted in one conversion tool which would solve the probmels of abc genrated with program X doesn't work with program Y. The downside could off course be that this would tempt programmers the care even less about conforming to the abc standard. But since this is already the case to some degree, it might be worth giving a thought. That said I know it's not me who's gonna spend my time implementing that conversion tool, so it's easy for my suggest, but here it is... -- Atte André Jensen To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
On Mon, 16 Oct 2000, Bob Archer wrote: > At 08:10 PM 16-10-00 +0100, Richard Robinson wrote: > >On Mon, 16 Oct 2000, Bob Archer wrote: > > > >> The more variants of abc programs accept, the less useful abc is as an > >> exchange mechanism. > > > >Reductio ad absurdum: if abc programs accept no variants of abc they'll be > >universal exchange mechanisms. > > > >I don't have to re-edit (primarily) abc2win-generated abc because abc2ps > >_accepts_ the abc2win variant. I have to re-edit them because it > >_doesn't_. > > My contention is essentially your Reductio ad absurdum, except I'm > expressing it as a sliding scale rather than as an absolute. As I said in > my previous post, there are two extremes - one where all software > implements the standard, no more and no less and the other where all of the > software ignores the standard completely. The first is impossible to > achieve, and is undesirable because of the lack of innovation allowed. The > second is undesirable because it makes abc unusable as an exchange mechanism. > > To come back to your example, I would state it as "You have to edit > abc2win-generated abc because abc2win does not generate standard conforming > abc". Yes. I think we're both saying "six of one, half a dozen of the other", really, and the old "be liberal in what you accept and strict in what you output". And maybe that what's generated is more of a key to the situation than what's accepted. > Again, I think that speed of updating the standard is critical to finding > the right balance point. Yes. -- 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] Modes, democracy and benevolent(?) dictatorship
At 08:10 PM 16-10-00 +0100, Richard Robinson wrote: >On Mon, 16 Oct 2000, Bob Archer wrote: > >> To finish off with, I am going to restate my basic premise: >> >> The more variants of abc programs accept, the less useful abc is as an >> exchange mechanism. > >Reductio ad absurdum: if abc programs accept no variants of abc they'll be >universal exchange mechanisms. > >I don't have to re-edit (primarily) abc2win-generated abc because abc2ps >_accepts_ the abc2win variant. I have to re-edit them because it >_doesn't_. > >I think you must mean 'generate' ? No, I meant accept, although the argument can also apply to generate. I might not have explained it very well though - I was also thinking more of human writers of abc than programs. I stated my full argument some time ago on here and got no response, so I decided not to repeat it in that post. I'll have another go. I am going to assume that many people who use abc also use some piece of software that reads abc. Whilst I am sure there are people out there who just use abc to scribble down a tune on a bit of paper and then transfer it directly to staff notation I am not considering them in this argument. If a program allows a feature of abc to be used, users will use that feature, whether or not that feature appears in the standard. Most users probably won't care if that feature appears in the standard - all they want is to get something working with their particular abc program. Some of these users will put their abc up on the net, other users will download that abc which might or might not work with their abc software. This leads to exactly what we have now. A body of abc tunes, some of which use features that are not in the standard and are not available on all abc software. My experience is that computer users will do whatever they are allowed to get away with - I don't even mean this in a negative way, it is just the way the world is. If the programs accept non-standard abc that's what we will end up with. My contention is essentially your Reductio ad absurdum, except I'm expressing it as a sliding scale rather than as an absolute. As I said in my previous post, there are two extremes - one where all software implements the standard, no more and no less and the other where all of the software ignores the standard completely. The first is impossible to achieve, and is undesirable because of the lack of innovation allowed. The second is undesirable because it makes abc unusable as an exchange mechanism. We have to be at some point on the sliding scale between the two extremes, and that involves balancing things off against each other. In particular we seem to have "usefulness as an exchange mechanism" pitted directly against "allows programmers to innovate" at the moment - the classic dilemma for all standards. To come back to your example, I would state it as "You have to edit abc2win-generated abc because abc2win does not generate standard conforming abc". Again, I think that speed of updating the standard is critical to finding the right balance point. Bob To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
On Mon, 16 Oct 2000, Bob Archer wrote: > To finish off with, I am going to restate my basic premise: > > The more variants of abc programs accept, the less useful abc is as an > exchange mechanism. Reductio ad absurdum: if abc programs accept no variants of abc they'll be universal exchange mechanisms. I don't have to re-edit (primarily) abc2win-generated abc because abc2ps _accepts_ the abc2win variant. I have to re-edit them because it _doesn't_. I think you must mean 'generate' ? -- 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] Modes, democracy and benevolent(?) dictatorship
At 06:48 AM 16-10-00 -0700, [EMAIL PROTECTED] wrote: > > > Bryan writes: > >| I will, but as I have said, abc is useless as an exchange medium if we ar= >| e=20 >| not all talking the same language. > >Well, now, it seems to me that this is disproved by even a casual >glance at the current situation. There is a fairly significant range >of discrepancy in how various abc tools implement various parts of >the notation. If the above were true, then abc as it is now would be >useless. But a lot of people are finding it very useful. Without wishing or trying to speak for Bryan, I think this misses the point of what Bryan was saying (or at least my interpretation of what Bryan was saying). He wasn't saying that "abc is useless", instead he was saying that "abc is useless as an exchange medium". Personally I wouldn't use the word "useless", but I would claim that the more variants of abc programs accept, the less useful abc is as an exchange mechanism. That doesn't stop abc being useful for a person who always uses the same program, or even a group of people who all agree to use the same program, but if we want a variety of programs to accept abc input there needs to be some idea of a standard, and developers need to make their programs stick to the standard to at least some minimal extent. Unless my memory has failed me completely, there have been plenty of postings on this list about people having to edit some abc they've downloaded because it was created to work with program X, and is now being fed into program Y. >The claim that abc must be a consistenly-implemented standard is a >red herring. This isn't true at all, just as it isn't true for any of >the other standards in the computing industry. Standards are never >implemented consistently by different developers. And some >widely-used tools (such as unix ;-) have radically different >implementations on different platforms, while still being very >useful. > >This isn't just ranting. Claiming that we *MUST* all step to the same >drummer is actually a way of suppressing innovation. If ABC is kept >in a little box and developers are discouraged from experimenting >with extensions, then it will be forever frozen at its current state. >It will remain useful for a few kinds of music, but will never >develop into a more generally useful notation. This is taking an extreme view of the situation (and a view that I don't think anyone has yet proposed). I could put forward the opposite extreme - that developers just go off and do whatever they want, every developer experiments with whatever extensions they like and we end up with a whole batch of incompatible input languages. Neither extreme is a particularly healthy situation - somewhere in the middle there needs to be a balance. Part of the balance involves having a standard that is extended in useful ways and can be quickly updated if necessary. Unfortunately that takes a lot of work and consensus building (assuming we're not going for the dictator model). >Keeping abc in a straightjacket by insisting that we must all be >talking the same language will in the long run be fatal, and will >relegate abc to the fringe. That may be the intention of some. But >there are a lot of kinds of music in this world, and musicians don't >talk the same language at all. I'd rather see abc continue to develop >as a user-accessible, emailable music notation that more musicians >can use. This requires that we accept variations and extensions, and >that we discuss them with the idea of developing ABC into a more >widely-usable notation. Again, this is taking an extreme view - I don't think anyone is out to "relegate abc to the fringe" and I don't think the implicit accusation helps the debate in any way. I have a question which I think is relevant to this debate: If a new developer were to start writing a program to accept abc input now, which version of abc should they accept as input? Should they stick to the currently published standard? maybe the draft standard? Should they attempt to handle all of the abc variants out there? (this would involve getting the instructions for a number of different programs and finding out what they accept). If they tried to accept many abc variations should they then attempt to keep their program up to date with changes to the other programs - I can see a situation where an extension implemented in program X causes a wave of changes in other programs to implement the extension. What should they do if two programs have incompatable extensions? To finish off with, I am going to restate my basic premise: The more variants of abc programs accept, the less useful abc is as an exchange mechanism. Bob To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
Bryan writes: | I will, but as I have said, abc is useless as an exchange medium if we ar= | e=20 | not all talking the same language. Well, now, it seems to me that this is disproved by even a casual glance at the current situation. There is a fairly significant range of discrepancy in how various abc tools implement various parts of the notation. If the above were true, then abc as it is now would be useless. But a lot of people are finding it very useful. The claim that abc must be a consistenly-implemented standard is a red herring. This isn't true at all, just as it isn't true for any of the other standards in the computing industry. Standards are never implemented consistently by different developers. And some widely-used tools (such as unix ;-) have radically different implementations on different platforms, while still being very useful. This isn't just ranting. Claiming that we *MUST* all step to the same drummer is actually a way of suppressing innovation. If ABC is kept in a little box and developers are discouraged from experimenting with extensions, then it will be forever frozen at its current state. It will remain useful for a few kinds of music, but will never develop into a more generally useful notation. ABC was a very useful start on a simple, human-readable and emailable music notation. It was limited, and saying this is no criticism of Chris's work. Good tools often start off simple and limited, and grow with time to include new capabilities. But this growth hardly ever happens with a central dictatorial control. It happens if you have a lot of interested developers who feel they have the freedom to try out new ideas and present them to the user community. Keeping abc in a straightjacket by insisting that we must all be talking the same language will in the long run be fatal, and will relegate abc to the fringe. That may be the intention of some. But there are a lot of kinds of music in this world, and musicians don't talk the same language at all. I'd rather see abc continue to develop as a user-accessible, emailable music notation that more musicians can use. This requires that we accept variations and extensions, and that we discuss them with the idea of developing ABC into a more widely-usable notation. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
> ... > http://members.aol.com/LewesArmsFolk/Lewesfav.html. > ... > Bryan Lewes. I do hope that you have avoided or survived the floods without damage. Laurie To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
At 09:41 PM 10/15/2000 EDT, you wrote: > >http://members.aol.com/LewesArmsFolk/Lewesfav.html. It appears on the abc >homepage under abc collections as "Favourite English dance tunes from the >Lewes sessions, Sussex". I'd like this to be accessible to other people's >software. That being the case, Brian, then the first thing I'd do is put those abcs out on the site in plain text format, rather than, or at least in addition to the zipped files. Every site I've seen listed on the ABC index on Chris Walshaw's site has the notation out in plain text, and there are some good reasons for doing it that way. If you made your tunes available in plain text, they'd be easily searchable by the same means that everyone else's are. Second, it would give visitors the option of downloading the specific tunes they want, rather than an entire file. Just as an aside, there is another perspective on the "democracy" question that you've been steadfastly ignoring, which I feel needs to be pointed out by someone who isn't one of the developers: these folks who work on these programs generously *donate* their time to it. They are volunteers, they put in whatever time they can, when they can, and should be applauded for that, not subjected to ridicule, abuse and per- sonal attacks. If you are running into resistance, perhaps you should consider that in many of your posts, your tone has been, er, somewhat less than respectful. Wendy To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Modes, democracy and benevolent(?) dictatorship
Phil Taylor says - > Any system of democracy involves a franchise: there are always some people > who are entitled to vote and some who are not. We don't allow children, > criminals, lunatics or the Queen to elect our politicians I'm sure "the vast majority of users" will be glad to know the high regard you hold them in. (Bags I be Queen first.) > Now if you don't like that Bryan, you know what you can do. Well, if I do write some more software (I think that's what you meant) please bear in mind that you will have as little influence on mine as I do on yours and, since I WILL be taking notice of what the vast majority of users want, I may have more influence than you'd like. I am reluctant to respond to John Atchley's posting because he will only accuse me of more whining but here goes. It is precisely because all the people you mention have made such important contributions to abc software development that I have tried to present my case with reasoned arguments rather than going it alone as you recommend. > And then there is Bryan, whose first and so far only contribution to the > abc user community is a program that will tell us when our abc notation is > "wrong." Come on! Everybody has to start somewhere, and my ABCchecker doesn't tell you when things are "wrong", it tells you when they don't conform to the standard. If something you want doesn't appear in the standard, campaign to get it put in. That was part of the point of the exercise. > I don't think there is a developer on this list who wouldn't love to see a > responsive and flexible, but concrete and comprehensive, abc standard. Maybe, they just don't seem to be prepared to do anything to bring this about. Chris Walshaw (who invented abc, remember?) has published a draft standard and says "A new version of the standard is under discussion on the abcusers mail list". I don't seem to have seen much constructive input. > As Phil pointed out, there is a sort of informal democratic process at work > in the development of the abc standard. I don't think Phil is into informal processes. His style is more laying down the law. His idea of democracy is "Lets all agree to do what I say." > If you want to vote, then write some software, I think every abc user should have an equal right to vote whether they have written any software or not (actually, I have, remember?). > or convince a developer that your desire is reasonable. What the ^&£$*@# do you think I've been trying to do? I've been met with intransigence, misrepresentation, "We know best!" and downright abuse all the way. > Bryan, if the K:^f syntax is so important to you, then begin using it. Well, I've already been given a ticking off by one who identified themselves with WE for trying to implement something that wasn't supported by abc2win. Now you seem to be telling me that that is exactly what I should do. Laurie Griffiths suggested that I use my Noteworthy to abc conversion programme to produce abc files unreadable by any other software, but at least he knew he was being sarcastic. > write some software of your own that uses it. I will, but as I have said, abc is useless as an exchange medium if we are not all talking the same language. > Add it to your abc source checker, having it print a warning that it is not yet > adopted in the standard. I already have. > Use it in the copious amounts of abc notation that you are transcribing and > contributing to the user community (what was that URL, BTW?) http://members.aol.com/LewesArmsFolk/Lewesfav.html. It appears on the abc homepage under abc collections as "Favourite English dance tunes from the Lewes sessions, Sussex". I'd like this to be accessible to other people's software. > If you are right, and there is sufficient demand for the syntax, other developers will > follow you and John Chambers and begin incorporating it into their software. Well, Phil Taylor believes that "the vast majority of users" would use it and this is (part of) his reason for opposing it becoming part of the standard. > At that point, like the V: syntax, it will matter little whether > it is in the standard; for better or worse it will have become a defacto > part of the language. But V: is not a defacto part of the language. It is used by a limited number of packages and will continue to be so until a precise syntax definition is availabe, preferably as part of the standard. > If Phil objects that's his problem. It certainly is. > Instead of arguing and whining, just press on. I would rather arrive at concensus of opinion. "Pressing on" produces a discoordinated shambles. > Of course, if you want to produce midi output from your abc you'll have to invest as > much time and energy as he and the other developers on this list by writing a > midi player that handles the syntax. When you prove yourself willing to do > that, the rest of us might take your recommendations a bit mo
