Jean-Francois Moine wrote: | On Fri, 16 May 2003 16:00:33 UTC, John Chambers <[EMAIL PROTECTED]> wrote: | >Actually, I've sent him a message or two on the topic, but I didn't | >get a reply. He's probably busy. I also looked at abcm2ps briefly, to | >get a feel for how difficult it might be. Some of his changes are in | >different directions than mine, and the two programs obviously can't | >be combined in any simple way. What I'd have to do is repeat the | [snip] | Hello John, | I don't remember any message from you. BTW, in your package, I saw you | have still old e-mail addresses of me. Now, my only address is the one | in my signature below.
That might explain the silence. ;-) I didn't see any bounces, and just assumed that the messages got buried in the usual pile of email. | I quickly looked at jcabc2ps (version Sept 2002 - is it the last one?), | and I found little extensions: | | - explicit accidentals in key signatures, | - more measure bar types, | | and also an other syntax for the clef vertical offset. | | Adding these topics in abcm2ps could be done in a next release, I think | before end of June. | | Do you see anything else? My jcabc2ps clone has a flock of "little" extensions. The biggie is probably the explicit keysigs, which requires a significant change in now keysigs are represented. Actually, it's not much conceptually. The original code uses an int to represent the keysig, which works for Western classical music but not for others. However, when the code gets around to producing the keysig, it builds a little array that lists the accidentals explicitly. What needs to be done is to replace the accidental count with the actual list of accidentals. This is reasonably straightforward, but does require rewriting nearly every bit of code that deals with key signatures. The original parse code that handles K:<tonic><mode> becomes the place where the list of accidentals is filled in, and after parsing the <tonic> and <mode>, it can look for a list of notes that just get added to the keysig list. It's a bit of work, but not conceptually difficult. There have been several suggestions for deciding the octave mapping, and it turns out that you need to handle it in both the K and V code. I've mostly used the "middle=" (or "m=") syntax in my abc, but there was also the suggestion of "clef=bass," and "clef=bass,," for bass lines using one or two commas to decide the octave. My tune finder found some abc that used these, so I implemented them, too. Both seem reasonable to me. The "middle=" syntax is more general, since it allows you to say something like "clef=treble middle=d" to get the so-called "French violin clef" that the Early Music crowd sometimes uses. My code also lets you add "-8" or "+8" to clefs, which does nothing more than add an '8' below or above the clef symbol. You'll also see "-16" and "+16" in the code. (Yeah, I know it really should be "-15" and "+15", but I haven't seen that yet, and I've been lazy.) I also really liberalized what the code would accept as bar lines. My tune finder kept giving lots of errors because of the many ways that people (or programs) write bar lines. My code now accepts such things as :||, :|], |]|, etc, and does something sensible with them. Cases like |]| are useful, because you see thin-thick-thin phrase boundaries in printed music, and it's useful to be able to transcribe them. Part of this was to accept multiple colons and produce them in the output. This makes it possible to use the conventional notation |:: ... ::| to mean "Play this three times". The code will also acdept variants such as [|:: ... ::|] and do the Right Thing with them. One thing it doesn't do yet is recognize a : not next to | and draw it. This isn't what I'd call very good notation, but I see it in music, and I think it should work. Anyway, it's in my ToDo list. There is also a significant addition to endings. These all work: |: ... |1,3 ... :|2,4 ... :| |: ... |1-3 ... :|4 ... :| |: ... |["N times" ... :|["Last time" ... |] The last case, with explicit text under the ending bracket, only works if you use the [, since without it there's no way to tell the ending text apart from an accompaniment chord. The unquoted syntax only accepts digits, commas and hyphens at present. (Some people like to use dots, but this turned out to be difficult to distinguish from the ornament, so I gave up trying to handle it. You can always use the quoted syntax if you really want a dot.) Another thing I did was to extend the parser for Q lines so that X/Y is generally replaces with the equivalent note if X/Y looks like a note length. This lets me write things like "Balkan" rhythms as Q: 4/8 3/8 4/8=70 This produces the conventional notation that shows the three notes (quarter, dotted-eighth, quarter) followed by "=70" above the first line of music. I can also use quoted text in Q lines: Q: "Adagio" I also added a "none" to a lot of headers, so that M:none produces music with no time sig, clef=none produces a staff with no clef, and T: without any text produces no title. One benefit of this is that I have a collection of abc "tunes" that produce pages of manuscript paper with staves in various scalings and spacings, without any music cluttering up the output. Another significant use of this is that I can write abc for a fragment of music, to use as illustrations in text. I then use abc2ps to generate a PS file, and then convert it to GIF or PNG or whatever, with the white stuff all trimmed away. I can then include this as an image in a web page. Discussions of this have often gotten responses of the "Why would you want to do something so stupid?" sort, but fragments of music are very useful if you're trying to illustrate a text about music. If you are trying to write a musical document, it's very annoying to have software that insists on putting things like titles, time and key signatures, bar lines, etc. on every piece of music. I can write: T:none M:none L:1/8 K:none %%staffwidth 50 GBd G3 This produces just the four notes on a very narrow staff without any sort of additional junk. Another subtle change is that jcabc2ps will act as a normal unix "filter" program. Given no input files, it reads from stdin, and the output defaults to stdout. I've found this really useful in writing scripts for an abc web site. However, as part of this, I had to do some significant rewriting of the way the program handles its command line. In fact, one of the thing that I did (mostly to preserve my own sanity) was to revise the way that command-line flags are handled. I simply adopted the approach that an initial '-' always has a negative meaning, while '+' is positive. A trivial example is that "-x" means "Don't produce index numbers", while "+" means "Produce index numbers". Making this consistent really helps when you're trying to write complex web scripts that call the program. This approach has popped up here and there in unix software, but of course it's not at all widespread yet. It's useful for programs with a zillion options. It also makes the code much easier to follow. I've been thinking of adding code to also accept the GNU "--" syntax as a synonym for "+", but I haven't gotten around to it. I really should. Of course, with the program writing to stdout, the usual "-o -O" can be rewritten as just ">". Another recent change was to simplify the handling of a final '\', so it always means "Continued on next line". The original code was a bit confused about this, and not very predictable. The abc that I see on the Net implies that different abc tools do this differently. I think the only reasonable solution is to adopt this simple rule, so that users can understand it. The !...! syntax is recognized, but not as well as abcm2ps, so that can probably be ignored. But there is a kludge to try to recognize the funny abc2win syntax that puts ! chars at apparently random places in the abc. My code basically tries to ignore an isolated ! if it is followed by end of line or anything that contains a space. I'm not sure if this is the best heuristic, but it has worked so far. I do wish we could get this program updated, but there's so much abc Out There that uses its syntax that it's probably hopeless, and only rank kludgery can solve the problems that it causes. I've also been slowly collection a lot of tiny test cases: http://trillian.mit.edu/~jc/music/abc/src/jcabc2ps/abc/ Anyway, I'd agree that merging all this into abcm2ps (and maybe calling the result "abc2ps" ;-) would be useful. But I do think it might be a bit of work. If we could do a lot of internal documentation and make it a real Open Source project, I'd be all in favor of it. Finding the time is a question, though. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
