Re: [abcusers] Re: My point of view on the abc standard
I. Oppenheim wrote: ... I do not agree with this approach. A standard should document advisable behaviour, not all the possible errors that people make when writing ABC. I'd say both yes and no to that. The new standard should certainly do far more than just document common ABC use. OTOH it wouldn't hurt to at least give some consideration to how people actually *write* their ABC, not only from a pragmatic POW (fewer faulty ABC files in circulation), but also because there might be good ideas there. Although it's not very common, people do occsionally have good reasons for doing thing the way they do. ;-) Frank Nordberg http://www.musicaviva.com To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: My point of view on the abc standard
There's been a lot of traffic on this topic already. Two things I'd like to emphasize: 1) I agree that the standards committee should have a chairman, but I think the committee needs to elect him/her. 2) We seem to be in danger of falling into the trap of everything that any known ABC-related application does has to be included in the standard. This runs the risks of a) making the standard too difficult to interpret and/or implement, and b) adding features to the standard before they've been used widely enough to figure out if they're actually workable as implemented. I'd recommend that in general, we try not to add features to the standard unless: a) there is consensus (or at least an overwhelming majority opinion) as to what the feature should do, and either b) several (or at least a few significant) applications already use it, or c) more than one developer (or group of developers) is planning to implement (or in the process of implementing) the same feature Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: My point of view on the abc standard
Jeff Bigler writes: | | 2) We seem to be in danger of falling into the trap of everything that |any known ABC-related application does has to be included in the |standard. This runs the risks of | |a) making the standard too difficult to interpret and/or implement, | and | |b) adding features to the standard before they've been used widely | enough to figure out if they're actually workable as implemented. ... Good points. There's a well-known phrase in the computing industry that describes this: the Second-System Syndrome. This refers to the way in which a first successful product is followed by a new, improved version that tries to solve all the world's problems. It is invariably a disaster. A much more successful approach is an evolving system, that adds new things after they have been tested. This includes field tests with users who have been warned that the new things are tentative and users are expected to provide feedback. The standard then includes only the things that have been widely accepted and implemented, and the rest are proposed extensions. It's worthwhile to document all of them, but you should make a clear distinction. One of the important parts of this is something we've discussed here lately: You will get new things that the old software can't handle. This means that the software in general needs to be written so that it doesn't choke on things that it doesn't recognize. We do have abc software that gives up (or dies) when it hits something it considers illegal. We should be pointing out to the programmers that this isn't acceptable. New things should at most get a warning, but should be handled (i.e., ignored) gracefully. This way, we can try out new ideas, and if they turn out to be good ideas, they can be added to the growing standard. One of the things that impressed me with abc2ps when I first started using it was that it did a pretty good job of this. I fed it abc from email and web sites that contained all sorts of funny things. It told me about them, and barged ahead. Sometimes there were things missing from the output, but at least the notes were there. (There are the cases where the tune doesn't end with a blank line, mostly when people attempt to embed abc inside html. This produces some rather bizarre modernistic music after what should be the end of the tune. But this is mostly funny.) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: My point of view on the abc standard
Jeff Bigler wrote: There's been a lot of traffic on this topic already. Two things I'd like to emphasize: I'd recommend that in general, we try not to add features to the standard unless: a) there is consensus (or at least an overwhelming majority opinion) as to what the feature should do, and either b) several (or at least a few significant) applications already use it, or c) more than one developer (or group of developers) is planning to implement (or in the process of implementing) the same feature Maybe adopting the IETF policy that there has to be at least two independent interoperable implementations of something before it becomes standard. Or something similar. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: My point of view on the abc standard
Buddha Buck writes: | | Maybe adopting the IETF policy that there has to be at least two | independent interoperable implementations of something before it becomes | standard. Or something similar. Good idea. We might go over the multi-voice implementations with this in mind. One that might satisfy the two-implementation requirement now: The original abc2ps insisted that V: lines all be after the K: line, in the music portion. At least one other program requires that voice definitions be in the header. In jcabc2ps, I replaced the error message that it gave for V: in the header with code to put the line on the end of a list of V: lines and report success. Then, when the code went into its music phase, I added a couple lines to run down this list and call the routine to process them. It worked fine. So jcabc2ps now accepts V: definition lines anywhere before the first use of a voice. All we need now is a non-abc2ps-clone program that is as liberal, and we can state in the standard that such lines can go anywhere (but probably before the first music for each voice). To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: My point of view on the abc standard
On Thu, 3 Jul 2003, John Chambers wrote: All we need now is a non-abc2ps-clone program that is as liberal, and we can state in the standard that such lines can go anywhere I do not agree with this approach. A standard should document advisable behaviour, not all the possible errors that people make when writing ABC. I think the only relevant question is: would there be anything against allowing those V: lines to go anywhere? I see no objections, so I think the standard should indeed allow 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
Re: [abcusers] Re: My point of view on the abc standard
On Wed, 2 Jul 2003 [EMAIL PROTECTED] wrote: I fundamentally disagree with this. I believe that it is imperative that the standard and the software that uses it should be isolated. I agree with you. I had already a bit of argument about this with Phil. The standard should define an abstract music representation format, that does not depend on the actual applications that use it. Application dependent meta information such as page width, font colour, midi track no could also be standardized, but in a meta standard that is separate and does not interfere with the abstract ABC standard. The ABC standard itself should only deal with purely musical elements. Compare it to the situation on the web: HTML/XML deals with the structured information itself, CSS/XSL deals with layout. In fact, the %%-notation and format files serve already as a sort of stylesheet. Please take these conceptual differences into account when writing the upcomming standard. No individual programme needs to implement the whole standard. Programmes aimed at western folk musicians may not need some of the complexities of classical music (or Klezmer or Persian). And the other way round---classical music programs may not want to deal with e.g. bagpipes or guitar tablature notation. Therefore I think the ABC standard should be highly modular; ABC software should be able to implement a minimal amount of ABC in a well defined way that is still standard compliant. The software developer is then able to clearly indicate which ABC modules are supported and which not. Stuff such as bagpipe notation, modal key signatures, microtonal accidentals, tablature support could go in separate modules that are optional. In this way it will still be possible to extend ABC with useful features, without requiring that they should be implemented by all programs. Only programs that want to deal with everything that's out there on the web, should be able to handle both bagpipes notation and microtonal subtleties. Other programs can specialize. 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: My point of view on the abc standard
In message [EMAIL PROTECTED], I. Oppenheim [EMAIL PROTECTED] writes ABC software should be able to implement a minimal amount of ABC in a well defined way that is still standard compliant. The software developer is then able to clearly indicate which ABC modules are supported and which not. Stuff such as bagpipe notation, modal key signatures, microtonal accidentals, tablature support could go in separate modules that are optional. In this way it will still be possible to extend ABC with useful features, without requiring that they should be implemented by all programs. Only programs that want to deal with everything that's out there on the web, should be able to handle both bagpipes notation and microtonal subtleties. Other programs can specialize. Well said - and surely the 'core' abc specification implemented by all programs should be 1.7.6 (which is IIRC effectively 1.6 with V: and w:). That way abc maintains backward compatibility with the thousands of files that are already published, and also continues to support the vast majority of its user base, eg people who are using abc to record and exchange single-line melodies with minimal ornamentation and what I might venture to call 'performance marks'. -- Steve Mansfield [EMAIL PROTECTED] http://www.lesession.co.uk - abc music notation tutorial, the uk.music.folk newsgroup FAQ, and other goodies To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: My point of view on the abc standard
From: I. Oppenheim [EMAIL PROTECTED] On Wed, 2 Jul 2003 [EMAIL PROTECTED] wrote: I fundamentally disagree with this. I believe that it is imperative that the standard and the software that uses it should be isolated. I agree with you. I had already a bit of argument about this with Phil. The standard should define an abstract music representation format, that does not depend on the actual applications that use it I agree entriely. The original abc defined the abstract music - the sequence of notes and barlines, tuplets, and so on. There are some concessions to the way it should be drawn (existence of bar lines; where to draw beams; where to split systems) but nothing as detailed as how much space to leave between notes and other items, for example. I can imagine that some programs might take the first set as advisory, but they have to invent a lot of information - like the spacing - for themselves. I think this is entrirely appropriate for a language like abc. As for page size: that is defined by the sheets of paper in your printer, and it is for the application to deal with - not abc :-) No individual programme needs to implement the whole standard. Programmes aimed at western folk musicians may not need some of the complexities of classical music (or Klezmer or Persian). And the other way round---classical music programs may not want to deal with e.g. bagpipes or guitar tablature notation. Actually all applications need to implement the whole standard, - in the sense that they need to be able to recognise elements they don't want to implement, and ignore them in a graceful fashion. Therefore I think the ABC standard should be highly modular; ABC software should be able to implement a minimal amount of ABC in a well defined way that is still standard compliant. The software developer is then able to clearly indicate which ABC modules are supported and which not. When it comes down to it, someone is going to open some unknown file xyz.abc with his favourite application. 90% of the contents of that file may be useful to him; the rest may be unrecognised by his application. If it comes across a V: together with some suitably coded information that this is a guitar tab stave and ghis application doesn't do guitar tab, it would be nice for him to be able to read the rest. In that sense the whole language *is* modular. An application would have to parse the file it anyway to find out what it uses. But all the application could do is put up a message saying this abc file contains elements from abc module ... and so I can't read all (any?) of it.In that sense a definition of modules would be useful - but not if people are going to argue too much over their boundaries :-) Stuff such as bagpipe notation, modal key signatures, microtonal accidentals, tablature support could go in separate modules that are optional. In the above sense optional does not make that much sense! In this way it will still be possible to extend ABC with useful features, without requiring that they should be implemented by all programs. Only programs that want to deal with everything that's out there on the web, should be able to handle both bagpipes notation and microtonal subtleties. Other programs can specialize. Specialising is great for *writing* files, but is more difficult if you want to read one from an unknown source. 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: My point of view on the abc standard
On Wed, 2 Jul 2003, David Webber wrote: An application would have to parse the file it anyway to find out what it uses. But all the application could do is put up a message saying this abc file contains elements from abc module ... and so I can't read all (any?) of it. Applications that write ABC files, could indicate in the ABC version field which ABC modules they used, e.g. 2MG for ABC version 2.0.0 with guitar module and microtonality module. 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: My point of view on the abc standard
From: I. Oppenheim [EMAIL PROTECTED] Applications that write ABC files, could indicate in the ABC version field which ABC modules they used, e.g. 2MG for ABC version 2.0.0 with guitar module and microtonality module. Yes something like that might be useful - even if those writing abc by hand omitted it (as someone pointed out they would). 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: My point of view on the abc standard
Jon Freeman wrote: I think you are taking a pretty narrow view here. Yes, abcm2ps is excellent but it is pretty well useless to many people I know who may like to use abc.What you see in the abcusers list tends to be the geeks, the ones that are quite happy to run command line programs, are quite probably capable of compiling from source code, etc. abcm2ps has been mentioned and praised at Mudcat for example but I think you will find few have tried it - Why? At least partly because the prospect of setting it up, installing ghostscript to view graphics. etc. it just too daunting for them. What these users (probably the majority of PC users) want is something that is easy to use and works on their system. Cross platform isn't even an issue... These are excellent points from Jon who raises the dilemmas of the non-programming ABC-user except that 'daunting' is too mild a term. 'Terrified' might be nearer the mark! But here's the beef: I am fundamentally an Irish Trad musician teacher, so what I'm basically looking for is a program which simply enables me to view, play and print tunes. To a large extent, I can get most of this from ABC2Win despite its severe limitations - especially in relation to the printed output, not to mention the haughty snipes from abc**ps programmers! But all I really need, for my purposes, is a single line score - like a present day O'Neill's Collection. However, for better tonal variation, I'm happy to use Henrik's ABCMus despite its own restrictions (no score, etc.). As a consequence, I've found a happy compromise in Melody Assistant which gives me the best of both worlds plus the added benefit of Tablature which helps greatly in my classes. (It also accepts ABC notation). Nonetheless, I have tried to get interested in programming by reading Guido's manual in an attempt to find out what the hell you, the programmers, are talking about! Regrettably, the concept just doesn't work for me and I had to say to myself -'Do I really need to do this?' I didn't and packed it in. Therefore, here I am- a 'geek' for music but a 'non-geek' in regard to programming, happy to use all your knowledge without doing any work - except, of course, paying for the programs I use. (Insert a cheer here for JC's 'Tunefinder' which is, of course, free). I feel, therefore, as if I'm intruding in a family row at this point in the discussion with each individual pushing his/her own point of view quite forcefully without actually coming to blows but, enter the interloper, and you'll all turn and tear me to pieces. It has all been very interesting but from my position as a non-programming musician it seems to have been, so far, a series of purely academic suggestions or hypotheses albeit with the, very laudable, goal of attaining a generally accepted or acceptable standard of ABC programming. What I should like to know, therefore, is where exactly is the debate going in terms of importance. What, for example, is the more crucial aspect of this discussion - the nuances of writing the program itself or the end result, i.e. the displaying and/or playing the music with the option of a printable copy. So far, it appears, we are getting bogged down in the technical aspects of the 'how-to's'- but that may be in the nature of the beast itself and it's very probable, as Sinatra might have warbled, '...One don't go without the other'. But I do wish you success. Anything which improves the current standard of ABC programs (free or otherwise) can only be to the benefit of us all - geeks, nerds or sensible musicians like myself! Gerry McCartney To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: My point of view on the abc standard
From: Gerry McCartney [EMAIL PROTECTED] What I should like to know, therefore, is where exactly is the debate going in terms of importance. This is the important thing. :-) I see four main desiderata as far as language goes (over and above the 1.7.6 standard): A way to include more than one voice in parallel [V:] A way to include lyrics [w:] A way for apps to include their own data without breaking others. Having a real standard and persuading software writers to ahere to it. I regard the 3rd as necessary for gaining the 4th.The other things are details :-) So far, it appears, we are getting bogged down in the technical aspects of the 'how-to's'- but that may be in the nature of the beast itself and it's very probable, as Sinatra might have warbled, '...One don't go without the other'. If one can persuade the committee that certain features would be very easily and elegantly incorporated, I guess one has a better chance of getting them :-) 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 : My point of view on the abc standard
I am using runabc.tcl (or runabc.exe) on both my PC and on Linux as a front end to abcm2psandgsview,and it is extremely easy to use. To a novice user, once it is setup, you hit "display" and it generates a pdf file directly and launches gsview32.exe (on Windows). I think the biggest thing lacking on Windows is an open source graphical score editor. I use abcm2ps extensively for generating music for church, and I have a large library of ABC worhip music, but I can interest anyone else in learning the syntax and writing music in a text editor. Don.Forgeot Eric [EMAIL PROTECTED] wrote: At least partly because the prospect of setting it up, installingghostscript to view graphics. etc. it just too daunting for them.What these users (probably the majority of PC users) want issomething that is easy to use and works on thier systemit's true I often recommended Abc to several musicians I know, butfound it difficult to tell them it's not that user-friendly to setup. I always recomment AbcMus (it's obvious because it's easy toinstall, compact (less than 1 Mb), efficient, powerfull...), butfor displaying music it's the tricky part. I generally recommentAbacus because it's easy to use and the result is good, even ifit's not as complete as Abcm2ps.Does someone know if it's possible to "hack" a ghostscript versionto have only the PDF export, and create a program that coulddirectly convert abc to pdf using abcm2ps, in a minimal package ?(Ghostscript is quite huge to d/l for ppl who may don't have thenecessary motivation for it at first)It's a pity Adobe don't include in their acrobat reader a PSviewer. With time acrobat reader grow for each new version, butthere are few real useful improvements.___Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !Yahoo! Mail : http://fr.mail.yahoo.comTo subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
Re: [abcusers] re : My point of view on the abc standard
On Wed, 2 Jul 2003, [iso-8859-1] Forgeot Eric wrote: Does someone know if it's possible to hack a ghostscript version to have only the PDF export That's possible. When compiling, you can select the output devices you're interested in. But it won't make ghostscript much smaller, because most of the code is used to emulate the postscript itself, which is quite a complex language. And you will still need to download all the postscript fonts that come with ghostscript. and create a program that could directly convert abc to pdf using abcm2ps, in a minimal package ? That's no problem. You only have to write a small batch file that first calls abcm2ps and afterwards ps2pdf, which is already part of ghostscript. Irwin To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] re : My point of view on the abc standard
In message [EMAIL PROTECTED], Donald White [EMAIL PROTECTED] writes I am using runabc.tcl (or runabc.exe) on both my PC and on Linux as a front end to abcm2ps and gsview, and it is extremely easy to use. To a novice user, once it is setup, you hit display and it generates a pdf file directly and launches gsview32.exe (on Windows). I think the biggest thing lacking on Windows is an open source graphical score editor. I use abcm2ps extensively for generating music for church, and I have a large library of ABC worhip music, but I can interest anyone else in learning the syntax and writing music in a text editor. For graphical score editor (wysiwyg) and soon to support abc you can try Music Publisher (www.muspub.com) but if open source=free then No. I have a living to make. Bernard Hill Braeburn Software Author of Music Publisher system Music Software written by musicians for musicians http://www.braeburn.co.uk Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] re : My point of view on the abc standard
From: Bernard Hill [EMAIL PROTECTED] For graphical score editor (wysiwyg) and soon to support abc you can try Music Publisher (www.muspub.com) but if open source=free then No. I have a living to make. open source means that you publish the source code for free for people to edit as they will and recompile on their own platform. It's popular among unix users. The people who write open source apps, and are most vociferous in proselytising the idea, tend to be paid a salary by a university somewhere while they're doing it. Ok for some. No-one that I know has ever come up with a model of how people like you and me would get paid for our time if we put out the fruits of our many man years' labour as open source. If I can crack it, then MOZART will have an abc import soon(ish) too. But I have a living to make too. :-( 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
