[abcusers] Re: ABC Standard 2.0 revision III
K:A_b^f^c shouldn't that have a G# also since you've written K:A? and a lot of other stuff around the same subject. Perhaps it's time to plug my idea of - K:_b^f^c tonic=A mode=whatever Completely unambiguous. Talking of which, are there any plans for a procedure for amendments or extensions to the standard or do we just stick to the implement your favourite idea and argue about it afterwards system we have now? Bryan Creer
[abcusers] Re: ABC Standard 2.0 revision III
Bernard wrote- 2. |: at the beginning of a section is not ugly. And I do not like being forced to accept incorrect notation in that if a |: is missing then the repeat should be made from the previous double bar. But it *is* ugly at the beginning of a piece. Apparently, Beethoven agreed. Open the score of any of his symphonies (or any other classical sonata-allegro movement, for that matter) and note that there is no opening |: although the first section repeats. It cannot be bad abc to preserve this. Also, Irwin: a minor request: All over your page, you use ` and ' as open and close quotes, respectively when referring to symbols. The first one, in particular, looks so odd that one is tempted to think it is part of the notation being referred to. Couldn't you use ' or or even curly quotes instead to make it flow more smoothly? Thanks David Barnert Albany, NY To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC Standard 2.0 revision III
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes Bernard wrote- 2. |: at the beginning of a section is not ugly. And I do not like being forced to accept incorrect notation in that if a |: is missing then the repeat should be made from the previous double bar. But it *is* ugly at the beginning of a piece. Apparently, Beethoven agreed. Open the score of any of his symphonies (or any other classical sonata-allegro movement, for that matter) and note that there is no opening |: although the first section repeats. It cannot be bad abc to preserve this. I did not say beginning of a piece I said beginning of a section. It has always been standard notation to assume the first repeat is from the beginning of the work. We are talking about | . | | :| | . | | :| which is ambiguous. And should maybe be | . | | :| |:.. | . | | :| I am always happy to keep the assumed back to the beginning repeat in stave 1 above. It's the 2nd stave of the top I object to. Also, Irwin: a minor request: All over your page, you use ` and ' as open and close quotes, respectively when referring to symbols. The first one, in particular, looks so odd that one is tempted to think it is part of the notation being referred to. Couldn't you use ' or or even curly quotes instead to make it flow more smoothly? Hear, hear. Either use back and forth quotes (Latin-1 charset decimal 145 and 146) or standard ' (decimal 39) for both. To mix ` (ascii 96) with ' is very untidy and illogical. 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
[abcusers] Re: ABC Standard 2.0 revision III
John Chambers wrote - Bryan Creer writes: | Talking of which, are there any plans for a procedure for amendments or | extensions to the standard or do we just stick to the implement your favourite idea | and argue about it afterwards system we have now? What a concept! This is a gang of musicians, you know. What are the chances of us ever agreeing to any such thing? That's good because I've implemented tonic= and mode= in Abacus. Next you'll be telling us that Britney Spears is a musician ... Yeah! And she' really is a virgin. Bryan Creer
Re: [abcusers] The abc standard
This response is a little late---I'm still re-installing things after a crash, and am just getting around to the abc programs. Irwin Oppenheim writes: The problem---or one of the problems---is simply that this isn't good enough when you care how the output looks. (Not to mention that the notation is way overloaded already...) I think that ^+ looks quite good in Abcm2ps: nicely centered over the notehead. The ^+ and + both seem to put the plus sign in the same place, which is over the staff. I'd probably want to experiment, but my preference would be to have it just above the notehead. That might require a different font size to fit. This would hold for the minus sign too--tenuto--which I've usually seen placed just above the note, not above the staff. If you want something really special, you can always use the %%postscript and %%deco commands, see for example: http://www.joods.nl/~chazzanut/abc/deco.html This is a very interesting feature. I'll have to look into it. The @ foo looks useful. Can it place things relative to a note on the staff? (As do foo and foo?) This gives you ultimate control and freedom, at the price of being package dependent. Non-portability isn't a problem for me, since I'm using abc2mtex and its macros---which handle this---for my serious printing, and it's hard to get less portable than that. However, I'd like to see abc make at least a part of this official (and therefore portable). I've found it useful, and I'm sure others will too. Cheers, John Walsh To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
On Wed, 16 Jul 2003, John Walsh wrote: The @ foo looks useful. Can it place things relative to a note on the staff? (As do foo and foo?) The draft standard says: Using the @ symbol leaves the exact placing of the string to the discretion of the interpreting program To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
John Walsh writes: | John Chambers writes: | Which does remind me of a suggestion I've long thought of making: Any | Baroque musician is familiar with the convention that a '+' above a | note means Ornament this note somehow. ... | | Ok, but you don't have to make the plus sign a part of abc. | There could simply be a macro---or escape or macro-like entity, or ... Actually, I've long done this, by simply using +. But there are a couple of problems with this. One is that this is, with some justification, often referred to as abusing the chord notation. While it may get the symbol above the note, or maybe it has to be ^+ with some programs, it really is (mis)using chord notation to get some text positioned the way you want it. Few if any abc programs would recognize this + as a symbol for an ornament. If all you want is printed music that looks right, that's fine. But if you want abc that can be correctly understood by other software, it's not so fine. Another objection is that a lot of programs allow only one such quoted string per note. So if you write G7+B you will likely get either the G7 or the + but not both. When the !...! notation first came out, I thought that it would be a fix for these problems. Great; now we have a way to correctly flag a bit of text as a musical annotation other than an accompaniment chord. But this hope was dashed when it became clear that people intend !...! to only allow things on a restricted list. I can't use it to attach arbitrary musical annotations to a note, because for most of the annotations won't be on anyone's list, and they will be discarded. I'm reminded of a musical spoof that I heard years ago, which went something like: This passage on the viola descends and gets quieter, and ends on a low Bb marked pensando. That's the only way it can be played of course, since it's below the instrument's range. I've wondered occasionally whether such passages could be transcribed to standard abc. That particular musical annotation is something that you're not likely to see in actual music, but it would be fun to be able to write it out as an example. (Some of us think music should be fun. ;-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
On Thu, 10 Jul 2003, John Chambers wrote: Actually, I've long done this, by simply using +. But there are a couple of problems with this. One is that this is, with some justification, often referred to as abusing the chord notation. I quote from the ABC draft standard: Annotations === General text annotations can be added above, below or on the staff in a similar way to accompaniment. In this case, the string within double quotes is preceded by one of five symbols ^, _, , or @ which controls where the annotation is to be placed; above, below, to the left or right respectively of the following note, rest or bar line. Using the @ symbol leaves the exact placing of the string to the discretion of the interpreting program. Where two or more such annotations are placed consecutively, e.g. for fingerings, the notation program should draw them on separate lines, with the first listed at the top. These symbols also distinguish annotations from guitar chords, and should prevent programs from attempting to play or transpose them. This means that you can use ^+ (but not +) with a clear conscience as an annotation, even together with other annotations and a guitar chord. If all you want is printed music that looks right, that's fine. But if you want abc that can be correctly understood by other software, it's not so fine. If you want to write out the implementation of your decoration for e.g. an ABC player, use the macro facility designed by Phil that will hopefully be soon available in Guidos fine ABC preprocessor. This passage on the viola descends and gets quieter, and ends on a low Bb marked pensando. That's the only way it can be played of course, since it's below the instrument's range. That would be ^pensando :-) Completely standard ABC. 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] The abc standard
On Mon, 07 Jul 2003 13:02:43 UTC, John Chambers [EMAIL PROTECTED] wrote: Jean-Francois Moine writes: | abcm2ps supports 'U:' (without '!'), and also 'd:' lines, which is | an other way for decorations, and which has not been discussed yet... I don't think I've seen (or maybe I should say noticed) that one. How does it work? It is quite the same as the 'Y:' line Eric Galluzzo told us about a few days ago. It as the same syntax as 'w:', but for decorations. Here is an example from the file 'sample2.abc': V:1 ~c.dJeNf cdef|aabc' gabc'|!coda!cdef gfec|| d: * * * * HRTu|!mf! |!sfz! *** ***!D.S.! V:2 CDEFCDEF|ffga efga|C D EF [EG]FEC|| d: ~.JNHRTu|~.JN HRTu|!5!!4!M* !5! M d: | |* P !3! !4! -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** | http://moinejf.free.fr/ Pépé Jef| mailto:[EMAIL PROTECTED] To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
John Chambers writes: Actually, I've long done this, by simply using +. But there are a couple of problems with this. One is that this is, with some The problem---or one of the problems---is simmply that this isn't good enough when you care how the output looks. (Not to mention that the notation is way overloaded already...) When the !...! notation first came out, I thought that it would be a fix for these problems. Great; now we have a way to correctly flag a bit of text as a musical annotation other than an accompaniment chord. But this hope was dashed when it became clear that people intend !...! to only allow things on a restricted list. I can't use It clearly has to be expanded to take arguments. Cheers, John Walsh To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
Am still catching up with last weeks postings... John Chambers writes: Which does remind me of a suggestion I've long thought of making: Any Baroque musician is familiar with the convention that a '+' above a note means Ornament this note somehow. It's a generic, unspecific ornament symbol. I personally would like it to mean this in abc. This really just means that '+' would be added to the list of ornament symbols, and the default display form is merely a '+' above the note. It should be definable, of course. And a clever abc player program could pick a random ornament from its repertoire. Ok, but you don't have to make the plus sign a part of abc. There could simply be a macro---or escape or macro-like entity, or whatever you want to call it---which will put *any* desired character over/under a note. Then you simply tell the macro that the character it's adding is a plus sign, and alias it with one of H---Z, say P, for plus. Then |ABc Pdef| puts a plus sign over the d. (Of course you need a way of making minute adjustments in the position of the plus sign so it'll look good---they seldom look just right without a little adjustment.) The advantage of this that you can put other articulation signs over the note with the same generic macro. I think you could try this out in your abc2ps clone without too much difficulty. Contact me off list if you're interested. Cheers, John To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
On Fri, 4 Jul 2003 10:39:36 +0100, Jack Campin [EMAIL PROTECTED] wrote: Over the past year or so, this group has become dominated by discussion of abcm2ps; [snip] It won't be if the notation has been designed to be unplayable and unanalyzable, which is where the !...! stuff is heading. abcm2ps supports 'U:' (without '!'), and also 'd:' lines, which is an other way for decorations, and which has not been discussed yet... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** | http://moinejf.free.fr/ Pépé Jef| mailto:[EMAIL PROTECTED] To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
Jean-Francois Moine writes: | On Fri, 4 Jul 2003 10:39:36 +0100, Jack Campin [EMAIL PROTECTED] | wrote: | Over the past year or so, this group has become | dominated by discussion of abcm2ps; | [snip] | It won't be if the notation has been designed to be unplayable and | unanalyzable, which is where the !...! stuff is heading. | | abcm2ps supports 'U:' (without '!'), and also 'd:' lines, which is | an other way for decorations, and which has not been discussed yet... I don't think I've seen (or maybe I should say noticed) that one. How does it work? To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
Over the past year or so, this group has become dominated by discussion of abcm2ps; Probably because it is the best and least limited ABC implementation around: it implements an extensive set of features, is actively developed, runs on all computer platforms that we use and gives excellent ouput quality! Its sound output wasn't that good last I heard, and I haven't got a computer that can run it. Nor is it much good at transposing tunes, cataloguing tune files or importing MIDI. Have you ever tried ABCMus, BarFly or Muse? [a standard developer] is going to be familiar with programs which do fast onscreen display of abc music, programs which play abc, programs which do musical analysis or use abc for archival or database purposes etc. Phil, this are all implementation specific issues which a standard should not address. As you indicated yourself, ABC is just an *abstract* computer representation of a computer score; It IS a score. Any staff notation you generate from it is a transformation of a notation which represents *music*, not marks on paper. Musical analysis is just as good a way to use it as making printable files from it. all that the standard should do is to define this representation in an abstract way. Whether the *concrete* ABC files are to be played, displayed, printed or analyzed is up to the end user. It won't be if the notation has been designed to be unplayable and unanalyzable, which is where the !...! stuff is heading. - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] The abc standard and ~ / turns / rolls
| Is ~ a roll or a turn? | According to ABC 1.7.6, it's a roll: One more disaster with that standard. The 1.6 standard said: : Alternatively, the tilde symbol ~ represents the general gracing : of a note which, in the context of traditional music, can mean : different things for different instruments, for example a roll, : cran or staccato triplet which is exactly what you want a new symbol for, having just dumped an already agreed one: Any Baroque musician is familiar with the convention that a '+' above a note means Ornament this note somehow. It's a generic, unspecific ornament symbol. I personally would like it to mean this in abc ~ has been around so long with its 1.6 meaning that almost every file on the web that uses it can be assumed to have the nonspecific semantics (which is not accidental, that's what Breathnach used it for in Ceol Rince na hEireann and where Chris got the idea). And in this situation you have no syntactic clue to tell you if the author might have had the redefined sense in mind. At this point it is WAY too late to think of imposing a new meaning on it. In fact + doesn't always have that generic sense in Baroque music. In English recorder music of the early 18th century it always means a trill starting on the note above. I brought that up a few years ago and the situation hasn't changed: BarFly can give me the semantics I want but not the original sign, abcm2ps's syntax can give me the graphical sign but can't represent its meaning in a way any player program could ever interpret. A full solution would need to allow new graphical elements to be introduced (in a platform-independent way, say as GIFs; in the worst case they might have to be taken from a scan of a manuscript) and allow their meaning to be redefinable, in case new scholarship finds that for some particular piece, a different set of conventions were really in force than those the transcriber had in mind. - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard and ~ / turns / rolls
On Friday 04 July 2003 10:07 am, Jack Campin wrote: A full solution would need to allow new graphical elements to be introduced (in a platform-independent way, say as GIFs; in the worst case they might have to be taken from a scan of a manuscript) and allow their meaning to be redefinable, in case new scholarship finds that for some particular piece, a different set of conventions were really in force than those the transcriber had in mind. May I direct you to my suggestion of a builtin scripting system? This is *exactly* the situation I was thinking of; the idea would be that one could insert a symbol called whatever, and attach drawing and playing instructions to it. As an aside, a vectorial description system would be better; if there's one that's ideal for parsing and translation, so much the better. FWIW. Cheers, Calum To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
Bert van Vreckem wrote: The committee in itself is a good idea [...], but if we want the standard to go forward, there should be only one leader OK, agreed. So can we decide on that and go forward? After what Guido wrote (quoted below) I feel he should be the leader. Guido wrote: We're almost there. I'm finishing a document I named A proposal of ABC 2.0.0 standard; it includes the latest 1.7.6 draft (verbatim), and adds the least common denominator of multivoice support, low level details (e.g. %%stuff), portability issues, some ABC examples, and so on. Then I point out that there are details that inherently only make sense in printed music, others in played music; I'm covering those too. To sum up, call me the coordinator if you wish; but bear in mind that you're free to toss my work and dedication out of the window if you wish, I'll not get upset. I just believe that with a bit of coordination - I did nothing more than this - we'll soon have the new standard. Henrik Norbeck, Stockholm, Sweden [EMAIL PROTECTED] http://www.norbeck.nu/ My home page http://www.norbeck.nu/abcmus/ AbcMus player program http://www.norbeck.nu/abc/ 1900 ABC tunes http://www.norbeck.nu/blackthorn Irish trad music band http://www.rfod.se/folklink/ Links to Swedish trad music To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
From: Bernard Hill [EMAIL PROTECTED] The problem as a developer is that we're second-guessing writers of bad abc notation. A concise way of putting it. :-) We're in a slightly different boat from some of the others though. If people want to write abc and read it using Notepad (or other ascii text app) and purely cerebral processing, then flexible notation with no exact standard may be clear enough. If people want write it by hand and only ever use one abc-specific application to print it, then only that application's dialect of abc need concern them. If your users (like some of mine) are clamouring for abc import because there's so much stuff out there, then we want to read *everything*. And life is suddenly harder without a strict standard. :-( 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] The abc standard
From: John Chambers [EMAIL PROTECTED] Actually, my main reasoning is that of a programmer: If we want everyone to implement this U: header, it should be as simple as possible. A string substitution is about as simple as it gets, and very easy to implement in just about any language. Actually this isn't *just* a programmer's viewpoint.If it is easy to parse then that also probably means that it is free of ambiguities - which is crucial when the same character symbol eg A, ], : is used as part of different constructs. 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] The abc standard
From: Bernard Hill [EMAIL PROTECTED] I read the (old) standard and thought that's OK. Not too much work. Hmm I must be telepathic - that's what *I* thought - before I came here :-) MOZART already has a general spec for an import filter for any non-native format, and its MIDI import module is built around it. Recently someone wanted to import a really weird format I had never heard of, is a C++ enthusiast, and wanted to write a module to read it. So I sent him the spec. At that moment, I decided to start the abc project in earnest, so that I find any problems with the import module spec before he does :-) 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
[abcusers] The abc standard
I've held back from this discussion so far to see where it was going but I think it's time to add my 2p. Over the past year or so, this group has become dominated by discussion of abcm2ps; it shows a strong tendency to become the abcm2ps users group. Now abcm2ps is an excellent program, but it is extremely limited; all it does is convert abc to postscript. If that's all you want to do with abc you will be perfectly happy to see the abc standard redefined in terms of what abcm2ps does. The language is, however much more than source code for musical typesetting. It is an abstract method of representing music in a human-readable format, and its development must not be tied to one particular use, any more than it should be tied to one particular musical genre. So, if we are going to hand over the development of the standard to one person, that person is going to need to have a wide range of musical interests, and be very familiar with the existing corpus of abc and the ways in which it is used. He is going to be equally familiar with all three of the major platforms on which abc software is run, and with the major abc programs which run on those platforms. He is going to be familiar with programs which do fast onscreen display of abc music, programs which play abc, programs which do musical analysis or use abc for archival or database purposes etc. He's also going to have lots and lots of time available. I don't think such a person exists. It's a job for a committee. Perhaps a different approach is called for. A while back, I made a study of the way in which different programs handle multivoice abc. http://www.barfly.dial.pipex.com/multivoice.txt It was a lot of work to do, but it proved useful, and since I put that document online, the major abc programs have actually moved closer together. Maybe what we need to do is to publicly document the remaining differences between programs in such a way that all of the developers can see what's already been done, and a) avoid reinventing the wheel.* b) support multiple existing formats where they exist. Certainly, whatever way we take forward, the first step is to document the existing programs in a comparative way. The way in which your favourite program does it is not necessarily the best way, and until you have done the comparison you really don't know. Phil Taylor * actually I'm not averse to doing that myself, since if nobody had ever reinvented the wheel your car would still run on log rollers. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
On Tue, 1 Jul 2003, Phil Taylor wrote: Over the past year or so, this group has become dominated by discussion of abcm2ps; Probably because it is the best and least limited ABC implementation around: it implements an extensive set of features, is actively developed, runs on all computer platforms that we use and gives excellent ouput quality! So, if we are going to hand over the development of the standard to one person, No one suggested that just 1 person should do all of the work. He is going to be familiar with programs which do fast onscreen display of abc music, programs which play abc, programs which do musical analysis or use abc for archival or database purposes etc. Phil, this are all implementation specific issues which a standard should not address. As you indicated yourself, ABC is just an *abstract* computer representation of a computer score; all that the standard should do is to define this representation in an abstract way. Whether the *concrete* ABC files are to be played, displayed, printed or analyzed is up to the end user. What the internal data format of the handling program should be, is up to the software developer and depends on the task at hand. As several software developers already indicated, no major software package will consider to import or export ABC unless there exists a clear, well-defined and uptodate ABC standard. As such, I think we are by far better off with a possibly sub-optimal standard than with no standard at all! No standard can make all users or developers happy at the same time; no one can oblige all software developers to implement the standard. All we can do as an user group is to define a clear standard for those users and developers that feel a need for it and are willing to comply. To make sure that this will work out, we need a couple of leaders who make the final decisions based on input from this e-mail group. As I already stated, possibly sub-optimal decisions are better than no decisions at all! So, Jef and Guido, what do you think? Are you willing to discuss your ideas with us? Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
From: John Chambers [EMAIL PROTECTED] Maybe not. There is a fairly well-established convention in the computer biz that the first digit should change only when you break backward compatibility. Well I must admit I believe that well established is a slight exaggeration - different people do all sorts of things. Of course, such things are merely conventions, and lots of companies have violated them. A big number change is often done for marketing purposes, to convince users that it's something they should spend money on. As you say, especially if they're selling them: in that case changing the second digit is not nearly so good at generating upgrade sales g. But no matter, I'm not particularly attached to the idea one way or the other. The V lines don't break any pre-existing abc. They are a pure extension, not a change of any sort. So this should probably not warrant a jump to a version starting with 2.. I'm too new around here to know what traditional abc apps do when they find a V: line - append it I guess it mostly seems silly to see that we'd be telling people that there are two versions of abc, 1.6 and 2. In the Windows world we're used to a lot worse: 3.0 - 3.1 - 95 - NT3.1 - NT3.5 - NT4 - 98 - Me - 2000 - XP. A choice between 1.6 and 2.0 would look positively sane. :-) This sounds like a parody of how computer people do things. Self-parody is a noble art. :-) Anyway to put my oar in the water properly: I am not primarily concerned about whether new developments in abc initially favour one kind of musician or another. (As a sax player I find my needs are rarely considered by anybody - but that's another story.) The reason for my lack of concern is that, having read one or two of the documents I have been pointed at, I see current developments as moving abc towards a point where it can represent a vastly wider selection of music, with V: being the really major development, which people have apparently implemented slightly differently. If abc1.7 or 2 or plus can define a standard for that, and persuade authors to come together to the new standard, then I'm sure further developments will be easier rather than harder. My interest is in having MOZART (initially) import abc. The one thing I *don't* want is to have to do it 23 different ways according to which package wrote the file. So if there is a standard I can read it. If not, then, abc starts to look like something which would have been nice but I am sure many other software authors who have not yet implemented abc will feel the same way, and so a properly defined standard (including V:) may actually make abc take off at a much greater rate - even if it doesn't cover absolutely everything (yet). Casting a (very) fresh eye, over abc, I see various things which I would like it to do (and maybe it does some of them and I have missed it). But I am going to refrain from specific comment a little longer, because I understand Guido is writing a draft standard for abc plus, which is almost ready to see the light of day. I understand he is trying to maximise compatibility with those who have already extended the standard. Given that he calls it a draft, it seems that he is inviting comment (and I intend to g). I don't know the history of who has written which app, or whether anyone has an axe to grind or not, but given that Guido is actually doing something (which is usually more effective than talking about doing something), I would very much hope that some group of interested parties could coalesce around his draft, and, with that as a starting point, agree on a standard (and how to maintain it as a standard). If I write an abc importer, I don't want people creating files in 6 months time which will break it. If I write an exporter, I would really like the exported files to be readable by as many packages as possible. Next year 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
Re: [abcusers] The abc standard
On Tue, 1 Jul 2003, Bernard Hill wrote: But the 23 different ways is with us already it seems to me. Downloading files from various sources on the net has given a LOT of differences which can't all be correct at the same time. I even asked for advice from Chris Walshaw but no reply. As soon as there is an uptodate standard, your program can claim that it handles only standard ABC, and the 22 other ways will be deprecated. Users will be adviced to only use software products that comply to the new standard. It is a very good idea to add an ABC version field to the header, to distinguish old ABC from new ABC. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
In message [EMAIL PROTECTED], I. Oppenheim [EMAIL PROTECTED] writes It is a very good idea to add an ABC version field to the header, to distinguish old ABC from new ABC. That gets my vote. And/or a change of file extension. 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] The abc standard
From: Bernard Hill [EMAIL PROTECTED] I'm in a slightly worse position, Dave. Music Publisher 5's abc import facility is almost at the finished stage and I don't want to undo any code writing! I have made a lot of progress with MOZART's abc import, but as you indicate I still have a long way to go. I am trying to steer clear of multipart files until a spec turns up. (MOZART's main difficulty is that it is fussy about the number of beats in a bar. I know Music Publisher isn't. There are swings and roundabouts - but given that a lot fo Chris Walshaw's first simple examples - an obvious place to start - do not respect the number of beats in a bar, I suspect you had an easier time of starting than I did.) But the 23 different ways is with us already it seems to me. Downloading files from various sources on the net has given a LOT of differences which can't all be correct at the same time. That is what I was afraid of. I even asked for advice from Chris Walshaw but no reply. Me too. I gather he seems to have let go of abc. If I write an abc importer, I don't want people creating files in 6 months time which will break it. Too late I think. Unless you can prove otherwise ... :-) Always the optimist eh Bernard? Still one can always try :-) 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] The abc standard
Suggestions that we change the abc file extension to something other than .abc are kind of missing the point. File extensions are irrelevant in Classic MacOS, so BarFly will open any text file, regardless of extension. If the file contains any lines which start with X: it will treat what follows as an abc tune on request. Likewise, the oft-repeated suggestion that file headers should start with a version number which identifies the version of abc won't work either because users mostly won't bother. You have to remember that most users write their abc using a text editor. They make mistakes, and they leave things out. Now you might say that programs should be strict about interpreting it, and point out the errors. The problem there is that the net is full of erroneous abc, and if a program is too strict in it's interpretation, it's a pain in the arse to use, and users will choose to go elsewhere. So, interpreting abc is rather like interpreting a natural language. Whatever the standard says you have to bear in mind that this is a language which people use to communicate music to each other, with no computers involved (other than in the transmission part of the process). For this reason, interpreting abc is much, much harder than interpreting MusicXML (despite the fact that MusicXML is a much more complete language). Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
I. Oppenheim wrote: On Tue, 1 Jul 2003, Phil Taylor wrote: Over the past year or so, this group has become dominated by discussion of abcm2ps; Probably because it is the best and least limited ABC implementation around: it implements an extensive set of features, is actively developed, runs on all computer platforms that we use and gives excellent ouput quality! Have you ever used any other abc software? So, if we are going to hand over the development of the standard to one person, No one suggested that just 1 person should do all of the work. He is going to be familiar with programs which do fast onscreen display of abc music, programs which play abc, programs which do musical analysis or use abc for archival or database purposes etc. Phil, this are all implementation specific issues which a standard should not address. As you indicated yourself, ABC is just an *abstract* computer representation of a computer score; all that the standard should do is to define this representation in an abstract way. Whether the *concrete* ABC files are to be played, displayed, printed or analyzed is up to the end user. What the internal data format of the handling program should be, is up to the software developer and depends on the task at hand. Sorry, I don't understand what you're trying to say here. Are you suggesting that a standard can be developed without giving any consideration to what it's going to be used for? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
In message [EMAIL PROTECTED], Phil Taylor [EMAIL PROTECTED] writes Suggestions that we change the abc file extension to something other than .abc are kind of missing the point. File extensions are irrelevant in Classic MacOS, so BarFly will open any text file, regardless of extension. If the file contains any lines which start with X: it will treat what follows as an abc tune on request. Likewise, the oft-repeated suggestion that file headers should start with a version number which identifies the version of abc won't work either because users mostly won't bother. You have to remember that most users write their abc using a text editor. They make mistakes, and they leave things out. Now you might say that programs should be strict about interpreting it, and point out the errors. The problem there is that the net is full of erroneous abc, and if a program is too strict in it's interpretation, it's a pain in the arse to use, and users will choose to go elsewhere. So, interpreting abc is rather like interpreting a natural language. Whatever the standard says you have to bear in mind that this is a language which people use to communicate music to each other, with no computers involved (other than in the transmission part of the process). For this reason, interpreting abc is much, much harder than interpreting MusicXML (despite the fact that MusicXML is a much more complete language). Phil Taylor All good points. However it's when some peoplen use ~ to mean a roll and others use it to mean a turn that there are problems. Of course you can specify which you want with U: field but most examples I've seen don't. I don't believe it's only the ~ which has a problem either... 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] The abc standard
In message [EMAIL PROTECTED], David Webber [EMAIL PROTECTED] writes From: Bernard Hill [EMAIL PROTECTED] I'm in a slightly worse position, Dave. Music Publisher 5's abc import facility is almost at the finished stage and I don't want to undo any code writing! I have made a lot of progress with MOZART's abc import, but as you indicate I still have a long way to go. I am trying to steer clear of multipart files until a spec turns up. Well I'm revealing no secret to say that that is also my intention. (MOZART's main difficulty is that it is fussy about the number of beats in a bar. I know Music Publisher isn't. There are swings and roundabouts - but given that a lot fo Chris Walshaw's first simple examples - an obvious place to start - do not respect the number of beats in a bar, I suspect you had an easier time of starting than I did.) Perhaps so. But the 23 different ways is with us already it seems to me. Downloading files from various sources on the net has given a LOT of differences which can't all be correct at the same time. That is what I was afraid of. Consider: Is ~ a roll or a turn? [..] is the symbol for a chord, but I've seen +..+ also used Change of time sig (etc) can be done with [M:3/4] in the middle of a line or M:3/4 on a line by itself. But I've seen music with M:3/4 without brackets in a mid-line. My biggest wail is the end-of-line. The standard says that the end of line is the end of music line (unless terminated with \ character). But many tunes have silly numbers of bars, on a line, like 10,9,1 on 3 consecutive lines. Clearly needing relayout but then when to relayout a line, when not? I even asked for advice from Chris Walshaw but no reply. Me too. I gather he seems to have let go of abc. That explains it. Although the courtesy of a reply would be nice. 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] The abc standard
On Tue, 1 Jul 2003, Phil Taylor wrote: Have you ever used any other abc software? Yep, under both Linux and Windows (I do not have a mac). Currently I'm using mostly abcm2ps and abc2midi with a midi player, sometimes I use nwc2abc. Are you suggesting that a standard can be developed without giving any consideration to what it's going to be used for? It's going to be used to represent music scores in a way both comprehensible by human beings and computer parsers. From this it follows that the standard should define (1) musical elements that the members of this list want to be able to notate, in a way that is (2) convenient for human beings to read and write and (3) for computer systems to parse. If these three concerns are addressed by the standard, I do not see why it is important to know what happens with the ABC code after it gets parsed. 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] the abc standard
So, let's get down to the real business now, instead of just saying how it should be, or what kind of person . I suggest the following ABC standards committee with motivations why everyone is suggested. Comments and changes welcome, and those suggested are also welcome to say no. Jef Moine (because of abcm2ps) John Chambers (because of the tune finder, jcabc2ps, etc) Phil Taylor (because of BarFly) Henrik Norbeck (because of AbcMus and bnf spec) Guido Gonzato (because of abcplus and lots of other stuff) I suggest that if the committee cannot decide unanimously on parts of the standard, a majority vote is performed if we decide we really need that part of the standard. Is there really any need for just one person who runs it? No. We can divide some hands-on tasks among the committee (e.g. Henrik writes the bnf spec). Note that I have not included two people who have been important to abc development: Chris Walshaw and Jim Vint. I never see them discuss on this list, so I guess their current interest is minimal. Henrik Norbeck, Stockholm, Sweden [EMAIL PROTECTED] http://www.norbeck.nu/ My home page http://www.norbeck.nu/abcmus/ AbcMus player program http://www.norbeck.nu/abc/ 1900 ABC tunes http://www.norbeck.nu/blackthorn Irish trad music band http://www.rfod.se/folklink/ Links to Swedish trad music To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
On Tue, 1 Jul 2003, Bernard Hill wrote: Is ~ a roll or a turn? According to ABC 1.7.6, it's a roll: $ The standard set of definitions (if you do not $ redefine them) is: $ U: ~ = !roll! $ U: T = !trill! $ U: H = !fermata! $ U: L = !emphasis! $ U: M = !lowermordent! $ U: P = !uppermordent! $ U: S = !segno! $ U: O = !coda! $ U: u = !upbow! $ U: v = !downbow! If the user wants different behaviour, he can change the definition. [..] is the symbol for a chord, but I've seen +..+ also used The + notation has since long been deprecated. Change of time sig (etc) can be done with [M:3/4] in the middle of a line or M:3/4 on a line by itself. correct. But I've seen music with M:3/4 without brackets in a mid-line. incorrect. Should give either a warning or an error message. My biggest wail is the end-of-line. The standard says that the end of line is the end of music line (unless terminated with \ character). But many tunes have silly numbers of bars, on a line, like 10,9,1 on 3 consecutive lines. Clearly needing relayout but then when to relayout a line, when not? All the standard says is : Generally one line of abc notation will produce one line of music, although if the music is too long it will overflow onto the next line. So a newline does not force (but only suggests) a line break, and it is up to the program to come up with a sound layout algorithm. 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] The abc standard
Bernard Hill wrote: [..] is the symbol for a chord, but I've seen +..+ also used +...+ for chords is obsolete long, long ago. Change of time sig (etc) can be done with [M:3/4] in the middle of a line or M:3/4 on a line by itself. But I've seen music with M:3/4 without brackets in a mid-line. That's probably because of the infamous line-breaking daemon. M:3/4 without brackets mid-line has never been supported by any abc application as far as I know. My biggest wail is the end-of-line. The standard says that the end of line is the end of music line (unless terminated with \ character). But many tunes have silly numbers of bars, on a line, like 10,9,1 on 3 consecutive lines. Clearly needing relayout but then when to relayout a line, when not? Also blame the infamous daemon! Much of the abc available on the web has been sent through e-mail at some time. You just have to have a user option for when to relayout line breaks. Henrik Norbeck, Stockholm, Sweden [EMAIL PROTECTED] http://www.norbeck.nu/ My home page http://www.norbeck.nu/abcmus/ AbcMus player program http://www.norbeck.nu/abc/ 1900 ABC tunes http://www.norbeck.nu/blackthorn Irish trad music band http://www.rfod.se/folklink/ Links to Swedish trad music To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
I. Oppenheim writes: | On Tue, 1 Jul 2003, Bernard Hill wrote: | | Is ~ a roll or a turn? | | According to ABC 1.7.6, it's a roll: Of course, a lot of people would ask What's the difference? ;-) And a lot of arrogant musicians (like me) would say Who cares? and interpret it as a suggestion to ornament the note, deciding on the spur of the moment what ornament to play. | The + notation has since long been deprecated. Which does remind me of a suggestion I've long thought of making: Any Baroque musician is familiar with the convention that a '+' above a note means Ornament this note somehow. It's a generic, unspecific ornament symbol. I personally would like it to mean this in abc. This really just means that '+' would be added to the list of ornament symbols, and the default display form is merely a '+' above the note. It should be definable, of course. And a clever abc player program could pick a random ornament from its repertoire. Of course, a really clever player program could do this with any ornament symbol, preferably looking at the note's length and picking an ornament that fits within that length. Then the program would be approaching the level of an arrogant musician. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
On Tue, 1 Jul 2003, John Chambers wrote: This really just means that '+' would be added to the list of ornament symbols, and the default display form is merely a '+' above the note. Something like: U: X = ^+ ? 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] The abc standard
Irwin Oppenheim wrote: | On Tue, 1 Jul 2003, John Chambers wrote: | | This really just means that '+' would be added to the | list of ornament symbols, and the default display | form is merely a '+' above the note. | | Something like: | U: X = ^+ ? No, more like: ... | fe +d2 | c4 |] where the d has a '+' drawn above the note head. Of course, for the benefit of people who want to make the music a bit more specific, they could add U: + = trill to the headers, and then they'd get the Tr ligature above the note head. That would satisfy Romantic-era musicians, who mostly don't know this notation. But Baroque musicians would of course sneer at that, and prefer the plain '+' that doesn't presume to tell them how to ornament the note. (Then they'd complain about ABC's lack of all those overly-intricate ornaments that some Baroque composers liked to use. ;-) I just thought that we could get '+' added to the list of official ornament symbols before it gets gobbled up for some other use. And then, if you don't see the point in that notation, you can use a U line to use it for something else. There are lots of potential uses of '+' in musical notation. Maybe you'd like it for a quarter-tone sharp sign. (I've seen people use '+' this way. It makes sense, since visually '+' is half of a '#'. But this visual metaphor doesn't extend to quarter-tone flats.) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] the abc standard
responsibility over the standard. Personally, I would propose Jef Moine and Guido Gonzato: Jef because he's I think it's a good idea, if they agree of course ;) I think also of John Chamber. Just one comment: having a software developer in charge of standards is a conflict of interests. S/he can drive the standard in the direction of his/her own software. Since Jeff has included so usefull features in Abcm2ps, and developped some unofficial (but yet accepted) notations (such as the multiple voices) because the 1.6 standard hadn't evolved at all, it wouldn't be a problem if the new standard would include parts of what he did in Abcm2ps. I don't think I would have been interested to retranscribe so many ancient music tunes if Jeff hadn't extended more possibilities to the abc format. We recently had a brief discussion of some notation for traditional Persian music. Though I don't play that myself, I do have a number of recordings, and I found the discussion interesting. I think for this kind of music, or the special less used features (quartertone, microtone), they should remain included in some %% command so it wouldn't confuse old applications, or softwares whose developpers don't wish to include those features in them. I know also some applications crash when they recognize something they don't understand. With %% command, they just ignore this. Yeah, and I'd like to add that we also shouldn't have a musician in charge of the standard, since s/he can drive the standard in the direction of his/her own favorite musical styles. I propose myself for this, and since Metal is one of my favorite (folk-metal etc.), I'll add nice and usefull feature in the standard : With new fields and commands such as : Q:4/4=very very fast R:Broken triple kick drum K:disharmonical K:detuned W:[screamed]: D:best of %%ultraoverdrive %%distortion %%MIDI control 7 9500 I haven't included them yet in my metal conversions :), but more seriously it's still possible to render in abc some tunes created by metal musicians : http://anamnese.online.fr/abc/metal.abc (some tunes are not finished to transcribe yet) ps : about what Phil Taylor as added recently, I think he's not wrong, even if I didn't notice than this list was dominated by the Abcm2ps corporation :) I don't think such a person exists. It's a job for a committee. It's what was proposed. If you think you could fit also in this committee, I believe you could do this job well. I read what you wrote about multivoice, and used it when I begun to learn about it. But the committee shouldn't involve too many pple, otherwise they will never agree and things will never take a step further. About looking for full range notation for such a little format, it'd be difficult to let it be able to notate all. Coming again on abcm2ps, I find it suits all my need (when I use it with Abc2midi), it's still very powerfull in its present form. I've never be able to enter efficiently notes with a mouse, so I like to type them instead. I use it also to write folk tune when I don't have any computer at hand. If I'd feel the need to use a all in one software with many specific notations and effect I think I'll look toward software that handle xml for ex. The output format is impossible to read by human, but it's not restricted. A format such as abc, even if it's wonderfull and I don't wish to use another one, will always be limited in comparison to MusicXML. In fact in my opinion NO program should break backward compatibility! It's also a reason why I advocate for the use of %% for new features. and .abc files written to the old 1.6 standard, the question is what the old apps do when they meet one of the new files. AFAIK there I think it'd be difficult to avoid notation such as the x for the invisible rests... I don't think it would be used in folk tune for ex. so only tunes with heavy needs would need this, that mean they would include also V: and other unsupported features in old app. It is a very good idea to add an ABC version field to the header, to distinguish old ABC from new ABC. I think it's a good idea too, and I'm willing to do it for abc following the Abcplus extentions, or not in the 1.6 standard (or at least try to do my best to find them all) ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
In message [EMAIL PROTECTED], John Chambers [EMAIL PROTECTED] writes I. Oppenheim writes: | On Tue, 1 Jul 2003, Bernard Hill wrote: | | Is ~ a roll or a turn? | | According to ABC 1.7.6, it's a roll: Of course, a lot of people would ask What's the difference? ;-) And a lot of arrogant musicians (like me) would say Who cares? and interpret it as a suggestion to ornament the note, deciding on the spur of the moment what ornament to play. A roll can mean quite a different thing to (eg) a dulcimer or auto-harp player and the playback would be totally different. | The + notation has since long been deprecated. Which does remind me of a suggestion I've long thought of making: Any Baroque musician is familiar with the convention that a '+' above a note means Ornament this note somehow. It's a generic, unspecific ornament symbol. I personally would like it to mean this in abc. This really just means that '+' would be added to the list of ornament symbols, and the default display form is merely a '+' above the note. That's available with ^+ notation. The .. is for text and the ^ says it's not a chord symbol but the text which follows, ie a + And I feel that if there is music out there using +..+ for chords then you are confusing the isue. It should be definable, of course. And a clever abc player program could pick a random ornament from its repertoire. I take it that's a joke? :-) Of course, a really clever player program could do this with any ornament symbol, preferably looking at the note's length and picking an ornament that fits within that length. Then the program would be approaching the level of an arrogant musician. :-) 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] The abc standard
In message [EMAIL PROTECTED], Henrik Norbeck [EMAIL PROTECTED] writes Bernard Hill wrote: [..] is the symbol for a chord, but I've seen +..+ also used +...+ for chords is obsolete long, long ago. Great. But does that mean there's no music out there with +..+? Change of time sig (etc) can be done with [M:3/4] in the middle of a line or M:3/4 on a line by itself. But I've seen music with M:3/4 without brackets in a mid-line. That's probably because of the infamous line-breaking daemon. M:3/4 without brackets mid-line has never been supported by any abc application as far as I know. My biggest wail is the end-of-line. The standard says that the end of line is the end of music line (unless terminated with \ character). But many tunes have silly numbers of bars, on a line, like 10,9,1 on 3 consecutive lines. Clearly needing relayout but then when to relayout a line, when not? Also blame the infamous daemon! Much of the abc available on the web has been sent through e-mail at some time. You just have to have a user option for when to relayout line breaks. Funny enough, that's what I've done. I've also given the user the code to edit (and optionally save) if s/he wants before the Import process. 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] The abc standard
From: Bernard Hill [EMAIL PROTECTED] Consider: Is ~ a roll or a turn? It was so vague in the origibnal spec that I was considering ignoring it :-) [..] is the symbol for a chord, but I've seen +..+ also used [ ] is what the spec says and so that is what I have implemented. Is ++ written down anywhere? Change of time sig (etc) can be done with [M:3/4] in the middle of a line or M:3/4 on a line by itself. But I've seen music with M:3/4 without brackets in a mid-line. The original spec seems a bit loose about whether M:3/4 needs a line to itself - I am *trying* not to make assumptions about it. My biggest wail is the end-of-line. The standard says that the end of line is the end of music line (unless terminated with \ character). But many tunes have silly numbers of bars, on a line, like 10,9,1 on 3 consecutive lines. Clearly needing relayout but then when to relayout a line, when not? I'm thinking about that one. the easiest thing with MOZART is just to ignore abc's end of lines and let it reformat - it does that anyway as bars grow and shrink. Alternatively I could put a hard line break where abc lines change - I'll suck it and see. MOZART is quite accustomed to doing a lot of formatting itself and by default after MIDI import it reformats absolutely everything as MIDI contains no format information. So I'm heading at things backwards with MOZART by letting it do all its own formatting, and gradually telling it to respect more of the contents of the abc file. 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] The abc standard
In message [EMAIL PROTECTED], I. Oppenheim [EMAIL PROTECTED] writes On Tue, 1 Jul 2003, Bernard Hill wrote: Is ~ a roll or a turn? According to ABC 1.7.6, it's a roll: $ The standard set of definitions (if you do not $ redefine them) is: $ U: ~ = !roll! $ U: T = !trill! $ U: H = !fermata! $ U: L = !emphasis! $ U: M = !lowermordent! $ U: P = !uppermordent! $ U: S = !segno! $ U: O = !coda! $ U: u = !upbow! $ U: v = !downbow! If the user wants different behaviour, he can change the definition. As long as he knows how. Can I ask how many abc users are used to editing the language, or do they just use it to print/play tunes on the net? [..] is the symbol for a chord, but I've seen +..+ also used The + notation has since long been deprecated. Change of time sig (etc) can be done with [M:3/4] in the middle of a line or M:3/4 on a line by itself. correct. But I've seen music with M:3/4 without brackets in a mid-line. incorrect. Should give either a warning or an error message. My biggest wail is the end-of-line. The standard says that the end of line is the end of music line (unless terminated with \ character). But many tunes have silly numbers of bars, on a line, like 10,9,1 on 3 consecutive lines. Clearly needing relayout but then when to relayout a line, when not? All the standard says is : Generally one line of abc notation will produce one line of music, although if the music is too long it will overflow onto the next line. So a newline does not force (but only suggests) a line break, and it is up to the program to come up with a sound layout algorithm. But I take it that the sentence above means that it WILL break at a line end and MAY break elsewhere... The problem as a developer is that we're second-guessing writers of bad abc notation. 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] the abc standard
Forgeot Eric mentioned: | | I think it'd be difficult to avoid notation such as the x for the | invisible rests... I don't think it would be used in folk tune for | ex. so only tunes with heavy needs would need this, that mean | they would include also V: and other unsupported features in old | app. Actually, I find the y invisible, unplayed rest more useful. For example, if you want the somewhat conventional comma-like phrasing/breath mark above the staff, abc2ps produces a fine result if you write ,y This positions the symbol properly between two notes, and adds a bit of extra space. There are a number of abc thingies that can only be produced above/below a note. Rests are quite sensibly counted as notes by most progams, so you can gedt those thingies isolated by attaching them to a rest. A rest that is otherwise ignored is a very good tool for this. This is a bit of a kludge ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] the abc standard
Henrik Norbeck wrote: So, let's get down to the real business now, instead of just saying how it should be, or what kind of person . I suggest the following ABC standards committee with motivations why everyone is suggested. Comments and changes welcome, and those suggested are also welcome to say no. Jef Moine (because of abcm2ps) John Chambers (because of the tune finder, jcabc2ps, etc) Phil Taylor (because of BarFly) Henrik Norbeck (because of AbcMus and bnf spec) Guido Gonzato (because of abcplus and lots of other stuff) I suggest that if the committee cannot decide unanimously on parts of the standard, a majority vote is performed if we decide we really need that part of the standard. Is there really any need for just one person who runs it? No. We can divide some hands-on tasks among the committee (e.g. Henrik writes the bnf spec). I am against the idea of a committee without a leader. The end responsibility should be with one person only. The previous attempt did not work out and I don't see any reason why it should now. To put it to the extreme: a benevolent dictator will be infinitely more beneficial to the abc community than a democratic body of people that will never agree on everything (if anything at all)... The committee in itself is a good idea (and all the people Henrik mentioned deserve to be part of it (sorry for not mentioning you in my original posting, lads)), but if we want the standard to go forward, there should be only one leader... Let´s get over our fear that our favourite non-standard feature will not be included in a future standard. Leaders of open-source projects are generally also very open minded and I´m sure all the ´papabiles´ mentioned above are no exceptions. bert -- Bert Van Vreckem Not all chemicals are bad. Without chemicals such as hydrogen and oxygen, for example, there would be no way to make water, a vital ingredient in beer. -- Dave Barry To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc standard
I. Oppenheim writes: | On Wed, 2 Jul 2003, John Chambers wrote: | I'd suppose that the answer would be that the bangs | are optional. | | I'm not sure that this will always work. For example: | | A!1!B versus A1B | | and even | | AaccentB | | could be difficult to parse, since a c and e are valid | note names. Many parser systems like yacc or bison | won't like this. | | So why not stick to the bangs to keep these things | a little clean? Or did I miss something? I don't think you missed anything. I basically agree, but I'd like to hear arguments for the other side. Actually, my main reasoning is that of a programmer: If we want everyone to implement this U: header, it should be as simple as possible. A string substitution is about as simple as it gets, and very easy to implement in just about any language. And it's very easy for users to learn. This by itself seems to be enough to argue for U: t=!trill! as the only syntax. Then there's just an expansion pass, followed by a parse by a routine that expects all those !...! terms. The builtin ornaments can generally be handled easily by setting them up as compiled-in substitutions. If we have a separate %include gimmick, we can easily provide some packaged definitions for different kinds of music. Still, I always think I might have missed something, so we should see if anyone else wants to argue for a different approach. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] the abc standard [was: abc - the new HTML?]
Atte wrote: | On Wed, 6 Feb 2002, John Chambers wrote: | | snip I'm not up to | | date with the work on the standard, is there still a commission | | working on what to include in the standard? I really think this work is | | extremely important if abc is to have any future. | | What seems to have happened is more or less consistent with the past | work on abc. The (semi-official) standards committee started with the | idea that what it needed was a clear formulation of abc version 1.6 | as a standard, and has worked on codifying that. New features are to | be put off until the current standard is established. Of course, this | is of little relevance to people who need things not covered by | version 1.6, so those of us have continued on our merry way inventing | random extensions for our own use, and wondering if the standards | folks will ever catch up. | | Ok, who's in the committee, where can one follow the progress of their | work, and what do they have to say? http://abc.sourceforge.net/standard.html I hope nobody on the committee objects to this being posted. It's at sourceforge, so I expect that everyone understands that everything there is pretty much all public information. You need to get a project admin to approve changes, but reading a project's info is pretty easy. BTW, if you just go to sourceforge.net and use the search widget, you'll find a number of other ABC-related projects. There's one that converts DNA sequences to ABC, so you can play a gene. I'm not sure what value this may have ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] the abc standard [was: abc - the new HTML?]
On Wed, 6 Feb 2002, John Chambers wrote: | snip I'm not up to | date with the work on the standard, is there still a commission | working on what to include in the standard? I really think this work is | extremely important if abc is to have any future. What seems to have happened is more or less consistent with the past work on abc. The (semi-official) standards committee started with the idea that what it needed was a clear formulation of abc version 1.6 as a standard, and has worked on codifying that. New features are to be put off until the current standard is established. Of course, this is of little relevance to people who need things not covered by version 1.6, so those of us have continued on our merry way inventing random extensions for our own use, and wondering if the standards folks will ever catch up. Ok, who's in the committee, where can one follow the progress of their work, and what do they have to say? -- Atte To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
