Re: [abcusers] Re: %%ABC 2.0 identifier
From: "Jeff Bigler" <[EMAIL PROTECTED]>
> The !...! commands, whether we like them or not, work this way.
> Regardles of whether the syntax ends up being !...!, +...+ or
whatever,
> the standard could (and IMO should) specify that new fields that
are not
> part of the standard must be enclosed between appropriate
delimiters, so
> that software that doesn't know how to interpret these fields can
easily
But as discussed earlier to avoid clashes of the same text used
differently by different abc users/developers we need something
broadly of the form
+namespace:whatever+
and
%%namespace:whatever
where "namespace" could be mozart (for me) barfly (for Phil) etc etc
etc and would make it less likely that clashes between different
usages of the same text ("whatever") would occur. Colon-free
entries (in this proposal) would be the standard abc namespace for
which a very specific set of allowed "whatever"s would be (are)
defined in the spec.
I can also see a case for allowing a very general syntax for all
header fields
V:... keyword=value keyword=value
where again keyword is from a very specific set defined in the ABC
standard OR is of the form namespace:whatever for user defined
enhancements.
The only required rule would be that the music has to make syntactic
sense if any of the namespace items is ignored.
Dave
David Webber
Author of MOZART the music processor for Windows -
http://www.mozart.co.uk
Member of the North Cheshire Concert Band
http://www.northcheshire.org.uk
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
I'm catching up on old email. Sorry if this has already been addressed. > Date: Fri, 18 Jul 2003 13:03:20 -0400 > From: Steven Bennett <[EMAIL PROTECTED]> > The key is to define user fields in such a way that they can be safely > ignored by computer programs trying to parse the file I think this is one of the more important points in this discussion. I think ABC needs this. In HTML, anything in <> is a command. Any command the browser doesn't understand gets ignored. While HTML isn't a perfect system, it is nice to have a simple method of communicating to the program, "This is a command. Interpret it if you can; otherwise ignore everything up to the end-of-command delimiter." The !...! commands, whether we like them or not, work this way. Regardles of whether the syntax ends up being !...!, +...+ or whatever, the standard could (and IMO should) specify that new fields that are not part of the standard must be enclosed between appropriate delimiters, so that software that doesn't know how to interpret these fields can easily determine the extent of what it needs to ignore. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
ANewman wrote: >> I've seen a lot of the uses of >> abc mixed with text > >I thought the H: line was for just that purpose. It is the only field >other than W: that allows multiple continued lines that are freeform >(until the next header). Can't people just use this? > >I agree that text in the middle of ABC tunes is a hassle since it is very >difficult (for the parser) to distinguish from actual ABC. Not text in the middle of an abc tune - abc tunes embedded in text. It's very useful if you are writing about music to be able to put illustrations in. We do it all the time on this list, but for a longer example see Jack Campin's modes tutorial. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
> I've seen a lot of the uses of > abc mixed with text I thought the H: line was for just that purpose. It is the only field other than W: that allows multiple continued lines that are freeform (until the next header). Can't people just use this? I agree that text in the middle of ABC tunes is a hassle since it is very difficult (for the parser) to distinguish from actual ABC. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
On Thu, 24 Jul 2003 [EMAIL PROTECTED] wrote: > If you read carefully what I wrote, you will > understand that the point I was trying to get over > was that the principle of a standard is to unify abc > regardless of its origin. I don't want to have to > use a different set of parsing rules depending on the > origin of the file. On the contrary, the upcomming standard will recommend parsers to read ABC as liberal as possible, so that one parser can parse as much ABC as is reasonably possible. On the other hand, the standard urges programs that _write_ ABC to do that as strictly as possible, with as much information as possible. > Then why are you saying what applications MUST do? I agree the wording was too strong. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Re: %%ABC 2.0 identifier
Irwin Oppenheim wrote - >On Wed, 23 Jul 2003 [EMAIL PROTECTED] wrote: > >> Must? What are you going to do if they don't? > >Please read carefully what I wrote. Then you will >understand, that: > >1/ Users are not required to manually add any of these >new fields to their ABC files at all. > >2/ Programs that import ABC files should not assume >that any of these files are present. > >3/ The only requirement that I made is that programs >that _export_ ABC notation, should add three fields to >their output, that make it possible to identify later >on which program generated the output, according to >which version of ABC. That's all. I have looked through the email I was quoting from and can find nothing corresponding to points 1/ and 2/. In 3/ you have modified "must" to "should"; an improvement. If you read carefully what I wrote, you will understand that the point I was trying to get over was that the principle of a standard is to unify abc regardless of its origin. I don't want to have to use a different set of parsing rules depending on the origin of the file. That is no improvement on the situation we have now. >> It is up to the developer to make it clear what >> subset of the standard they do implement then the >> user can make their choice and pester for the things >> they want. > >Nobody disagrees on that. Then why are you saying what applications MUST do? A a further point, you are defining %% commands as mandatory parts of the standard whereas their current usage is application dependant in such a way that they can be safely ignored by other applications. They are thus, by definition, not part of the standard. Bryan Creer
Re: [abcusers] Re: %%ABC 2.0 identifier
On Wed, 23 Jul 2003 [EMAIL PROTECTED] wrote: > Must? What are you going to do if they don't? Please read carefully what I wrote. Then you will understand, that: 1/ Users are not required to manually add any of these new fields to their ABC files at all. 2/ Programs that import ABC files should not assume that any of these files are present. 3/ The only requirement that I made is that programs that _export_ ABC notation, should add three fields to their output, that make it possible to identify later on which program generated the output, according to which version of ABC. That's all. > It is up to the developer to make it clear what > subset of the standard they do implement then the > user can make their choice and pester for the things > they want. Nobody disagrees on that. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Re: %%ABC 2.0 identifier
Irwin Oppenheim wrote - >Applications which extract separate tunes from a file, >must insert the fields of the original file header, >into the header of the extracted tune. >Software that exports ABC tunes conforming to this >standard, must include a version field. >Software that exports ABC tunes conforming to this >standard, must include a creator field. Must? What are you going to do if they don't? What about the existing abc files? One of the strengths of abc is that you don't need any specialist software at all; you can write it using a simple text editor (or pen and paper for that matter). How are you going to get Microsoft Notepad to conform to this standard? If I Copy and Paste a tune from an abc file into an email how is the operating system supposed to extract data from the file header? Surely an abc standard shouldn't be about software, it should be about abc. It should define what abc is. What software does is up to the developer under pressure from their users. As Guido said a while ago - >That said, programs don't necessarily have to comply to 1.7.6 or 2.0.0 or >3.1415. Many users are happy with single-voice ABC, so programs targeting >these users may be left untouched. But what about we classical musicians, >who need more? What's more important, so-called standards or people's >needs? No application is likely to be a complete implementation of any version of the standard. It is up to the developer to make it clear what subset of the standard they do implement then the user can make their choice and pester for the things they want. Bryan Creer
Re: [abcusers] Re: %%ABC 2.0 identifier
On Wed, 23 Jul 2003, Steven Bennett wrote: > What I meant to say is that there should be no ABC2 > data outside the context of an individual tune inside > a file. Each ABC2 tune should be capable of being > parsed outside the context of the file it's in. This is also dealt with in the upcomming standard. I quote: << The file may optionally start with a file header, which is a block of consecutive field lines, finished by a blank line. The file header may be used to set default values for the tunes in the file. Such a file header may only appear at the beginning of a file, not between tunes. Of course, tunes may override the file header settings. However, when the end of a tune is reached, the defaults set by the file header are restored. Applications which extract separate tunes from a file, must insert the fields of the original file header, into the header of the extracted tune. It is legal to write free text between the tunes of a tunebook. The free text should be separated from the surrounding tunes by blank lines. Programs that are able to print tunebooks, will print the text between the tunes. The free text may be interspersed with directives (see section ABC Stylesheet specification) or with Extended information fields; however, the scope of these settings is limited to the text that appears up to the beginning of the next tune. At that point, the defaults set by the file header are restored. Each line in the file may begin or end with blank space which will be ignored. For the purpose of this standard, ASCII Tab and ASCII Space characters are equivalent and are both designated with the term `space.' Applications must be able to interpret end-of-line markers in Unix (^J), PC (^M^J), and Macintosh style (^M) correctly. >> > I *do* think the %%ABC2 tag on each compliant tune, > or something similar, is needed. Also dealt with. I quote: << Version field Example: %%abc-version 2.0 Software that exports ABC tunes conforming to this standard, must include a version field. Later occurrences of the version field, override earlier ones. >> and what about this one: << Creator field Example: %%abc-creator xml2abc 2.7 The creator field contains the name of the program that created the ABC file, followed by the version number of the program. Software that exports ABC tunes conforming to this standard, must include a creator field. Later occurrences of the creator field, override earlier ones. >> Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
Phil Taylor wrote: >> (IMHO, >> there should be NO data in an ABC2 file which exists outside the context of >> the current tune -- I don't know if anyone else agrees with this, but it >> makes the most sense to me...) > > I have to disagree. One very useful feature of abc is the possibility > of embedding abc tunes in other text. This makes it a fine tool for > writing about music. See Jack Campin's tutorial on modes in Scottish > music for a good example of this. Oops. I see I really phrased that one wrong. I've put ABC tunes embedded inside emails myself. What I meant to say is that there should be no ABC2 data outside the context of an individual tune inside a file. Each ABC2 tune should be capable of being parsed outside the context of the file it's in. Unfortunately, doing so means more or less doing away with the file header support, or at least disallowing any field that's affects how the tune is processed. (ie. M:, m:, R:, T:, U:) But I expect there would be quite a bit of resistance to that idea, which is why it's just an opinion, and not something I was suggesting we actually do. I *do* think the %%ABC2 tag on each compliant tune, or something similar, is needed. And given we have the file header anyway, I could accept a compromise that the %%ABC2 tag could be placed in the header and thus apply to all tunes in the file. The header has to be copied out anyway whenever you break a tune out of a file, so that's not a big deal. >> (Which reminds me -- is >> there ANY other open source parser out there other than the several dozen >> variants of the ones in ABC2PS and ABCM2PS? I'd like to look at one, >> especially an object oriented one if one exists...) > > There's the parser used in abc2midi and yaps, but it's ansi C not C++. Thanks, I'll look at them. C++ isn't necessary - I used to be a big C++ advocate but now I *much* prefer Objective-C. -->Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
On Tue, Jul 22, 2003 at 07:11:05PM -0400, Steven Bennett wrote: > > ... (IMHO, > there should be NO data in an ABC2 file which exists outside the context of > the current tune -- I don't know if anyone else agrees with this, but it > makes the most sense to me...) > > > (2) A surprisingly large proportion of users type their abc directly > > in a text editor. There's no way you can make these people include > > the identifier. They mostly won't bother, and if their software enforces > > it they'll prefer to use a program which doesn't. > > Which is why I suggest it as part of a new ABC 2.0 standard. If *all* > programs which support ABC 2.0 need that line, then people will use it when > writing new tunes to that format. It's not like typing "%%ABC2" at the > start of your tune is a particularly onerous or time consuming task. It's be a lot less onerous to type it once at the head of the file and let the existing rules for "global" headers stand. If new software insists on things that people don't particularly want to do, they might just not use it. > > The issue with XML is you end up with something trivial to parse, but nearly > impossible to write without machine assistance. The main reason I like ABC > (and I suspect others do also) is it's relatively easy to type in music in > that format. Same here. > should be as bloody difficult as it currently is. (Which reminds me -- is > there ANY other open source parser out there other than the several dozen > variants of the ones in ABC2PS and ABCM2PS? I'd like to look at one, > especially an object oriented one if one exists...) There's also the abcMIDI one. -- Richard Robinson "The whole plan hinged upon the natural curiosity of potatoes" - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
Steven Bennett wrote: >Phil Taylor wrote: > >> To return to the original suggestion in the title of this thread, it >> has been suggested many, many times before. One of the first postings >> I ever made to this list (or was it the developer's list?), made >> exactly the same suggestion - for goodness sake lets write the version >> of abc used in this file at the start so programs know what they have >> to deal with. It's a great idea, but it won't work because: >> >> (1) The fundamental unit of abc data is not the file, it's the tune. >> ... [snip] >> So the identifier would have to be added to individual tunes to be >> useful, rather than go in the file header. > >I fully agree with you. My suggestion is exactly that - this belongs in the >header of each tune, and in fact, might be best defined as the first line of >a new tune, making it a much more easily identifiable tune break. (IMHO, >there should be NO data in an ABC2 file which exists outside the context of >the current tune -- I don't know if anyone else agrees with this, but it >makes the most sense to me...) I have to disagree. One very useful feature of abc is the possibility of embedding abc tunes in other text. This makes it a fine tool for writing about music. See Jack Campin's tutorial on modes in Scottish music for a good example of this. >> (2) A surprisingly large proportion of users type their abc directly >> in a text editor. There's no way you can make these people include >> the identifier. They mostly won't bother, and if their software enforces >> it they'll prefer to use a program which doesn't. > >Which is why I suggest it as part of a new ABC 2.0 standard. If *all* >programs which support ABC 2.0 need that line, then people will use it when >writing new tunes to that format. It's not like typing "%%ABC2" at the >start of your tune is a particularly onerous or time consuming task. I dunno. Some people can't even bother typing in the X: field at present. >> If you really want to write an abc parser, you will have to get your >> head round the idea that abc is not a computer language, it's a >> natural language (albeit a very simple and regular one, with very >> few dialects). It makes writing a parser a much more interesting >> task. If you want an easy (to the point of being boring) job, write >> a MusicXML parser. > >The issue with XML is you end up with something trivial to parse, but nearly >impossible to write without machine assistance. The main reason I like ABC >(and I suspect others do also) is it's relatively easy to type in music in >that format. Very true. It's also (surprisingly) much easier to debug an abc parser than an XML parser, just because it's so hard to find your way around those huge files (an error on line 3 is much easier to locate than one on line 2872). >Unfortunately, ABC as it exists now has indeed become a natural language, >and that limits it's usefulness immensely in the computer world. And I beg >to differ about "few" dialects -- as near as I can tell, there are at least >as many dialects as there are programs to handle ABC, and from comments here >on this list, I suspect there are even more than that. I meant few compared with English or French:-) >I have no problem developing a complex parser -- I've done that plenty of >times before, but developing one from scratch which has to deal with >multiple conflicting rules and absolutely no means of identifying which rule >applies, is absolutely no fun at all. Writing a parser isn't the goal - >it's a necessary step in creating a new program, and there's no reason it >should be as bloody difficult as it currently is. (Which reminds me -- is >there ANY other open source parser out there other than the several dozen >variants of the ones in ABC2PS and ABCM2PS? I'd like to look at one, >especially an object oriented one if one exists...) There's the parser used in abc2midi and yaps, but it's ansi C not C++. >Maybe I should be proposing that the new standard not be called "ABC 2.0" at >all, but something entirely different. It would still be the same goal -- >establishing a truly standard computer-readable dialect of ABC, but by >changing the name, it loses the baggage that name currently carries... Yes it used to drive me mad too. But abc as it stands at present isn't going to go away, and while a new, strict language is undeniably attractive to programmers it may well prove to be much less so to the public at large. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
John Chambers writes: | On Tue, Jul 22, 2003 at 07:11:05PM -0400, Steven Bennett wrote: | > | > ... (IMHO, | > there should be NO data in an ABC2 file which exists outside the context of | > the current tune -- I don't know if anyone else agrees with this, but it | > makes the most sense to me...) | | While I usually have pure abc files, I've seen a lot of the uses of | abc mixed with text. You see it all the time on some musical mailing | lists. As part of a discussion, someone includes a tune or three in | abc form. It's really convenient to be able to take the message, feed | it unaltered to abc2ps, and see the staff notation. | | Of course, it doesn't always work out that well. Long lines get | wrapped, and it looks really stupid on the screen. So you have to go | back, edit the message, and try again. And people don't always | remember to put a blank line after the tune, producing a bit of extra | "modern" music at the end. But a lot of the time, it works just fine. I forgot to include the really big annoyance with abc tunes embedded in email text: People have this way of putting most of the info in the English text. Then, if I want to add it to my collection, I have to go in and edit the text into abc header lines and move them into the tune. Since I always want to have interesting info in the abc, this is a lot of extra work. But it doesn't do any good to complain; people just keep doing it. I can easily write code to generate a missing X: line, but extracting the info from English is a LOT more difficult. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
On Tue, Jul 22, 2003 at 07:11:05PM -0400, Steven Bennett wrote: > > ... (IMHO, > there should be NO data in an ABC2 file which exists outside the context of > the current tune -- I don't know if anyone else agrees with this, but it > makes the most sense to me...) While I usually have pure abc files, I've seen a lot of the uses of abc mixed with text. You see it all the time on some musical mailing lists. As part of a discussion, someone includes a tune or three in abc form. It's really convenient to be able to take the message, feed it unaltered to abc2ps, and see the staff notation. Of course, it doesn't always work out that well. Long lines get wrapped, and it looks really stupid on the screen. So you have to go back, edit the message, and try again. And people don't always remember to put a blank line after the tune, producing a bit of extra "modern" music at the end. But a lot of the time, it works just fine. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
Phil Taylor wrote: > To return to the original suggestion in the title of this thread, it > has been suggested many, many times before. One of the first postings > I ever made to this list (or was it the developer's list?), made > exactly the same suggestion - for goodness sake lets write the version > of abc used in this file at the start so programs know what they have > to deal with. It's a great idea, but it won't work because: > > (1) The fundamental unit of abc data is not the file, it's the tune. > ... [snip] > So the identifier would have to be added to individual tunes to be > useful, rather than go in the file header. I fully agree with you. My suggestion is exactly that - this belongs in the header of each tune, and in fact, might be best defined as the first line of a new tune, making it a much more easily identifiable tune break. (IMHO, there should be NO data in an ABC2 file which exists outside the context of the current tune -- I don't know if anyone else agrees with this, but it makes the most sense to me...) > (2) A surprisingly large proportion of users type their abc directly > in a text editor. There's no way you can make these people include > the identifier. They mostly won't bother, and if their software enforces > it they'll prefer to use a program which doesn't. Which is why I suggest it as part of a new ABC 2.0 standard. If *all* programs which support ABC 2.0 need that line, then people will use it when writing new tunes to that format. It's not like typing "%%ABC2" at the start of your tune is a particularly onerous or time consuming task. > If you really want to write an abc parser, you will have to get your > head round the idea that abc is not a computer language, it's a > natural language (albeit a very simple and regular one, with very > few dialects). It makes writing a parser a much more interesting > task. If you want an easy (to the point of being boring) job, write > a MusicXML parser. The issue with XML is you end up with something trivial to parse, but nearly impossible to write without machine assistance. The main reason I like ABC (and I suspect others do also) is it's relatively easy to type in music in that format. Unfortunately, ABC as it exists now has indeed become a natural language, and that limits it's usefulness immensely in the computer world. And I beg to differ about "few" dialects -- as near as I can tell, there are at least as many dialects as there are programs to handle ABC, and from comments here on this list, I suspect there are even more than that. I have no problem developing a complex parser -- I've done that plenty of times before, but developing one from scratch which has to deal with multiple conflicting rules and absolutely no means of identifying which rule applies, is absolutely no fun at all. Writing a parser isn't the goal - it's a necessary step in creating a new program, and there's no reason it should be as bloody difficult as it currently is. (Which reminds me -- is there ANY other open source parser out there other than the several dozen variants of the ones in ABC2PS and ABCM2PS? I'd like to look at one, especially an object oriented one if one exists...) Maybe I should be proposing that the new standard not be called "ABC 2.0" at all, but something entirely different. It would still be the same goal -- establishing a truly standard computer-readable dialect of ABC, but by changing the name, it loses the baggage that name currently carries... -->Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
Steven Bennett wrote: >ABC is *both* a musical notation format, and a computer standard. At least >according to the docs, and the history of this thing, it developed as a >means of writing tunes in a format that could be understood and printed by a >computer, and that appears to be it's primary purpose. If you want to write >something that's readable primarily by humans, there are already plenty of >non-computer notations to do it in. Well, no. Actually Chris Walshaw invented abc when he was on holiday in France, encountered some French musicians with interesting tunes, and lacked manuscript paper to write them down. So he just wrote the names of the notes along with a multiplier for the length as necessary, and a bit of header information required to read the rest. Later, faced with a pile of scraps of paper with tunes written in text he wrote the first version of abc2mtex as a way of converting this material to conventional musical notation. So it definitely started life as a musical notation, and computer considerations came later. To return to the original suggestion in the title of this thread, it has been suggested many, many times before. One of the first postings I ever made to this list (or was it the developer's list?), made exactly the same suggestion - for goodness sake lets write the version of abc used in this file at the start so programs know what they have to deal with. It's a great idea, but it won't work because: (1) The fundamental unit of abc data is not the file, it's the tune. Tunes get pulled from their original files and added to new files all the time. There are large and important collections on the web which are archives of various mailing lists, thousands of tunes coming from hundreds of contributors. Frank Nordberg has an archive of tunes posted to this list (are you going to add your transcription of Guitar Boogie, Frank?). John's Tune Finder pulls tunes from their original files (although I believe it will get the whole file on request). So the identifier would have to be added to individual tunes to be useful, rather than go in the file header. (2) A surprisingly large proportion of users type their abc directly in a text editor. There's no way you can make these people include the identifier. They mostly won't bother, and if their software enforces it they'll prefer to use a program which doesn't. If you really want to write an abc parser, you will have to get your head round the idea that abc is not a computer language, it's a natural language (albeit a very simple and regular one, with very few dialects). It makes writing a parser a much more interesting task. If you want an easy (to the point of being boring) job, write a MusicXML parser. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
On Fri, 18 Jul 2003, Jack Campin wrote: [mostly snipped because it was such colorful rhetoric...] > ...this is such ... Authoritarian Actually, I have to admit it *is* rather authoritarian of me. 20+ years of dealing with incompatible and poorly defined computer file formats, protocols, and APIs tell me that when developing a *standard*, the standard writers MUST be authoritarian about it. Strictly so. Or it will cause problems down the line. ABC is *both* a musical notation format, and a computer standard. At least according to the docs, and the history of this thing, it developed as a means of writing tunes in a format that could be understood and printed by a computer, and that appears to be it's primary purpose. If you want to write something that's readable primarily by humans, there are already plenty of non-computer notations to do it in. Unfortunately, ABC right now suffers because nobody *has* taken that strict authoritarian stance -- everyone adds their own little pet additions in 50 zillion incompatible ways, with the result that developing a new parser from scratch (something I wanted to do...) is nearly impossible because of all the variations. Either someone steps in, takes charge, and develops a new, more restrictive standard, or the format keeps bifurcating into something more or less useless. It looks like most of the people on this list are trying to take that step -- I just wanted to add in something that I've found key in dozens of other similar cases I've encountered in my career. Also you seem to be assuming that by creating a strict standard, you lose any option of adding something special that you need but that isn't covered by that standard. Nonsense. User defined fields are commonplace in most standards -- there's nothing preventing us from defining something similar, and I encourage as much. The key is to define user fields in such a way that they can be safely ignored by computer programs trying to parse the file -- that hasn't always been the case with the old ABC, and seems to me to be the driving reason behind developing an ABC 2.0 standard in the first place. And if you could care less if your ABC files are parsable by any computer program, well, feel free to put in whatever you like. I'm not stopping you. The programs will probably complain, toss out the tune, or even crash when your so called "ABC" files were read, but that's no different than what exists now, right? >> If that isn't a strong enough incentive, then it might be a good idea >> to create a program which converts ABC tunes to ABC2 tunes, and then >> don't even bother including a parser for pre-ABC2 files in new ABC2 >> compliant tools. > > And the burn-the-past attitude of that paragraph is obscene anti- > intellectual garbage. You do NOT alter somebody else's past work > without their permission or misrepresent your own editing of it as > being the real thing. Okay, this one I didn't snip completely, because it *really* annoyed me -- it was arrogant and totally uncalled for. Okay, so was most of the rest of the message, but this implies I steal IP, and that's something I feel very strongly about. Read what I said, willya? I did NOT say, or even imply, that we're going to go willy-nilly converting all the tunes on the web to ABC2 and upload the new versions as a replacement -- I don't have the authors permission, as you so very rightly pointed out. Nor would I consider running everyone's ABC files through ABC2PS and upload the resulting postscript files for the same reason. The presence of a tool to convert ABC to a usable ABC2 file is no different. The converted tune doesn't have to be kept around after. I was thinking very much along the lines of a UNIX filter -- ie. "abc2abc2 old.abc | abc22pdf" takes your old ABC file converts it to ABC2 format, and from there to PDF using a new ABC2 to PDF conversion program. Oh, and before you complain about *that*, I wouldn't upload the PDF files, either. Sheesh. Note that with such a program, there is no need to cleanup old ABC files -- any time you want to use an old ABC file with your new program, you simply run it through the converter. The whole idea of this isn't converting old ABC files, it's making it easier to conform to a standard for NEW ABC files. I honestly don't think it would be necessary or worthwhile to try to convert and replace all the existing ABC files on the web once a tool like this exists. And it also significantly lowers the bar for entry for people developing new ABC programs -- you don't have to support the idiosyncrasies that existed before the new standard. You could if you really wanted to -- in fact it would be easy -- just take the abc2abc2 source and stick it in your program as a preprocessor before your ABC2 parser. But you don't have to. -->Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
Jack Campin wrote: [ ordinarily I do not attribute posters I respond to, but this is such mind-blowingly offensive, arrogant, counterproductive authoritarian shite that no way could I ever forget the name of the author or want it mistakenly attributed to anybody else ] Jack, are you sure you're not doing poor Steven wrong here? Seems to me you interpreted his posting in the worst possible way. Every musical notation there has ever been has been adapted by people who needed something different to express what they needed to say, and weren't prepared to wait for a committee to approve them saying it. You're right, Jack. It never ceases to amaze me that some people seems to think that the rules of standard notation was written down on stone tablets and handed down to us by the pantheum of great classical composers. It's nothing like that. Standard "tadpole" notation has gradually evolved and been adapted to different purposes for about seven centuries, and is still evolving today. By now, it's all so patchy you have to look very closely to spot the original - very clear and logical - idea at all. If the computer is simply going to sit there as a censor stopping me saying what I want, well, fuck the computer, I can write ABC on paper perfectly well (and have done, I have a stack of notebooks of it). Good point, but I don't think ABC will ever become the ultimate cover-all-bases music notation system. In fact I hope it won't. The need for completeness is very much in conflict with the need for simplicity. Frank Nordberg http://www.musicaviva.com To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
On Friday 18 July 2003 11:25 am, Jack Campin wrote: > [ ordinarily I do not attribute posters I respond to, but this is such > mind-blowingly offensive, arrogant, counterproductive authoritarian > shite that no way could I ever forget the name of the author or want > it mistakenly attributed to anybody else ] Phew. Some dried frog pills are in order, I think. (Though for the Americans on the list, I should probably point out that in Scottish terms, this isn't at all unfriendly. Jack's just pointing out the error of Steven's ways in a forthright manner.) Steven's point isn't that bad, and is equivalent to the movements in HTML/XHTML in recent years. If I stick a doctype declaration on my pages saying XHTML 1.0, browsers will attempt to render it in an XHTML compliant fashion. If I f***ed up, then it'll fall back to the methods it has for dealing with the bloated mess that is HTML2.0 - 4.0. There are good reasons for this; it's because XHTML is a better way to go than previous attempts at a markup language. Likewise, the intention here is to provide a new way of doing ABC. Hopefully, it will be a lot more featureful and be able to do a lot more than you could express with old-school ABC. However, to get there, we *have* to do things differently. ! is just a case in point. Sooner or later someone will have to bite the bullet and decide that it stays or it goes. Whatever, all this old-school ABC on the web won't be going away any time soon. So it's better to have a way of saying: there is a clean way to do this, or there's a messy way to do this. It's up to you, but the clean way is what's supported. The point is, this isn't a standards checker; it's a signal that the tune contains something that just doesn't exist or work under 1.7.6. It means: deal with this tune as per 2.0.0, as it has some clever stuff in it. And when someone wants something that ABC2 can't do, they can submit an RFE, and it can become supported, not a buggy hack that breaks other people's software. Of course, if the standard is sufficiently open and flexible to start with, it shouldn't be a problem... Cheers, Calum To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
From: "Jack Campin" <[EMAIL PROTECTED]> > You are completely and fundamentally confused about the whole > purpose of a musical notation. It is to mediate communication > of artistic creations between human beings. The fact that a > computer might be used as a transport medium is secondary. We > are not writing for an audience of machines... Actually, in developing a standard for abc one is doing *exactly that*. A human reader can cope with all sorts of devations from the standard. Computers however do not have the same facility for applying common sense and intuition. If anyone wants to read abc and print it with a computer, then you need a standard; if not then you don't. Thus while the computer's needs are indeed secondary for *music*, they certainly are not secondary for having a *standard*. > If the computer is simply going to sit there as a censor stopping > me saying what I want, well, fuck the computer, That's another area where computers may be less interesting than people. :-( > I can write ABC on > paper perfectly well (and have done, I have a stack of notebooks > of it). No. If there is a standard and what you write does not conform to it, then you are not writing ABC but rather you are writing something *roughly like* ABC. For human consumption this may be ok - but it will rule out computer processing of your files with many computer applications - perhaps all. This is your choice. >What will actually happen: people will write within certified > standard syntaxes up to the point where they need more. Then they > either turn off the flag that enables the standard checks, or if > the application won't let them, ditch it and find one that will. Which is why I suggested (what others turned into) the namespace idea for %%... lines and between !...! That way the standard admits extension methods which allow files still to conform to the standard. You can use it for what you like and software will be able to cope with it by ignoring anyting it doesn't understand. > I have a few bits of ABC on my CD-ROMs that no existing application > can process, and the scores and sound files do not always correspond > to the ABC I give. This is absolutely intentional. I document what > my ABC means, and if the computer can't yet understand what any > intelligent human can, that's not my problem Indeed not. And when the day comes that all musicians can read directly from ABC text instead of needing notes on stave lines, then it will be nobody's problem. But I am not holding my breath. The problem is that there are files in existence for which a standard cannot be defined which encompasses all of them. Nothing can be done about this, except for individual software developers to try and design software which copes. The point of defining a standard is so that this deeply unsatisfactory situation will not get worse or be repeated in future. The fact that "you document what your ABC means" is fine. Others may do so too. And when abc becomes really popular a million other people may also document what *their* abc means, and software developers can start working through the documentation, seaching for inconsistencies, and in the almost impossible event where they fnd none, can start working though the million documents in order to make their software read all million dialects of abc. But more likely they are up the creek without the encumbrance of having a paddle. Dave David Webber Author of MOZART the music processor for Windows - http://www.mozart.co.uk Member of the North Cheshire Concert Band http://www.northcheshire.org.uk To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
On Fri, 18 Jul 2003, Jack Campin wrote: > [ ordinarily I do not attribute posters I respond to, but this is such > mind-blowingly offensive, arrogant, counterproductive authoritarian > shite that no way could I ever forget the name of the author or want > it mistakenly attributed to anybody else ] Please relax Jack. I must say that I'm a little shocked by the agressiveness with which you are reacting. There was really no need for a personal attack here. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
[ ordinarily I do not attribute posters I respond to, but this is such mind-blowingly offensive, arrogant, counterproductive authoritarian shite that no way could I ever forget the name of the author or want it mistakenly attributed to anybody else ] Steven Bennett <[EMAIL PROTECTED]> wrote: > The whole idea (and the goal any standards maker should be working > towards) is to provide a mechanism and incentive for both the content > developer and the tools developer to implement and stick to the new > standard. [...] > The incentive for the content developer to put these in is twofold -- > First, if they stick to the new standard, their content should work > with ANY ABC2 compliant app. Second, since the old parser isn't > being further developed (and shouldn't be, IMHO...), if they want to > use any ABC 2.0 or later feature or different syntax, they *must* > put in the version tag and comply with that spec, or that feature or > different syntax won't be recognized. > It's important to establish that this tag isn't a comment or > a suggestion to the user or tool -- it's a clear, unequivocal > statement: "The following tune conforms *strictly* to the ABC > 2.0 spec, and if you find it doesn't, throw the tune out with > an error". And it's absence is another clear statement: "The > following tune is pre-2.0, so try to parse it as best as you > can, and definitely do NOT allow any 2.0 specific features". You are completely and fundamentally confused about the whole purpose of a musical notation. It is to mediate communication of artistic creations between human beings. The fact that a computer might be used as a transport medium is secondary. We are not writing for an audience of machines. Every musical notation there has ever been has been adapted by people who needed something different to express what they needed to say, and weren't prepared to wait for a committee to approve them saying it. If the computer is simply going to sit there as a censor stopping me saying what I want, well, fuck the computer, I can write ABC on paper perfectly well (and have done, I have a stack of notebooks of it). What will actually happen: people will write within certified standard syntaxes up to the point where they need more. Then they either turn off the flag that enables the standard checks, or if the application won't let them, ditch it and find one that will. And if I find that some implementor is playing manipulative games with me that not only affect what I can write but also what I can retain and use of what other people have written, then not only will I not use their crappy program myself, I will shout from the rooftops that nobody else should either. I have a few bits of ABC on my CD-ROMs that no existing application can process, and the scores and sound files do not always correspond to the ABC I give. This is absolutely intentional. I document what my ABC means, and if the computer can't yet understand what any intelligent human can, that's not my problem. When I'm transcribing a unique source hardly anyone has access to, people who know the value of that source will want to see it reproduced as well as possible. If that means reading ABC source that can't be interpreted by any program, they'll find the effort worthwhile. > If that isn't a strong enough incentive, then it might be a good idea > to create a program which converts ABC tunes to ABC2 tunes, and then > don't even bother including a parser for pre-ABC2 files in new ABC2 > compliant tools. And the burn-the-past attitude of that paragraph is obscene anti- intellectual garbage. You do NOT alter somebody else's past work without their permission or misrepresent your own editing of it as being the real thing. (See the fife music file on my site - I had to edit it to make it work with BarFly, and fixed some apparent transcription errors, but I kept the original in the same file so you can't download my version without getting the unmodified one too). > The added step of doing the conversion every time they want to try > their new tunes out will quickly convince content writers to use > the %%ABC2 tag. And it will make writing new tools easier because > they won't have to deal with any parsing oddities. You're going to "quickly convince" Laurie Griffiths, are you? (And many still-living content creators are untraceable, with no known person formally responsible for maintaining their archives. Guido's suggestion of doing a mass cleanup of old files on the web was phrased the right way, making it a cooperative effort with the original transcriber, but in a *large* proportion of cases there will be no way to find out who that is, or the originator might no longer be in a position to help). Incidentally, not all of the computer industry operates the way you'd like it to. In the aerospace business (at least in the UK), for obvious safety and forensic reasons, all design data must be retained *in its original format* until long
[abcusers] Re: %%ABC 2.0 identifier
The whole idea (and the goal any standards maker should be working towards) is to provide a mechanism and incentive for both the content developer and the tools developer to implement and stick to the new standard. This is useful to both -- the tools developer should use an old parser if the version tag is not there, and can develop a clean and robust parser for those tunes which have it. The incentive for the content developer to put these in is twofold -- First, if they stick to the new standard, their content should work with ANY ABC2 compliant app. Second, since the old parser isn't being further developed (and shouldn't be, IMHO...), if they want to use any ABC 2.0 or later feature or different syntax, they *must* put in the version tag and comply with that spec, or that feature or different syntax won't be recognized. It's important to establish that this tag isn't a comment or a suggestion to the user or tool -- it's a clear, unequivocal statement: "The following tune conforms *strictly* to the ABC 2.0 spec, and if you find it doesn't, throw the tune out with an error". And it's absence is another clear statement: "The following tune is pre-2.0, so try to parse it as best as you can, and definitely do NOT allow any 2.0 specific features". If that isn't a strong enough incentive, then it might be a good idea to create a program which converts ABC tunes to ABC2 tunes, and then don't even bother including a parser for pre-ABC2 files in new ABC2 compliant tools. The added step of doing the conversion every time they want to try their new tunes out will quickly convince content writers to use the %%ABC2 tag. And it will make writing new tools easier because they won't have to deal with any parsing oddities. Again, IMHO, -->Steve Bennett >> it's fairly clear to me that the real key to >> writing any new specification is adding some identifier that says >> that the tune conforms to the new specification. For example, maybe >> something like: >> >> %%ABC3.0 >> >> ...anywhere in a tune's header will indicate that the tune's encoding >> conforms *strictly* to the ABC version 3.0 (just an example version...) >> specification > > yes, it has already been requested before. As an ABC user, I > totally agree with the idea, and I would include such a comment in > all my tunes (that conform to it) if it enters in the standard. > But the general answer about such an identifier is that "no one > would bother adding it", "you can implement it but only 5 % users > would use it" etc. > > I don't see were is the problem. If some pple don't mind their > tune won't be well played / displayed in most advanced > application, and if they don't wish to add the level of abc used > 1.6, 1.7 or 2.0, it'd be only their own fault. > >> If it's present, though, you can parse it strictly to the >> 3.0 specification -- no deviations allowed. > > it will allow to give responsibilities to pple who wish it this > way, so I find it positive and more logical. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] RE : %%ABC 2.0 identifier
>I don't know if whatI'm about to suggest has been suggested before,/.../ > it's fairly clear to me that the real key to >writing any new specification is adding some identifier that says that the tune >conforms to the new specification. For example, maybe something like: > >%%ABC3.0 > >...anywhere in a tune's header will indicate that the tune's encoding >conforms *strictly* to the ABC version 3.0 (just an example version...) >specification yes, it has already been requested before. As an ABC user, I totally agree with the idea, and I would include such a comment in all my tunes (that conform to it) if it enters in the standard. But the general answer about such an identifier is that "no one would bother adding it", "you can implement it but only 5 % users would use it" etc. I don't see were is the problem. If some pple don't mind their tune won't be well played / displayed in most advanced application, and if they don't wish to add the level of abc used 1.6, 1.7 or 2.0, it'd be only their own fault. >If it's present, though, you can parse it strictly to the >3.0 specification -- no deviations allowed. it will allow to give responsibilities to pple who wish it this way, so I find it positive and more logical. ___ 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
