Re: [abcusers] another pebble on the beach
Jack Campin wrote: Another version of Shingly Beach, using lots of BarFly-specific tricks to fit it on one page, landscape format. Sent as an attachment in case of linewrap problems. I'll leave it to Phil to turn it into a GIF with the latest anti-aliasing version. See http://rbu01.ed-rbu.mrc.ac.uk/shingly.gif (Phil: you will notice a bug in the display of the C crotchet in bar 4, Looks OK to me. an ugly blob in the F-crotchet-against-G-quaver at the end of the second line, Yes, if you want a program to be fast enough to let you do live editing, and run on 8-year old machines you have to draw the line somewhere, and scanning every note to see if it conflicts with any other in any voice is a little beyond that line. (Mind you, so is antialiassing, unless you've got a fast PowerMac, so it might come in as an option at some point.) and that y is a hack that shouldn't be needed). Same applies. The 'y' gets you where you want to be without using a lot of processor cycles. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] The Irish MP3 Player
(It's a Feadog tin whistle:-) Joke from an article in today's Guardian On Line section on music on the web, which has quite a lot to say about abc and gives a mention to Muse, BarFly and a paragraph to Frank's MusicaViva site. http://www.guardian.co.uk/Archive/Article/0,4273,4215819,00.html Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] chords writing in abc
Eric Forgeot wrote: One example X:21 T:Branle R:Branle C:Tielman Susato Z:[EMAIL PROTECTED] M:6/8 L:1/8 Q:1/4=110 K:C V:1 cde def | cde d3 :: ede cde | f2 e d3 :|] V:2 %%MIDI transpose -12 [G2e2] [ce] [B2g2] [Af] | [A2e2][ce] [G3d3] :: [C2c2] [Cc] [F2a2] [Eg] | [D2f2] [Cg] [B,3g3] :|] V:3 %%MIDI transpose -12 CB,C G,2 D | A,B,C G,3 :: gfg cAB | dAc B3 :|] In fact my partition gives me only one staff for V:2 V:3. With abc2ps for exemple, the result is less impressive than in the original partition. And if this example is rather simple (one can easily split the original partition into 2 or 3), in some partitions where the voices cross each others, this can be rather difficult. Is there a solution for the future ? Merging multiple voices onto one staff is a tricky problem for the programmer. Human music engravers have all kinds of little tricks to solve the conflicts which occur (turning note heads round, adjusting the positions of rests up and down etc). It will be a while before abc programs can do that automatically. Life gets especially complicated where the voices cross over. In this particular case, where V:2 and V:3 are actually played by the same instrument you might be able to improve things by moving notes from one voice to the other, replacing them in the original voice with invisible rests (x). So the last bar of V:2 and V:3 could be written as: V:2 | [D-df-][ADf] [Ccg] [B,3B3g3] :| V:3 | x3 x3 :| Another possibility is to control the direction of the note stems on a note by note basis. I don't know if any programs allow you to do this at present, but it will probably be required in future. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] chords writing in abc
Frank Nordberg wrote: For those who isn't sure what this is about, I've uploaded a pdf with something similar to what I think Eric is looking for at: http://www.musicaviva.com/temp/de-madrigale-a1gtr.pdf and a midi at: http://www.musicaviva.com/temp/de-madrigale-a1gtr.mid Here's the original four part setting: X:26 T:De madrigale C:Tielman Susato S:Tileman Susato: Danserye (1551) M:3/2 %org. time signature: C3 %org. no barlines L:1/2 K:Gmix V:1 CDE|DEF|CDE|D3::EDE|CDE|F2E|D3:| V:2 G,2C|B,2A,|A,2G,|G,3::C2C|CA,B,|DA,C|B,3:| V:3 E,2E,|G,2F,|E,2C,|D,3::G,F,G,|A,2G,|F,2G,|G,3:| V:4 C,B,,C,|G,,2D,|A,,B,,C,|G,,3::C,2C,|F,2E,|D,2C,|G,,3:| See http://rbu01.ed-rbu.mrc.ac.uk/DeMadrigale.gif for BarFly's version. To be honest, I don't think there is really an abc-only solution for this kind of thing. To get this picture I added the following lines to the header: V:1 m=B, V:2 up m=B, transpose -12 V:3 merge m=B, transpose -12 V:4 down merge m=B, transpose -12 This did everything except the offset G in bar 5 in the lower staff. That I did by post-editing in a drawing program. Unless we add some complex and messy syntax for special formatting to the abc standard these fine adjustments will always involve some human intervention. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] chords writing in abc
Frank Nordberg wrote: To sum it up, both BarFly and abcm2ps seem to handle this particular job fairly well - slightly better than I had expected, but there are still a few problems: 1. As far as I know both programs are single platform applications: BarFly is Mac only, and from Jean-Francois' site I gather that abcm2ps is Linux only. abcm2ps is written in ANSI C and could be compiled for other platforms without much trouble. BarFly would require an enormous amount of work to port elsewhere. 2. The two programs require different ABC extensions, so you'll have to post two different versions of the file. Not necessarily. abcm2ps doesn't have the middle= directive, so the tune has to be transposed into the right octave, but that will be OK in BarFly. BarFly will ignore abcm2ps's %%staves directive, and abcm2ps will probably ignore the V: fields in the header in which BarFly stores the same information. BarFly doesn't like the clef specifiers on the same line as the V: fields in the tune, but they would probably work in both programs as an inline K: field [K:treble], and in any case they are redundant in this case since both programs will default to treble clef. Maybe somebody could try this out with abcm2ps and see if it works: X: 26 T:De madrigale C:Tielman Susato S:Tileman Susato: Danserye (1551) M:3/2 %org. time signature: C3 %org. no barlines L:1/2 V:2 up transpose -12 V:3 merge transpose -12 V:4 merge down transpose -12 K:C %%staves 1 (2 3 4) V:1 cde|def|cde|d3::ede|cde|f2e|d3:| V:2 G2c|B2A|A2G|G3::c2c|cAB|dAc|B3:| V:3 E2E|G2F|E2C|D3::GFG|A2G|F2G|G3:| V:4 CB,C|G,2D|A,B,C|G,3::C2C|F2E|D2C|G,3:| 3. Stem directions and empty bars aren't problems in this particular example, but they can be major headaches in slightly more complex pieces. As far as I know, BarFly is the only program that offers a useable solution to the latter, while none seem to be able to handle the former properly. Doesn't abcm2ps have the invisible rest x? abc2ps does. I could easily fix BarFly to change the stem directions in mid tune. Maybe in an inline K: field again as for clefs. 4. Most important of all: We're talking about program specific extensions to the ABC standard here, and that wasn't what Eric asked for. Guess it's time for the abc standard committee to start working! All extensions start out as program-specific. If they turn out to be useful they get adopted by other programs. The w: field for words started in abc2ps and is now supported by most programs. M:none started in BarFly. middle = started in Muse and is now supported by BarFly. Use of abc for Gregorian chant notation started in BarFly and is now supported by Melody Assistant. Multivoice abc using V: started in abc2midi and (at least in its basics) is now supported by most programs. Irritating though it is for users, that seems to be the way that the language progresses. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] linux only ?
John Chambers wrote: Frank Nordberg wrote: | James Allwright wrote: | Unless it has changed radically since I last looked, it is a source code | distribution that will compile and run on anything with a C compiler... | | That's really great, but there's still a minor problem. | | One of the basic ideas behind ABC is that it's for everyone, and - as | hard as it is for us to believe - there is, even today, a small minority | of computer users that feel slightly uneasy when asked to compile the | software themselves... Great! Someone provides a program that solves the problem of binary incompatibility by supplying the source in ANSI C. Several people report compiling it on various obscure systems without any problems. So the programmer gets criticised for writing a program that needs to be compiled. Ya sure can't win at this game. ;-) Nobody's criticising the author of the program. However, the explosion in computer use over the past few years has mainly come about as the result of GUI interfaces like Windows and MacOS which don't require users to mess with the works. Most users don't understand the difference between source and object code and wouldn't have a clue what to do with a C compiler. Neither do they want to learn - they are not interested in computers per se, only in what they can do with them. This is not just a problem for technophobes either. I once spent a whole day trying to install gcc on a Silicon Graphics Indy, eventually giving up in disgust and trashing the whole thing. I just don't have the time to mess with a system which only delivers incomprehensible error messages. I still have the machine, but the only software on it is stuff which is obtainable in binary form. (I have been tempted to translate abc[m]2ps to perl, just for the yuks, and for extra portability. Then it wouldn't have to be compiled. But I bet I'd get flamed because perl doesn't come pre-installed on all possible computer systems. ;-) Sure. Most MacOS users can't even use AppleScript (which has to be the world's easiest scripting language) let alone perl. It's a simple fact of life that no Mac user is going to be able to use abcm2ps until I, or Wil Macauley or somebody else who knows how to do it compiles it for them and hands out the binary. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] linux only ?
| (I have been tempted to translate abc[m]2ps to perl, just for the | yuks, and for extra portability. Then it wouldn't have to be | compiled. But I bet I'd get flamed because perl doesn't come | pre-installed on all possible computer systems. ;-) | | Wouldn't the most portable language for it be PostScript itself? You might think so, but it seems that Windows systems still don't come out of the box with a postscript viewer. Pretty much everything else does, though. The idea of doing it in postscript is interesting. I wonder how difficult it would actually be? Postscript is a threaded interpreted language. I don't know Postscript, but I do know Forth, which is a close relative. The joke which everybody knows about Forth is that it's a write-only language. Code which you wrote yesterday is unreadable today. It's very terse and quick to write but impossible to understand later, and it makes programs impossible to maintain. I would guess that Postscript, which is designed to be written by software rather than humans, will be even worse in this respect than Forth. On the Mac, Postscript as a graphics format is a serious pain in the posterior. The only thing you can do with it out of the box is to print it, and that only if you have a Postscript capable printer. Most users don't even know how to do that, and even for those that do there are other problems. Because sending Postscript files to the printer bypasses the normal Page Setup and Print dialogs you are stuck with the layout which is written into the file. If the file was created for a larger page size than your paper the margins are going to be cut off, and there's nothing you can do about it, other than go back to the original program and recreate the file (if possible). Hardly any of the graphics software can import Postscript, so if you want to look at the contents of the file you have to install Ghostscript/MacGS viewer. This is a wierd program which doesn't pay much attention to the MacOS user interface and has menus full of incomprehensible and undocumented commands. But it will let you look at the pictures in the file (one at a time, and only in the order in which they exist in the file), and it will let you convert them to a more tractable graphics format, albeit at a fixed resolution. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] chords writing in abc
Bryan Creer wrote: Phil Taylor wrote - All extensions start out as program-specific. Why? Why shouldn't they start out as proposals for discussion and feedback from other developers and even users? That way the idea might be improved on and clashes avoided and the resulting definition included in the standard for all to see. Two reasons. 1. Anything but the most simple extension needs some experimentation to find out what works. You've got to do it first, then try it out with a lot of music to see if it's a good idea. 2. If we had to wait for agreement nothing would ever get done. If they turn out to be useful they get adopted by other programs. If other developers can be bothered, can find any documentation, aren't openly hostile to the person who originated it, can work out which of the several versions is the definitive one. (When I asked which version of V: I should use, I was told to stop whining.) Nobody's hostile to anyone here (present company excepted, of course). Documentation is a problem of course. I've never been able to figure out how the %%staves directive is supposed to work. The w: field for words started in abc2ps and is now supported by most programs. M:none started in BarFly. Well, at least these made it into the draft standard. middle = started in Muse and is now supported by BarFly. Use of abc for Gregorian chant notation started in BarFly and is now supported by Melody Assistant. Which these didn't. middle = was proposed after the draft standard appeared. I never bothered proposing Gregorian chant as a general standard as it's such a specialised area. I was quite surprised that Melody Assistant adopted it. Multivoice abc using V: started in abc2midi and (at least in its basics) is now supported by most programs. In at least two incompatible versions (see above). Not completely incompatible (see above). Irritating though it is for users, But who gives a *@%$ about them? that seems to be the way that the language progresses. But it doesn't have to be. What is the standards committee for? I notice that in your list of examples you don't include the !symbol! syntax which is in the draft standard but, judging by a recent exchange, you are very unlikely to implement in BarFly. The draft standard is just that. It represents one person's proposals put up for discussion. I've made my opinion on that section clear on several occasions, and will continue to do so. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] little V: comment
Jean-Francois.Moine wrote: There have been many proposals for V: in ABC, but as it seems the standard advances very slowly, I would just ask Phil about its comment in the 'Shingly Beach...s' thread: This is fine for BarFly, but other programs don't like having the V: fields on the same line as the music, so I fixed that. It's much less readable, but should work in most programs Do you really think that: V:1 D | G4 c4| Bd cA F2 D2 | ... is less readable than: [V:1] D | G4 c4| Bd cA F2 D2 | ... ? No, but it's more readable than V:1 D | G4 c4| Bd cA F2 D2 | ... (which was what I was discussing) because that spreads the tune out vertically by inserting an extra line between each voice, so it's not as easy to compare the corresponding notes in different voices. I do suggest in the BarFly documentation that users should use this syntax for tunes which are to be uploaded, for the sake of compatibility. [V:1] D | G4 c4| Bd cA F2 D2 | ... doesn't currently work in BarFly, although I probably will implement it as a third alternative. What worries me about the use of an inline field for V: is that it is an invitation to people to put [V:2] in the middle of a line. After all, that's what inline fields are for. In this case, however, it makes no sense at all to change voices in mid-line. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Standards committee
John Chambers wrote: Steve Mansfield asks: | Mention of the standards committee prompts the thought : Y'know, I haven't received any email from them recently. Either there's no current activity, or I've been dropped from the mailing list. Maybe I should ask. Probably no need to, though, since all of the committee are on this list. I think it's probably the holiday season. We haven't heard anything on this list recently from Laurie, Robert, Laura or John Atchley. | Where's the standards committee up to? Are we any closer to putting some | of the current incompatibilities and bifurcations to the vote? As far as I'm aware, the activity so far has been mostly to work on a more formal baseline standard that matches Chris's 1.6 doc. | And, in the mean time, can I take this opportunity to repeat my request | for some kind person to point me at the URL of the page someone put | together recently about the differences and similarities between the two | (+?) versions of the V: field? I've been experimenting a bit in my tune finder's clone of abc2ps, to see how much of the extant V: lines I can get it to handle automatically. So far, I think there's actually no important incompatibility other than the old octave question (whether bass lines need zillions of commas). The rest of the V: clauses can simply be merged. The proposed middle= clause seems a very usable solution to the octave that also has the benefit of allowing people like me to define things like French violin clef and various other non-standard note-to-staff mappings. I'm still contemplating a heuristic to try to discover which mapping was used when there's no middle= clause, but I haven't implemented it yet. Maybe I should get at it. How about this: If there's a middle = directive then use that else If there are V: fields in the header of the tune it was written for BarFly. If there are no M= or middle= directives in those fields then the mapping is middle = B for the treble clef, middle = D, for the bass. else If there's a %%staves directive it was written for abc(m)2ps, and the mapping is middle = d for the bass. else If there's a %%MIDI directive it was probably written for abc2midi, and the mapping is as for BarFly. else count the commas. There are some things in V: lines that I don't understand and are currently ignored by my abc2ps clone. Maybe I should make up a list of them and ask what they mean. So far, ignoring them seems to have worked. I suspect they have something to do with producing sound files, which abc2ps doesn't do, so they may not be significant to me. All the stuff that goes in V: header lines in BarFly can be ignored. You will just get a basic interpretation of the abc with as many staves as there are voices, all bracketed together, default note mapping and no transposition, default instruments for playing and so on. I have seem some symptoms of people who have discovered the V: lines and are using them without invoking any abc software. That is, V: lines are being used to communicate to other human readers of the abc. I suspect that there are more abc readers about than many of us might guess. For someone who doesn't read music, abc may be easier to learn than standard staff notation. This would, of course, lead to a lot of illegal V: lines in the abc that we see on a number of music mailing lists. I can see that we're going to end up having to write smart software which can figure out the right answer from anything which looks like abc. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] chords writing in abc/little V: comment
John Chambers wrote: Bryan Creer hath writ: | I can see that we're going to end up having to write smart software | which can figure out the right answer from anything which looks like abc. | | Or, alternatively, we can all work to the same standard and save ourselves a | lot of trouble. Fat chance. Even if we try that, experience so far has shown that there are serious incompatibilities possible between two programs that follow the standard. This is inevitable in any standard that's written in English, which is hopelessly ambiguous. Lawyers have been trying for centuries to develop a clear, unambiguous English subset, and their general failure is shown by the huge number of cases in which the courts have to decide what a law means. True. An additional problem is one which you yourself pointed out recently: users often write abc which is intended to be read only by human readers. In other words they are treating abc as a natural language. In this context any variation on abc syntax is OK as long as it's obvious what is meant. I've always been in two minds as to what programmers should do about this. Coping with all the possible variations of syntax whose meaning is obvious is an interesting programming challenge. On the other hand, to allow too many variations is to contribute to the deterioration of the language. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Three-handed job.
Richard Robinson wrote: On Tue, 10 Jul 2001, John Chambers wrote: Modern GUIs are very well designed, for people with three hands. The real problem has been how slow customers have been to make necessary hardware upgrades to meet the requirements of the software. Quite ;-) You might be interested in the following quote from Apple: We've done a cool $50 million of R D on the Apple Human Interface. We discovered, among other things, two pertinent facts: Test subjects consistently report that keyboarding is faster than mousing. The stopwatch consistently proves mousing is faster than keyboarding. This contradiction between user-experience and reality apparently forms the basis for many user/developers' belief that the keyboard is faster. People new to the mouse find the process of acquiring it every time they want to do anything other than type to be incredibly time-wasting. And therein lies the very advantage of the mouse: it is boring to find it because the two-second search does not require high-level cognitive engagement. It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function. Not only is this decision not boring, the user actually experiences amnesia! Real amnesia! The time-slice spent making the decision simply ceases to exist. While the keyboard users in this case feel as though they have gained two seconds over the mouse users, the opposite is really the case. Because while the keyboard users have been engaged in a process so fascinating that they have experienced amnesia, the mouse users have been so disengaged that they have been able to continue thinking about the task they are trying to accomplish. They have not had to set their task aside to think about or remember abstract symbols. Hence, users achieve a significant productivity increase with the mouse in spite of their subjective experience. -- (Not wanting to start a GUI vs CLI war or anything - just thought you might find it interesting.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Folk band
bert van vreckem wrote: I don't seem to be able to open your midi's, though (I'm using WinAmp on an NT 4.0 box.) The pdf's are fine, so it's not a corrupted zip file. There is something odd about these midi files on a Mac too (I downloaded the .hqx version). They all appear with the default icon, but labelled in different colours. If you drag one onto QT Player it opens and plays fine, but if you try to open it using the Open command either in QTPlayer or SimpleText it appears as a folder in the dialog. If you try to open this folder you get the same file list as previously, but with all the files greyed out. Examination of a file with ResEdit shows the file type to be Midi (correct) but the creator is completely blank - not even whitespace chars there. I didn't think that was possible, and I suspect it's actually a string of ascii null characters. ResEdit also shows that the file has a bunch of 'pref' resources, which if present in the zipped version might account for the difficulty of playing them on a Windows machine. In theory, the resource fork of a mac file should get separated when you zip it, and unpack into a folder named rsrc.frk on a Windows machine, but sometimes it just gets concatenated with the data, and therefore corrupts it. (Nice arrangements though, what I've listened to so far.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Folk band
Frank Nordberg wrote: But in any case it's not as if the compressed archives saves any downloading time. The self-extracting hqx archive is actually considerably *larger* than the individual files, while the zip archive only saves 8%. I just thought it'd be a good idea for visitors to just have to click on a single link. Both midi and pdf are quite dense formats, so you can't compress them much more. Making a .zip or .sit file mostly has the advantage of putting them together in one file. If you make that a self-extracting archive it gets a bit bigger, because you have added the code to decompress it. If you make that into .hqx it gets much bigger still, because that's an ascii text representation and only uses seven of the eight bits in each byte. hqx is not really needed any longer, as things get downloaded in binary mode now. I can answer two of the questions that puzzled Phil, though. The midi files are colour coded according to nationality. I usually remove such labels before uploading, since they'll only appear on Macs in any case, but in this case I forgot. As for the creator code, I routinely remove those from the midi files. It's mostly just a habit, but also because I think Macintosh users should be allowed to choose the application themselves. Again this shouldn't make any difference whatsoever to other computers. OK. If you want to mark a file as not belonging to any particular program, you should set the creator to '', as that value is reserved by Apple for that purpose. It sounds as if your zipped midi files were in MacBinary format. You should be able to turn that off in your zip program (if you use Zipit, it puts the letters 'mb' in the right-hand column of the contents table. Click on that to turn it off.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Folk band
I spent some time listening to the midi files last night, and I have to say that the arrangements are absolutely lovely. I can find very little to criticise. For my personal taste, they sound a bit too (er) musically educated (I like my folk music with a bit more shit on its boots), but it certainly makes for a different and interesting take on the music. The reels (particularly the Irish reels) should go a bit faster, and the title of the Morpeth Rant is mis-spelled. I have only one question really. How on earth do you find the time? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accents and other signs
Programs which don't know what an inverted fermata is would simply write the text instead. As I understand it, that is how the !symbol! syntax is supposed to work, but without the necessity of introducing the exclamation mark. I don't really see this as a good solution. We could introduce another special character in so that *invertedfermata generates the symbol instead of text, but this is one extra character compared to ! !. If your objection is specifically to exclamation marks, we could use @ @, but this seems a bit ugly to me. I don't see the necessity for any extra characters here. I basically don't want to see abc with unnecessary text descriptions of symbols embedded in it, although for those that insist on that there is already a mechanism for programs which implement macros. I would far rather that we stuck to the original abc scheme of using the letters H..Z with the U: field as a minimal extension to allow as many symbols (globally) as necessary. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accents and other signs
John Walsh wrote: Phil Taylor writes: BarFly also supports macros, which are quite different in that they allow the user to define anything that can be expressed in abc text. It is not the case (as suggested in the draft standard) that U: is used for staff notation and macros for playing. The critical difference is that symbols defined using U: invoke a piece of code to draw or play something and can only be used if the developer has written that code into the program, while macros simply substitute one bit of abc text for another before the tune is parsed, and the user can use this for purposes which the developer may not have anticipated. Aha! So when you speak of redefinable symbols, you mean H--Z rather than the symbols they (may) stand for? So that the letters can be used for things other than single symbols, e.g. U: I = start crescendo, i = end crescendo in order to start a crescendo hairpin which may extend across several notes, and which is ended when i is typed. Exactly. Or, if one wished to write a cadenza or other passage in small notes, U: K = small notesize, k = normal notesize and then type K ABcdef k for the passage. (Always assuming, of course, that the code has been written for these. By the way, doesn't the (proposed) standard permit both upper and lower case letters, except for a couple, like z, which are already assigned? That's useful for start/end markers, as above, as well as giving twice as many characters---the 19 extra characters may sound like a lot, but in fact it's all to easy to run out, once you start using them.) As I have it set up currently, you can only use the capital letters, as these are explicitly mentioned in the abc 1.6 definition, but I see no reason why the lower case letters can't be used too. Of these, uvwxyz are currently in use, but the bow markings u and v should be redefinable too. The distinction between macros and symbols is valid, but can lead to misunderstandings since it is package dependent---it depends on exactly what code has been written and is accessible. With packages like MusixTeX and Lilypond, the code has already been written, and is directly accessible, so there is a *lot* of flexibility in the U: field. To add to the confusion, commands in TeX are called macros, so if you use the letters H--Z in abc2mtex, they actually represent macros in TeX. (Repeat: macros in *TeX*, not in abc.) OK! Presumably then a future version of abc2mtex which supported redefinable symbols could simply do so in most cases by just substituting single letters for one another? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Three-handed job.
Henrik Norbeck writes: | Phil Taylor wrote: | [snip most of long quote from Apple] | Hence, users achieve a significant productivity increase with the mouse in | spite of their subjective experience. | | One advantage (over mouse commands) of a using more | keyboard commands is that you have a lower risk of getting | mouse-arm. I dunno about mouse-arm, but repetitive strain injury is a real problem which primarily affects heavy keyboard users (and musicians, of course). But there was one thing that I noticed missing, which was the whole point of my original cute quote. The Apple writer did admit that there was still a roughly 2-second delay in switching between keyboard and mouse. If the users of this sort of UI would just make the necessary hardware upgrades to take advantage of the design, this delay could be eliminated entirely, and users could make full use of its capabilities with no clumsy switching delays. But for some reason, users insist on sticking with their legacy 2-handed hardware. Sometimes users can be so bullheaded ... Well, we're still working on the DNA engineering of course. And Microsoft's bioengineering division are busy writing the necessary operating system for it. Your middle arm control system has performed an illegal operation and has been shut down could become a great excuse for all sorts of things, couldn't it? Scuse the anti Gates remarks. My PC has just died horribly, and I'm trying to figure out how to reformat the HD and reinstall Windows. Anybody know the Installing Windows shanty? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] BarFly is moving
BarFly's home page is moving to: http://www.barfly.dial.pipex.com The old page will be around for a month or so, but will eventually disappear, so please update your bookmarks and links. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accents and other signs
On Mon 23 Jul 2001 at 09:09AM -0700, John Carson wrote: Dear ABCexperts: I have several questions concerned about the improvement of abcm2ps or abc2ps. Is there anyway we can type words under the staff?(i mean not the lyric). It will prove handy to add this function, as simple as the words above the staff, right? I have recently added an option that lets yaps place acompaniment chords below the stave instead of above it. I invented some abc2ps-like syntax for this, since I couldn't find an abc2ps switch. Not really an answer to the original questioner, since he's not a Mac user, but BarFly will let you put guitar chords above or below the staff (its a local option, and involves no change to the abc). You can also use the annotation format; _text will write text below the staff. Doing it this way avoids confusing the transpose routine, which won't treat the text as a chord. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accents and other signs
JohnCarson: But using syntax like _text really doesn't work with either abc2ps or abcm2ps. So do you have other way out? I think jaabc2ps supports it. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accents and other signs
JohnCarson: Have you found that jaabc2ps has many a bug? First it put the dynamic signs above the staff, I can do nothing about it. So I usually use abcm2ps instead. I haven't actually used it myself (there isn't a Mac version). According to the web site it does support the annotation syntax, so ^text would write text above the note, and _text would place it below. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Three-handed job.
Bryan Creer writes: | Come on, folks! You're expecting too much. Most people have more than the | average number of arms as it is. Then, of course, there's the statistician's observation that the average adult has one breast and one testicle. As a reproductive biologist I have to take issue with that. Even if you insert the word approximately before each one, then it's still not true, since men have breasts too. My father had four, which must have skewed the average a bit. And when it comes to testicles, that's definitely cue for a song: X:1 T:Hitler C:Traditional (WW2) R:march M:C K:C GE z3 EFG | e2 e2 c4 | w:Hit-ler, he on-ly had one ball GE z3 EFE | G2 G2 F4 | w:Goe-ring, had two but ve-ry small FD z3 GAG | cG z3 GFE | w:Him-ler, him some-what sim-ler, While Doc-tor DA zC B,G zG| C8|] w:Goeb-bels had no balls at all! I believe that Hitler was actually monorchid, although how the author of the song could have known that is one of life's mysteries. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Three-handed job.
Let's see; since Hitler has been mentioned, does that mean that this topic will now die a sudden death? I don't think so; nobody has yet accused anyone of being a Nazi, only of having an abnormal complement of reproductive organs. OTOH, such musical parodies can be a lot of fun. And it's a good way to use a copyrighted tune in public and get away with it. Colonel Bogey was first published in 1914, so it must be close to out of copyright by now. It was written by Lieutenant F.J. Rickets, and published under the pseudonym Kenneth Alford. Apparently he used to play golf with an eccentric retired colonel who was in the habit of whistling two notes a descending minor third apart instead of shouting Fore. The interval stuck in Rickett's head and he wrote a tune around it. The tune has a second part which is quite unsingable. The words have been attributed to Churchill's secretary. There are two more verses, but nobody sings them any more because they're anti-German rather than anti-Nazi, and we quite like the Germans these days. (Oh, no! It's the dreaded Copyright Topic again ...) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] on being ripped off
Frank Nordberg wrote: Jack Campin wrote: I have a transcription of Clarkson's American tunes of 1805 on my website. It contains this note, at the start where no reader could miss it: ... Now I discover via JC's tune finder a file of uniformly good-quality transcriptions called longlist.txt with all those tunes in it ... What the hell do you think you're doing, Andrew? What list was this posted to and where is the archive? This looks really bad, but I don't think Andrew is the main offender here. The file you refer to is an archive of tunes posted at the Fiddle-L list. So it's probably some unknown member of that list who's to blame. I rather doubt it, since each tune contains the line: Z: posted by Andrew Kuntz 2/01 implying that the euphoniously-named Mr Kuntz was the poster. Whoever the butcher was, he screwed up by including the wrong L: field for that voice, so every bar is now in error. Of course it's possible that he followed your instructions by posting the original versions as well, and the archivist omitted them since they were not for the fiddle. The Fiddle-L archive, from which this list comes is at: http://www.best.com/~otter/tunes/fidlarch.html and the keeper of the list can be mailed at: [EMAIL PROTECTED] Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] on being ripped off
John Chambers wrote: I did experiment some time back with having my Tune Finder add a line giving the URL that a tune came from. I've commented this out, because I found that it was just too difficult to get the line terminators right for Mac and PC users. A lot of software on those systems chokes if you don't use their (non-standard) line terminators, and there's no way to find out what they want. Not having access to all their software, I can't do much experimenting to test whether my code is producing something that is usable. As far as BarFly (and probably most other software) is concerned, the correct technique would be to use the same line terminator as the rest of the file. I test the first line and use that information to correct the rest of the file, as it would be very slow to treat each line individually. Maybe I should just convert everything to ANSI standard terminators? I know - I'll have it use RS (Record Separator) characters, which is what the standard says is the preferred terminator. ;-) Technically, one abc tune = one record, so I suppose we should have an RS at the end of each tune (but please don't:-) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Johnnie Scobie
Frank Nordberg wrote: Hartmut Wiechern wrote: Hi, does anybody by chance know the tune Johnnie Scobie and has it in abc? I couldn't find it in the tune finder. Thanks in advance. H. Wiechern Just a quick transciption. Hope it's good enough. BTW, does anybody know who wrote this tune and whether it is copyright protected? Frank Nordberg X:1 T:Johnnie Scobie Z:Transcibed by Frank Nordberg - http://www.musicaviva.com M:C L:1/8 Q:1/4=120 K:Hp %A mixolydian AB|c3e dcBA|c2A2 A2ce|a4 agfe|f4 e2fg| a4 a2c2|d2f2 e3e|f2e2 a2c2|B4 A2:| I know this tune under another title, which is in the tune finder: X:149 T:We're No Awa Tae Bide Awa S:Catherine Smith, Dundee Z:Nigel Gatherer M:4/4 L:1/8 K:D DE|F3 A GFED|F2 D2 D2 FA|d3 e dcBA|B4 A3 A| d3 e d2 F2|G2 B2 A3 A|B2 A2 d2 F2|E4 D2|] No idea about copyright, but I've always thought of it as trad. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC in an internet cafe
John Chambers wrote: It's not obvious to me how the above I lines would apply to this. The first would just mean that the tune wouldn't be in the index at all. The second would mean that all MIDI requests would get the first tune, in which case you might as well not bother (unless that's the tune that the user asked for). What should happen in the second case is that when that tune appears in a list of hits, the buttons which retrieve GIF, ps or midi would be disabled, and the abc button would retrieve the whole file. (I've no idea how easy that would be to implement - presumably the index would need an extra field to hold the information.) Presumably this would not affect normal search robots at all, since they won't index .abc files anyway? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] BarFly macros
Henrik Norbeck wrote: What does the standards committee say about BarFly m: macros? Besides, there are the U: and u: redefinitions. I'm getting to these parts in my implementation, and I will need to know what we accept as standard, since U:, u: and m: seem to be in conflict with each other at the moment. Can we reach an agreement about a great unified macro/redefine standard. Is the standards committee working? Who is on it? Is this a big can of worms? You bet! There hasn't really been any discussion of macros yet, and the proposed standard doesn't really address them except to give them the letter u: instead of m:. That's not really a problem. The big problem is with the U: field and the use of !text! in the tune. I have argued against this ever since it was first proposed (and I bet nobody here wants to hear the arguments again). Nonetheless it got put into the draft standard and a couple of people have implemented it. Since nobody wants to change the way that their program works we have a deadlock. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abcmac - BarFly-style abc macro preprocessor in Perl
Anselm Lingnau wrote: Phil Taylor wrote: BarFly's macro processor does take lengths. You have to write a separate macro for each length of note. The reason for this is that an ornament which sounds right on a half note is often wrong on an eighth. I'm confused now. Suppose I had definitions for `Mn' and `Mn2'. What would happen (a) for `Mc' (b) for `Mc2' (c) for `Mc4' in the body of a tune? The interesting point is whether the `n' includes a length or not. (a) and (b) will expand, (c) will not, since there is no macro definition for that length. 'n' does not itself include the length, but the length (if any) is part of the target string. What the current Barfly version does when it encounters a macro on a note with an accidental is to place the accidental on the first ocurrence of the principal note in the expansion. [...] BarFly doesn't do this; rather it expands the macros in reverse order to the order in which the definitions are listed. Actually, thinking about this some more, it would be possible to sort the macro definitions into order before expanding them, provided that you used a sort algorithm which is guaranteed not to change the order of elements which are the same size. Since the list of macros to be expanded is never going to be very big you could just use a simple bubble sort. I've put a version of abcmac which is fixed in these two respects on my web page at `http://anselm.our-isp.org/abcmac/abcmac'. Maybe we can get abc2midi to process the Goldberg Variations? We could try ... If there's the possibility of other programs handling the macros, I'll fix the V: fields to be inline once I release the next version of BarFly (the current version won't work with that syntax). The postscript programs will still only be able to display it with the ornaments written out in full, which is highly illegible. I wasn't able to test the script, unfortunately. I had installed a new hard drive in my machine and simply copied all my stuff over to it. MacPerl has got itself into a fankle and can't find its libraries any more (perl5lib not found in @IN), despite the fact that perl5lib is certainly there, and the correct pathname is in the preferences. I downloaded and installed a new version which comes as a single standalone application, with all the libraries compiled in, and that didn't work either, objecting to 'strict', right at the beginning of the script. Us Mac users don't have a lot of fun with perl. Every time I try to use it I end up concluding that it would be quicker to write a program in C or Pascal to do the job. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Susato's Danseryes
Simon Wascher wrote: Frank Nordberg wrote: Just like to tell everybody at abcusers that I've just posted a complete ABC edition of Tielman Susato's Danserye Hey great, thats really nice. It is indeed - thank you Frank. My transcriptions raises a few interesting questions regarding ABC-versions of early music. Should we add barlines? How do we disern between original and editorial accidentals? etc. etc. etc. Anybody's views on those question are much apreciated. I usually use #A or bA to show editorial accidentals. Yes. Perhaps ^# would be better. About the barlines, I would primarily say no, lets give the source as pure as possible, but maybe for the sake of usability just add a note: no barlines in the source. It depends on what you are trying to do here. Barlines do make the music much easier to read, and easier to check for correctness. Also it's much easier for a user to take them out than it is to put them in again, if that's what is required. I would find it much better to write the music voice after voice. It is not really possible to read the four voices in paralell in the abc text anyway and it is complicate to extract parts for playing. I still find that programmers should enable voice after voice input. The way it is here simply mixes up text matters and layout matters (not your fault). I disagree. Writing the abc line by line preserves the original music layout in the abc, and I find it much more readable. I notice, however that in some of the pieces you have two lines in each voice. This seems to me to be the worst possible compromise. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] To V: or not to V: (was: Susato's Danseryes)
Frank Nordberg wrote: But anyways, it seems to me that abc should allow for both alternatives. According to Laura, abcselect is able to convert between the two alternatives, and the latest version of BarFly is able to do a one-way conversion (how about running that both ways, Phil?) so it shouldn't really be too much of a problem(?) It works both ways already. Just enter sufficiently large numbers under Bars per line and notes per line and each voice will come out on a separate line. You will have to insert some line breaks and continuation characters by hand if you want to email it, but it's an easy way to extract voices. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Steganography
As a carrier medium for concealed messages abc is pretty poor. The tunes are too small, and contain too little redundant information. This means that you have to add some (apparently) redundant characters to contain the message, and it's a dead giveaway. Steganography is usually done by substituting the low-order bits for each pixel of a picture, or each sample in a sound file. The message is itself encrypted, and if you use a modern encryption algorithm, the resulting cyphertext is indistinguishable from a string of random numbers. The only effect on the carrier picture or sound is to make it a little more noisy. Unless the enemy has a copy of the original picture/sound to compare, there is no way he can prove that the intercepted message contains anything unusual. abc is simply too good at doing what it was designed for to be used for anything else. Phil Taylor (Who has been writing a shareware encryption program, but doesn't feel like releasing it right now.) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] two hand notation examples
It is certainly possible for abc to represent keyboard music. I have transcribed the entire Goldberg Variations using BarFly. It plays perfectly, but the problem is that some of the pieces require as many as five voices to represent it adequately, and merging those five voices correctly onto two staves when you want to print the staff notation is a very difficult task. Steve Allen has a thoughtful discussion of this problem at: http://www.ucolick.org/~sla/abcmusic/piano/piano.html Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc libraries
James Allwright wrote: Some time ago I toyed with the idea of creating an intermediate level format (ILF) which would make it easier for developers to create new tools. We would then have separate programs for abc - ILF ILF - PostScript / Display on Screen ILF - MIDI The idea is that the ILF is read and written by computer and designed to be very simple to parse. All this seemed like quite a lot of work, so I never got very far. Yes, I thought about that too. It's an appealing idea, but the problem is that the ILF has to be very comprehensive because it has to represent absolutely anything which is found in music, otherwise future extensions to abc will invalidate it. You end up with something which is just as hard to parse as abc. In the end I wrote two separate parsers for BarFly, the only common code being the basic stuff which retrieves field contents from the header. What did you have in mind for the output of your library Taral? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Multivoice doc
James Allwright wrote: It is still possible for someone who cares about an abc standard to help the process along; get hold of every abc program you can, go through them carefully and then document the compatibilities and incompatibilities carefully on the web I started to do something similar to this with respect to the V: field. It proved to be very hard work. It is still incomplete, and almost certainly contains errors, but you can read the results at: http://www.barfly.dial.pipex.com/multivoice.txt Corrections and additions are very welcome. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] requesting goodies from developers
Richard Robinson wrote: By section header, do you mean the global header lines, external to any tune ? I've been wondering about this recently, whether many people use them. I like them, I find they can save a lot of fiddly typing, but I'm not sure what programs handle them. (Surely it's not _that_ hard for a GUI app. ? Reading applying them is fairly simple, just go through the file suck the tunes into memory, with default headers applied where necessary. Writing is an extra fiddle, if you want to remember the globals, but you don't actually change the meaning of anything by not doing that. ) From the abc 1.6 definition: Information fields == The information fields are used to notate things such as composer, meter, etc. in fact anything that isn't music. Most of the information fields are for use within a tune header but in addition some may be used in the tune body, or elsewhere in the tune file. Those which are allowed elsewhere can be used to set up a default for the whole or part of a file. For example, in exactly the same way that tunebooks are organised, a file might start with M:6/8 and R:Jigs, followed by some jigs, followed by M:4/4 and R:Reels, followed by some reels. Tunes within each section then inherit the M: and R: fields automatically, although they can be overridden inside a tune header. So within a file you can have global header lines (at the beginning of the file before any tunes) and section header lines (in between tunes at the start of each section). BarFly supports the global stuff, which can include information fields, macro and symbol definitions, but not section headers between tunes. In order to support these the parser would have to parse the whole file from the beginning in order to display the 900th tune. Remember that the file may have been edited since the last operation without the edits being saved, so it's not sufficient to just parse the whole thing when it's opened. As far as possible I prefer abc tunes to be self-contained. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multivoice doc
James Allwright wrote: This explanation of octave= is not quite right. I suggest the re-wording Yaps and abc2midi support a simpler version of this, where the directive octave=-2 causes every note to be treated as having a pitch two octaves below the written pitch. The point being that it is not just drawing of the notes that is affected, but playing them too. Done! Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE : The day the music died! voting for abc standard
The trouble with propositions of this kind is that they tend to come from users who have experience with a very limited number of programs and usually on only one platform. What is being proposed here is that we all use abcm2ps syntax (plus a few enhancements) and abandon all other approaches. This is very nice for people who use abcm2ps (we all like what we know), but utterly unacceptable to those who are familiar with a different program. If you really want to put forward a serious proposal for features to be added to a new standard you must first study _all_ of the existing programs, and come up with something which minimises the changes which have to be made to all of the existing code and invalidates as few as possible of the published abcs. It's not easy work, but you could start by reading the multivoice document whose url I posted here yesterday: http://www.barfly.dial.pipex.com/multivoice.txt This actually covers more than just multivoice, it covers the major features of all the programs which currently support the V: field, and so deals with clefs, transposition, the use of the continuation character and its interaction with he w: field etc. Resolving the syntax differences between different programs is probably going to require that we allow multiple formats. For example, I have no intention of abandoning the intuitive way in which BarFly specifies the layout of staves, clefs and merging of voices in favour of the cryptic %%staves directive. Likewise Jean-François will be reluctant to invalidate all of his music by ruling out its use. The real solution is to have both programs recognise either format, and leave it up to the users to choose whichever they prefer. That won't happen unless both formats are legitimated by inclusion in a new standard. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics (was)
Gianni Cunich wrote: I won't let your offensive emails drive me away... Do you actually wish to ask Toby making this a censored list? Not a bad idea actually. Why don't we take a vote on expelling Gianni from the list? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] what clefs are available?
Kathy Mulvey wrote: Am I correct in my reading of the documentation of ABC (I use the http://www.gre.ac.uk/~c.walshaw/abc/ site) that a clef indication is a commonly available extension to the K keyword, but is not part of the real 1.6 standard? Yes. I was just wondering if there was any way to indicate that the treble clef was transposed an octave, using the 8 indication above or below the G-clef symbol. It's not mentioned at all in the extensions section of Steve Mansfield's ABC tutorial, so I was wondering if it was just not available. Depends which program you are using. In BarFly and (I think) Muse you can add transpose = -12 or T=-12 (or +12) to the K: field to do this. BarFly supports the treble, alto, tenor and bass clefs plus the eight clefs used in Gregorian chant, Muse does something similar. The abc2ps familiy of programs and yaps support treble, alto and bass clefs, but I don't think any of them will do the ottavo mark. (I also see I've stumbled on to the list at a time when there's much discussion about moving on to a new standard. I wish you all the best of luck with the process.) Thanks! Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
Laura Conrad wrote: Anselm == Anselm Lingnau [EMAIL PROTECTED] writes: Anselm I'm still waiting for you (or anybody) to explain why an Anselm ABC tune should contain one prescribed explicit metronome Anselm speed for display and another, different, prescribed Anselm explicit metronome speed for playback, Because you might want to tell a human player what speed you think the piece sounds good at, but you want to tell the computer what speed you want to proofread your transcription at? But why would you want to record your proofreading speed in the abc for posterity? Surely you just want to override the given tempo using a setting local to your program? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] request for info
One or two abc files I have downloaded recently have a lower case m: field, as in m: Tn = (3n/o/n/ Can you tell me what this means please? It's a BarFly macro. What it does is to define how the T symbol gets played. In this case, what it means is that the symbol Tc would cause the note to be played as a triplet, (3c/d/c/. There's a full description of the macro system on the BarFly site: http://www.barfly.dial.pipex.com/bfextensions.html Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: DA:
Simon Wascher wrote: James Allwright wrote: You are right, there is no satisfying solution for it and this is a shame. On the other hand it could simply and instantainously be done by implementing a DA: = dance field into the header. Since there is no such field, it cannot make any existing abc's outdated, and since it is not active, I belive it could be used from now on. Sorry, this won't work. You can only have 1 character before the colon, otherwise you are going to have lots of parsers complaining. It is a pity if it is that way. And my copy of barfly did not complain on a first try. Unlike most programs, BarFly does not parse the header line by line. Instead it searches for the fields which it needs (K:, M:, L: Q:) and ignores anything else in between. So if we did decide at some point to introduce two-letter fields it would be relatively easy to do, as long as they were confined to the header. So its definitely something which the actuall programs rely on ? In my simple mind the rule could also have been: accept (between linebreak linebreak X: and the first K:) as a header what is between a line break and the next colon. I see it: [from the standard:] ...that any line beginning with a letter in the range A-Z and immediately followed by a : is interpreted as a field... ...archive fields do not affect the output at all... - (practically as long as fields with two letters are restricted to the header area and use just those letters used in archive fields they could not do any harm. The question then would be if any indexing application would support it. I am willing to change the standard if it does no harm to actuall programs and therefore existing abc files) I think you will meet with a lot of opposition from people whose programs parse the header line by line and produce an error message when meeting an illegal line. On the other hand, there is a clear demand for new field types, and very few single letters left, so perhaps we should consider it. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] a partial solution to the tempo definition problem by macros
Jack Campin wrote: BarFly's macro mechanism provides part of what I need. I can define two separate macro files, each defining a q macro, one containing the line: m: q con moto = [Q:1/4=120] snip The problems with that are: - it's a hack The macro system lends itself to hacks. I've seen some really wierd ones (several from yourself, of course:-) - there's no syntax identifying the macros as tempo constructs Yes. You have to expand the macro to see what it does. - I can't put the required macros at the top of the file (I don't understand this, it works for other macros as in Phil's Goldberg Variations example) - they have to be in a separate file It works OK provided that you save, close the window and re-open it after editing. BarFly only reads the file header when opening the file. - there's nothing like a #include construct to link a file to the macros it needs - the linkage has to be done through application preferences I've considered doing something like that, but haven't really found it necessary yet. Since BarFly allows multiple external macro files (you choose which one is in effect from a menu) you would only really need it if you wanted to link them together in chains. That's getting pretty fancy. - I can only use this in tune bodies since macros don't work in headers (not much of a problem for me, maybe would be for other people) Not really a problem for tunes you write yourself, since Q: fields can be placed after the K: just as well as before. - it would be much nicer if BarFly never printed numerical tempi in the first place; that way I could get away with just one macro file It's on the list of stuff to do:-) - I'd hate to ask anybody else to do it. Yeah. But I'd *much* rather insist on people going through those hoops, and additionally restrict them to using software that can handle Barfly- style macros, than hardwire my interpretive guesses till the end of time. So, in the absence of any discernible progress, I think I'll just start doing it, and put a pair of suitable macro files on my website that you will have to use to make sense of anything I upload from now on. Note, this mechanism subsumes the suggestions made for constructs that would put the tempo indication in a distinctive typeface, because the quoted-string mechanisms of programs that allow multiple typefaces can be invoked by whatever I put on the RHS of a macro definition. Unfortunately the macro system honours comments in the macro definition, otherwise you could define your macros as: m: %%q con moto = [Q:1/4=120] and use %%q in the tune, which would be ignored by other programs. Maybe I should make a special case for %% definitions. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Sharps 'n flats
What the accidentals =, ^, _ mean? Are they absolute (e g _e means e flat) or are they in relation to the key (e g =e means e flat in Bb major)? Accidentals in abc work exactly in the same way as in modern staff notation, that is _e means e flat, even if the e was sharp or flat already as the result of the key signature or an accidental earlier in the bar. Accidentals apply only to the note they precede and any other instances of that note later in the same bar, and not to the same note in a different octave. (Note though that the early music people prefer accidentals to apply only to the following note, leaving any later instance of the note unchanged, and some programs may permit this as an option.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Multiple Endings
When John first suggested multiple alternate endings and repeats of 2 times I thought it was a good idea and started to implement it in BarFly. Getting it to display was easy, but getting it to play correctly turned out to be a nightmare, to the extent that after working on it for several days I gave up and pulled all the new code out. There were all sorts of problems. Of course that does not mean that it can't be done, just that it ain't as easy as it looks at first sight. A few things to consider when discussing repeat syntax: * It has to coexist happily with other methods of specifying repeats, such as the P: field in the header, and not rule out the use of conventional musical indirection (e.g. using the Segno). (A lot of people would like to use that.) * If we can have multiple alternate endings, why not multiple alternate segments within a repeat, not necessarily at the end? This is common in pipe music, and we have seen requests for it on this list. * It is very common to see repeats written as: abc |[1 abc :|[2 cba :| which is wrong (the last repeat should be written as || or |]), and is explicitly forbidden by the 1.6 standard. At the moment, because it's so common BarFly lets it go without comment, but what should be done here? Should it be treated as an instruction to repeat the section four times with endings 1,2,1,2, or should it generate an error? * We need a clear set of rules as to where repeats should start from. At present, when it encounters a repeat BarFly searches backwards for one of the following symbols: |:, ||, |], [|, a P: field, or the start of the tune. This seems to give the least problems, but it does mean that you can't use a double bar or thin/thick bar within a repeat. * We also need a (preferably illustrated) description of how the various repeats are to be displayed in conventional notation. If we have a 4x repeat - |:::...:::|, should that be displayed with four dots arranged vertically next to the bar line? I have seen that symbol used in music where the context suggests that a normal single repeat is what is intended (e.g. in the Original Sacred Harp). Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multiple Endings
John Chambers wrote: Phil taylor writes: | * It is very common to see repeats written as: | | abc |[1 abc :|[2 cba :| | | which is wrong (the last repeat should be written as || or |]), and is | explicitly forbidden by the 1.6 standard. At the moment, because it's | so common BarFly lets it go without comment, but what should be done | here? Should it be treated as an instruction to repeat the section | four times with endings 1,2,1,2, or should it generate an error? This is done because with most current ABC tools, it's the *only* way to indicate four times through. It's definitely crappy notation, but it's the best you can do if the software chokes on: abc |[1,3 abc :|[2,4 cba :| No, people use it sloppily where there is only one repeat. BTW, where does the 1.6 standard explicitly forbid this final :|? I don't seem to see anything at all on the topic, only the statement that :| marks the end of a repeated section. This would imply that the above notation is legal, since that bar line *is* the end of a repeated section. You are quite right. I could have sworn that the standard forbade the use of :| to terminate the second repeat. Maybe it was in an earlier version of the standard? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: Initial repeats
Jack Campin wrote: Version 3 *should* produce an error warning, as there is an empty bar between lines 3 and 4; this is no different from writing the first two lines as Aee efg|edB dBG|Aee efg|edB A3 | |aaa gag|fgf eAA|Aee efg|edB A3:| which BarFly correctly flags as an attempt to write a bar shorter than the time signature says. (In fact BarFly doesn't see the problem in 3, though according to the 1.6 standard, it should: repeat signs are bars, so the two cases ought to be treated the same way). It used to flag that as an error, but I changed it not to do so, as it occurs in so many tunes. In any case, repeat signs don't always coincide with metrical bars. The commonest case where a repeat sign is not a metrical bar is in a two part tune where the last bar of the first part is shortened to match the anacrusis at the start of the second part. Also, if you want to reorganize the line breaks, you have to edit the adjacent :| and |: signs into a single :: (after all, :||: is illegal). This is a silly timewaster. If you're changing line breaks you shouldn't be forced to change anything *but* line breaks. :||: is not strictly illegal; just a waste of space. The optimal behaviour: write the ABC as in version 2, with a display option in the program to suppress those dangling marginal dots and another option to interpret the :: sign graphically as a closing repeat on one line and an opening repeat on the next. That would decouple the choice of repeat sign from the physical location of its representation in staff notation and allow for all the staff-notation conventions that people have expressed a preference for in this thread. It's on the list of things that BarFly will do when I get around to it:-) (I thought I'd compare my version of that tune with how other people have represented it. But it turned out that all three copies known to the Tune Finder are mine, which I find astonishing considering how familiar it is). : James is adamant that abc2midi won't play a repeat unless there's : a balanced begin/end. I didn't realize this. I haven't used a current version, since I have nothing that will run it, and I soon gave up on the one included with the old abc4mac (0.95?) because it produced too many spurious warnings. Should I put a warning on my site for people not to use abc2midi on anything there? Almost every tune I've transcribed uses the Kerr's/ NPTB convention, and it *must* be easier for a programmer to modify their code to accept them than for me to change all of them. (And no way in hell am I going to change anything until the software I use gives me the option never to see redundant initial repeats in staff notation made from them). I think most people who use abc2midi will be well aware of it. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Twelve Days of Christmas
A small correction (I have problems counting up past four at this time of year, never mind twelve). X:1 T:The Twelve Days of Christmas M:none %a cop out P:AB ACDB AC2DB AC3DB AEDB ACEDB AC2EDB AC3EDB AC4EDB AC5EDB AC6EDB AC7EDB K:D [P:A] AA | A2 dd d2 cd | efge f3 || w:On the nth day of Christmas* my true love sent to me [P:B] g |a2 bg fd e2 | d3 || w:a partridge** in a pear tree. [P:C] a2 | ef g2 [P:D]||f || w:Two tur-tle doves and w:Three French* hens w:Four ca-lling birds %etc [P:E] a2 b^g a4 || agfe d2 g2 | B2 d2 edcB A2 | w:Five gold* rings, Four* calling birds, Three french hens, Two turtle doves Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Twelve Days of Christmas
John Walsh wrote: A Christmas challenge: find the shortest abc for the music to the Twelve Days of Christmas. (all verses, all extensions suggested in this thread are welcome, of course.) Ooh, I can't resist. Here's a starter using no extensions other than inline fields: X:1 T:The Twelve Days of Christmas M:none %a cop out P:AB ACDB AC2DB AC3DB AEDB ACEDB AC2EDB AC3EDB AC4EDB AC4EDB AC5EDB AC6EDB K:D [P:A] AA | A2 dd d2 cd | efge f3 || w:On the nth day of Christmas* my true love sent to me [P:B] g |a2 bg fd e2 | d3 || w:a partridge** in a pear tree. [P:C] a2 | ef g2 [P:D]||f || w:Two tur-tle doves and w:Three French* hens w:Four ca-lling birds %etc [P:E] a2 b^g a4 || agfe d2 g2 | B2 d2 edcB A2 | w:Five gold* rings, Four* calling birds, Three french hens, Two turtle doves Plays fine in BarFly. Now I've wasted all that time when I should have been shopping:-) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] A Christmas Challenge
David Barnert wrote: I love it. This was a great challenge. Thanks. snip Here it is: X:1 T:Twelve Days of Christmas M:none P:AEBFECGFECGGFECKECHKEBIHKECHIHKECHHIHKECHHHIHKEDIHHHIHKECJIHHHIHKE K:G P:A % First day DD|D2GGG2FG|ABcAB3c| P:B % 2nd, 7th days DD|DDGGG2FG|ABcAB4| P:C % days 3, 4, 5, 6, 8, 9, 10, 12 DD|D2GGG2FG|ABcAB4| P:D % 11th day (3DDD|DDGGG2FG|ABcAB2d2| P:E % Partridge in a pear tree d2ec BGA2|G6| P:F % 2 Turtle doves and a d2ABc2Bc| P:G % Calling birds, French hens d2ABc2| P:H % 6, 8, 9, 10 Xers Xing (or X a-Y-ing) d2AB cA| P:I % Seven and (e)-leven Xers Xing (or X a-Y-ing) dd AB cA| P:J % 12 Lords a-leaping, e-(leven) d2AB cA/d/| P:K % 5 Gold rings, ... and a d4e2^c2|d8|dcBAG2|c2E2G2|AGFED2Bc| Excellent. Better than mine, since I didn't bother dealing with the changing syllables in the days above six. However, here is the definitive shortest version (if you don't count the macro definitions:-) m: .A = AA | A2 dd d2 cd | efge f3 || m: .B = g |a2 bg fd e2 | d3 || m: C = a2 | ef g2 m: D = f || m: E = a2 b^g a4 || agfe d2 g2 | B2 d2 edcB A2 | m: 2C = CC m: 3C = CCC m: 4C = m: G = .A.B .ACD.B .A2CD.B .A3CD.B .AED.B .ACED.B .A2CED.B .A3CED.B .A4CED.B .A4CCED.B .A2C4CED.B .AC2C4CED.B (beware of the line wrap on that last line. I just discovered a bug which prevents the use of the continuation character \ in macro definitions, so it has to be written all on one line.) X:2 T:12 Days of Xmas M:none K:D G Thats it! The dot before the A and B part definitions is necessary because the tune contains A and B notes, so the target string needs to be something other than a single letter. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] attachements to the lists.
Toby Rider wrote: Please do not send attachments to the lists. It slams the mailserver. Slows down delivery of mail to all users and lists served by the machine. I don't want to have to set up a filter to bounce all mail with attachements. Thanks! Yes, it also means that everybody has to download the attachment whether it's useful to them or not. Luis, the usual way of distributing binary material like this is to put it on a website or ftp site and post the url to the list. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] small nag in ABC notation?
Guido Gonzato wrote: On Tue, 22 Jan 2002, Phil Taylor wrote: I would regard CC/ as an illegal construct since only makes sense when both sides have the same length. Maybe this is the problem ? I'm inclined to agree. It's not explicitly illegal in the abc standard, but it's a bit ambiguous as to what it actually means. BarFly translates CC/ as C3/C/4, but that is a different length from CC. You could also argue that it should mean C5/4C/4, which would keep the total length the same. I see the point. Should I conclude that if I want to obtain a dotted quarter followed by two semi-quavers, with L:1/4 I'll have to resort to an inline [L:1/8]? Why do you need the change of default note length? With L:1/4 you can write C3/C/4C/4 which is shorter than [L:1/8] C3C/C/ (and you don't have to change back to L:1/4 later). I have doubts though. In fact, the 1.6 standards states: To support this abc notation uses a to mean `the previous note is dotted, the next note halved.` following this rule, CC/ with L:1/4 would mean a dotted quarter followed by a semi-quaver... exactly what I need, even though it isn't a real broken rhythm. I find this notation much more handy than an inline [L:1/8]. If the general consensus is that one should avoid writing this, I'll follow the rule. I just want to make sure I write portable, standard ABC. The broken rhythm construct is a shortcut which saves a huge amount of typing in some dance tunes (e.g. Strathspeys), where it happens twice in every bar. The situation where you might want to use it between unequal notes is relatively rare, so it saves very little typing. Here I would always write it out in full in order to achieve portability. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and midi
Atte Andre Jensen wrote: I never used abc for midi playback before the other day. I grabbed abc2midi and ran my abc through it just to find that it doesn't handle tied notes correctly. If I have CDE^F- | F that is perfectly allowed in music notation, and abcm2ps also findes it no problem at all (which it isn't), but abc2midi gives me this in the midifile: CDE^F | F so in order to get what I want I need to write CDE^F- | ^F which is wrong (not very, but at least it looks funny). So my questions are now: 1) are there other packages available (linux) that will convert my abc into midifile in a correct way? 2) if not are there any workaround to the problem, maybe in the form of scripts that can be run before abc2midi? 3) would you, James Allwright, consider to correct the behaviour of abc2midi? I think you will find that several programs have this problem. BarFly certainly does. It's not easy to fix, because if there is another F in the second bar it should be natural: CDE^F-|FEDC FEDC | should play as: CDE^F-|^FEDC =FEDC | It needs some special-case code to handle it. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and midi
Atte Andre Jensen wrote: On Wed, 30 Jan 2002, Phil Taylor wrote: I think you will find that several programs have this problem. BarFly certainly does. But how do *you* work with midifiles then? I put in the necessary accidentals to make it play properly, even though they are redundant in the printed version. It's a fairly rare occurrence. I'd prefer to fix the program, but as I said, it's a fairly tricky bit of code, and there's always something more urgent to do. A similar problem exists where you have a tie or slur across a repeat marker as in the following example: X:39 T:Bonnie Kate N:The slurs in this tune are almost impossible to deal with N:correctly. Note the slur from the d in bar 7, which should N:be drawn to the A in the first repeat bar AND to the A in N:the second repeat bar, so we have a slur with one start and N:two ends. Note also the slur from the g in the first repeat N:bar of part B. This crosses the repeat and goes to the a2 N:at the beginning of that part. B:Pete Cooper: Mel Bay's Complete Irish Fiddle Player, p. 144 R:reel M:C| K:D P:A d(uB|A2)dA (3Bc(vd A)(F|DF)AF EGF(E|DF)AF GBed|cAB(c d2) d(uB| A2)dA (3Bc(vd A)(F|DF)AF EA,CE|DFAF GBe(d|1 cA)B(c d2):|2 cA)Bc def(g|] P:B a2)fd vAdfa|~g3e cde(f|g2)gf vgba(g|fg)fe def(g| a2)fd vAdf(a|gf)ge cdef|gfed vc(bag)|1 fgfe def(g:|2 fgf(e d2)|] Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Corrupted files
Philippe Sauvé wrote: Point 1 - In writing abc files, I copied reused several times the same SimpleTex dossier After a whyle, the dossier got corrupted and made BarFly crash systematicaly. It stopped when I copied the content to a new dossier. BarFly saves various bits of extra information in the file's resource fork: text formatting, viewing mode, shape and position of the window etc. Sometimes this information gets corrupted. If this happens, you can force the program to ignore the bad data by holding down the option (alt) key while you issue the open command. You will lose any text formatting, colours etc. and the file will open as plain text. Alternately, as you have discovered, you can rescue the contents by using another text editor to open the file and then copying the text to a new file. Point 2 - Is there, for IBM/DOS/Window users an équivalent to BarFly Henrik Norbeck's abcMus is a very good abc player. MUSE and Melody Assistant (which is multilingual, including French) are both music editors which can import and export abc. If you have been using standard abc 1.6 everything will work OK (BarFly plays and displays all of the 1200+ tunes on Henrik's site correctly, so I guess it should work the other way round too). If you have been using the program's more advanced features (redefinable symbols, macros, multivoice or Gregorian notation) you will have some problems. Mail me off list if you need any more help. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Music of Dalkeith
A bunch of new ABCs at this site, but I've ZIPped them up to keep search engines out (for reasons which should be obvious when you look at the first page): One small point, Jack. The warning about Quicktime 5 has been overtaken by the facts, as Apple have now fixed that bug. QT 5.0.5 (released last week) works properly. Versions 5.0 - 5.0.3 were bad, and I don't know about 5.0.4 as I never saw it. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: OT: hornpipes
Richard Robinson wrote: On Thu, 28 Feb 2002, John Chambers wrote: The word hornpipe does exist primarily as a dance term, I think it has also been used for an instrument name (just to confuse things) - unsurprisingly enough I have a vague memory of bumping into it somewhere (but I can't remember where) as a translation for chalumeau, which is also said to have been a forerunner of the clarinet Yep The hornpipe (the instrument that is) was a single reed instrument, blown by mouth, with a bell at the bottom made from cows horn - hence the name Phil Taylor To subscribe/unsubscribe, point your browser to: http://wwwtullochgormcom/listshtml
Re: [abcusers] Encoding linefeeds
Christian Cepel wrote: I'm a bit confused, reading through the documentation available online Our first task in development is of course to parse an abc file I'm trying to figure out, per the 16 standard, WHAT EXACTLY the _approved_ linefeed/newline character, and encoding are for abc This is a continuing problem for all of us Most users are unaware of the differences in newline character encoding and find it very confusing (It's all text isn't it?) In writing BarFly I decided that it was going to be impossibly complicated to preserve and handle original encodings within the program, so I test new files as they open and convert them to the Mac standard (CR) The program also saves them in this format so that they can be expected to work with other Mac text editors This seems to be the technique which causes least complaint from users, ie accept any format but export the data in the format which is local to the platform There is a way in which the program can be made to export text in any of the formats, but I don't advertise it as it's simply going to confuse the less sophisticated users If all abc programs adopted the same strategy the problem would simply disappear (but how likely is that?) Phil Taylor To subscribe/unsubscribe, point your browser to: http://wwwtullochgormcom/listshtml
Re: [abcusers] The X: field
Laurie wrote: Here is another rather nastier example that actually *does* have an X: line but can still cause severe problems if you try and parse it. This is because the ABC is embedded in this email where spurious T: lines and X: lines can occur. In fact you can even get spurious K: lines which make it look like the song has started and that can kill a parser DEAD! And exclamation marks on the ends of lines can leave you wondering whether the next line is a real delimiting blank X:1 T:Real title K:C ABc You had fun composing that, didn't you? Actually, it's not a situation that happens very often (except on this list) - only when you are writing about abc itself, and illustrating what you say by means of examples. I have to be careful when writing BarFly's documentation, which consists of abc files containing tutorial text with example tunes. Since BarFly absolutely insists on having an X: field at the beginning of a tune , all I have to do is to avoid what I've done in this sentance, i.e. putting the characters X: at the start of a line. Not that that would kill the parser, of course, just display an error message where the music should be. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Reducing Accidentals
Jack Campin wrote: Is there an application to reduce accidentals (i.e. change __a to =g)? I know that double sharps and double flats exists to be used but sometimes it's easier to read music without them. BarFly's search and replace can do that, if you really want to. Not very convenient, since you'd have to do a separate replace operation for every pitch. You could probably do it with an editor which supported selection expressions like MPW shell, and I'm sure the unix guys will have a way of doing it. However there is nothing in the ABC spec that says the result needs to represent the same pitch. The standard sensibly doesn't mandate equal temperament and ET should not be assumed. I've never tried doing custom intonations in BarFly, can it use different pitches for ^A and _B in the same piece? No, it doesn't cater for more than twelve pitches per octave. Of course you could probably cobble together something for a particular piece by co-opting one of the unused pitches and re-tuning it, but there's no general solution for that. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] OT: Battle of Aughrim
Joe McCool wrote:
My kids and I play the battle of Aughrim something like:
(ABAG) (ABAE) | (ABAG) (ABAE) | (ABAG) (ABAE) | (ABAG) (ABAE) |
((3AGA) ((3AGA) ((3AGA) AE | ((3AGA) ((3AGA) ((3AGA) AE |\
((3AGA) ((3AGA) ((3AGA) AE |
{C/E/F/GA}B3c d3e | d2e2 d2f2 | d2e2 d2f2 | d2e2 d2e2 | Td8 | cBAG HE4 |
(ABAG) (ABAE) | (ABAG) (ABAE) | (ABAG) AE |
((3AGA) ((3AGA) ((3AGA) AE | ((3AGA) ((3AGA) ((3AGA) AE| (GABc) d3e|\
d3e d2f2| d2e2 d4 | (cBAG) HE4 |]
But I get the impression that the Battle of Aughrim, strictly speaking,
consists of a set of tunes, of which this is only part.
What are the other parts called please ?
Searching through my collection of abcs I found that tune in the O'Neil's
project files, complete with its header (makes it a lot easier to work
with:-)
X:1845
T:The Battle Of Aughrim
M:2/4
L:1/16
B:O'Neill's 1845
Z:Transcribed by Bob Safranek, [EMAIL PROTECTED]
Z:There is no way to duplicate the notation of the grace notes in bar 8
K:G
(ABAG) (ABAE) | (ABAG) (ABAE) | (ABAG) (ABAE) | (ABAG) (ABAE) |
((3AGA) ((3AGA) ((3AGA) AE | ((3AGA) ((3AGA) ((3AGA) AE |\
((3AGA) ((3AGA) ((3AGA) AE |
{C/E/F/GA}B3c d3e | d2e2 d2f2 | d2e2 d2f2 | d2e2 d2e2 | Td8 | cBAG HE4 |
(ABAG) (ABAE) | (ABAG) (ABAE) | (ABAG) AE |
((3AGA) ((3AGA) ((3AGA) AE | ((3AGA) ((3AGA) ((3AGA) AE| (GABc) d3e|\
d3e d2f2| d2e2 d4 | (cBAG) HE4 |]
It's nothing like the Battle of Aughrim which I know, in fact it doesn't sound
like a tune at all - more of an introduction, perhaps?
The tune I know is this one (in Henrik Norbeck's transcription):
X:7
T:Battle of Aughrim, The
R:march
Z:id:hn-march-7
M:2/4
L:1/8
K:Ador
|:EA AB/d/|ed cA|BG G/F/G/A/|B/G/A/G/ ED|
EA AB/d/|ee/d/ ea/g/|ed B/e/d/B/|A2 A2:|
|:a/b/a/g/ ef/g/|a/b/a/g/ ef/g/|aa/f/ gg/e/|dB G2|
a/b/a/g/ ef/g/|a/b/a/g/ ee/d/|Be dB|A2 A2:|
variations
|:EA A/B/c/d/|ed cA|BG G/F/G/A/|BG ED|
EA A/B/c/d/|ee/d/ ea/g/|a/g/e/d/ B/e/d/B/|A2 A2:|
|:ag ef/g/|a/b/a/g/ ef/g/|af ge|d/e/d/B/ Ga|
ag ef/g/|a/b/a/g/ ed|Be dB|A2 A2:|
version 2
|:EA AB/d/|ed/B/ cA|BG GA|BA/G/ ED|
EA AB/d/|ed e/a/a/g/|e/g/e/d/ B/A/G/B/|A2 A2:|
|:ae ef/g/|a/b/a/g/ ef/g/|a/b/a/f/ ge|d/e/d/B/ Gf/g/|
ae ef/g/|a/b/a/g/ ed|Be dB|A2 A2:|
The same tune turns up again as a Polka in Richard Robinson's
tunebook:
X:18
T:After the Battle of Aughrim
R:Polka
O:Scotland
O:Ireland
M:2/4
%%RR_hdr-OriginalCollection: URL:http://www.leeds.ac.uk/music/Info/RRTuneBk/
%%RR_hdr-AbcTypedBy:Richard Robinson [EMAIL PROTECTED]
K:ADor
E2A2 ABcd | e2d2 c3A | B2G2 GFGA | B2AG E2D2 |\
E2A2 ABcd | e2d2 e2ag | e2d2 BedB | A4 A4 :|
|:\
a2e2 e2fg | abag e2fg | abaf g3e | dedB G4 | \
a2e2 e2fg | abag e2d2 | B2e2 d2B2 | A4 A4 :|
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Complex Chords in ABC
John Chambers wrote: (And I oughta get me a Mac, too. I wonder how many of the Mac apps run on OSX? ;-) Only Skink (which is in Java, and therefore runs on anything) I think. However, classic Mac OS itself will run under OS X, and you can have both systems running at once, so older programs will also run. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V:
Anton Keijzer wrote: To introduce myself: I have an interest in the usability of ASCII file formats for music composition by blind musicians. My question: In the case of the proposed V: extension to the abc file format, is it proposed to be legal notation to have more than 2 occurences of, for example, V:1, for different segments of the one voice? It might, in my opinion, make abc text more readable, in particular, for blind composers. This would be like the bar-over-bar layout of braille music notation. I'm not sure about braille notation, but you can certainly have multiple occurrences of each V: field. In fact, BarFly will only display the music correctly if each line is preceded by its own V: field, so the layout of the abc is the same as that of the music. Mind you, the usage of the V: field is not very standardised. I wrote a discussion of the differences between the different programs a while back; it's at: http://www.barfly.dial.pipex.com/multivoice.txt Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Which field for melodic codes?
I'm asking this on behalf of a friend who is considering starting a large transcription project, entering music into abc. He wants to use Gore or Breathnach's melodic codes to simplify searching. The question is, what field to use? My personal opinion is that such an important entry needs a field to itself. Is it time perhaps to re-cycle the I: field, used long ago to set tempo by playabc, but long superceded by the Q: field? Or should a new lower-case field be considered? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] repeats
Forgeot Eric wrote: concerning repeats, will it be possible into the new abc standard to have more than two repeats in a song ? And how about repeats like |: blabla '-1.3 blabla :| '-2 blabla :| '- 4 etc... || ? Yes, it's been proposed several times, and I think quite a lot of people would find it useful. It's very easy to make it work in a display program, but a bit of a nightmare for players. In the mean time, you could of course do it like this, which should play properly on all the current software: X:2 T:Valse à Manu R:Valse C:Manuel Murcia H: N: B:Diatonisch Nieuwsblad n°14 (fév 1988) D:Maluzerne O:France A: Z:[EMAIL PROTECTED] -- http://anamnese.fr.st M:3/4 L:1/4 Q:3/4=78 P:ABCABDABCABE FGFHFGFH IJIKIJIL K:Am [P:A]f/ a/f/ \ [P:B]| e2c | Af a/f/ | e2c | Ac A/c/ | BdG |\ [P:C] B/G/ d/G/g/d/ | [c2e2] A |Af a/f/ || [P:D] g/d/ B/g/ d/B/ | c2 A | Af a/f/ |\ [P:E] g/d/ B/g/ d/B/ |c2 A | A3 \ [P:F]| b2 a | aba |\ [P:G] c'2b | bc'b |\ [P:H] e'2d' | e'd'd' | [P:I]e b/e/ c'/e/ | d'e'c' |\ [P:J] b2a | agf |\ [P:K] a3 | agf |\ [P:L] a2 g | a3 || Probably not what you want to see in the staff notation, though. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] re : repeat / or P: field
Concerning the P: field, I don't know any abc player that play a song in the correct order defined in the P: header (with this test for example : X:1 T:test M:3/4 L:1/4 P:aabccaa Q:3/4=78 K:C P:a CCC P:b DDD P:c EEE ) But it is in the standard... Not quite - you have to use capital letters for the part names. If you do that then BarFly plays it in the order specified. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] pdf files (re : from ABC to image)
On Fri, 26 Apr 2002, Forgeot Eric wrote: Is it possible to compile and use abcm2ps on a mac ? When you find out I'd really love to know, not for myself but for my mac-friends. Please post it here if it is/isn't possible... It's certainly possible. Under OS X (which is BSD Unix underneath) you should be able to compile and run it from the command-line interface just like any other unix. Under Classic Mac OS, you could download the MPW development system from Apple and compile it as an MPW tool to be invoked from within the MPW shell environment. Alternately you could use MPW or another development system to compile it as a free standing program within a drop shell. You'd also need a lot of time, patience and technical knowledge. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Tunes with chords
I'm currently adding a routine to BarFly which will expand guitar chords into a second voice; John Walsh's earlier example of the strangeness of chords suggested by abcMus will look like this: X:1 T:Tommy Reck's R:polka Z:J Walsh (with strange chords from abcMus:-) S:T. Reck M:2/4 V:2 volume = 50 T=-12 K:D [V:1] A2d2 fgfe|d2F2 A3d|c2E2 G3B|A2D2 F2A2| [V:2] [^A,4=F4^A4d4=f4^a4][^D,4A,4^D4G4A4^d4]|\ [^D,4^A,4^D4F4^A4^d4][A,4=F4A4=d4=f4^a4]|\ [^A,4=F4^A4c4=f4^a4][^G,4^D4^G4B4^d4^g4]|\ [^A,4=F4^A4d4=f4^a4][=F,4=C4F4=A4=c4f4]| % [V:1] A2d2 fgfe|d2F2 A3d|c2A2 G2E2|F2D2 D4:| [V:2] [^A,4=F4^A4d4=f4^a4][^D,4A,4^D4G4A4^d4]|\ [^D,4^A,4^D4F4^A4^d4][A,4=F4A4=d4=f4^a4]|\ [=F,4=C4=F4A4=c4=f4][^D,4^A,4^D4G4^A4^d4]|\ [^A,4=F4^A4d4=f4^a4][A,4F4A4d4f4a4]:| % [V:1] f2d2 d4|c2B2 B4|e2B2 c2B2|B2A2 F2A2| [V:2] [^A,4=F4^A4d4=f4^a4][A,4F4A4d4f4a4]|\ [^G,4^D4^G4B4^d4^g4][G,4D4G4B4d4g4]|\ [^G,4^D4^G4B4^d4^g4][G,4D4G4B4d4g4]|\ [=F,4=C4=F4A4=c4=f4][F,4C4F4A4c4f4]| % [V:1] f2d2 d4|c2B2 B4|B2e2 B2c2|d6 z2:| [V:2] [^A,4=F4^A4d4=f4^a4][A,4F4A4d4f4a4]|\ [^G,4^D4^G4B4^d4^g4][G,4D4G4B4d4g4]|\ [^G,4^D4^G4B4^d4^g4][^A,4=F4^A4c4=f4^a4]|\ [=F,8=C8=F8A8=c8=f8]:| (BarFly users will need the latest version to play this, as the previous one didn't allow V: fields inline.) I'm looking for tunes to test it on. At present the input tune must be single-voice, which rules out Atte's jazz transcriptions for the moment (but I'll get to that in due course). Anybody know of any site which has complicated single voice tunes with chords? (Preferably with key and metre changes, frequent chord changes, unusual chords etc. to give the code a roasting.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Tunes with chords
Jack Campin wrote:
Is this odd enough in the slurs department? The BarFly documentation
doesn't say how you'd prefer to write the -3 chords so I've left them
as they are in the book.
-3 chords are no problem. At the moment, continued lines are a problem,
and the routine strips the continuation chars out and handles it one text
line at a time.
Here's the output:
X:1
T:Yammil Abaya
T:Lovely Maiden
O:Iraq
B:Charles Haywood, Folk Songs of the World (1966)
Z:Jack Campin 2002
N:BarFly doesn't display the second chord in line 5.
N:It does if you put the chord on the principal note, rather than on
N:a beam of grace notes.
N:The double bars mark text line breaks, but are
N:really a workaround for BarFly's line-end bug.
M:4/4
L:1/8
Q:1/4=90 % Andante; no metronome value in the book
V:2 volume = 50
K:C
[V:1] d2 ({cd}(c)B)(B_A) (BA) | (G3_ A GF G2)||
[V:2] [G,8D8G8d8g8d'8]| [G,8D8G8d8g8d'8] ||
%
[V:1] F2 (FE) F2G2 | G6 z2 ||
[V:2] [^A,8F8^A8f8^a8f'8] | [C,8G,8C8E8G8c8] ||
%
[V:1]_B2 (BA) ({B}(A)G) GF | (F E2 F ED E2) ||
[V:2][^D,8^A,8^D8^A8^d8^a8]
|[^A,6F6^A6f6^a6f'6][E,2B,2E2G2B2e2]||
%
[V:1] G2 F2 ({F}E)_D (ED) | C8 ||
[V:2] [C,8G,8C8G8c8g8] | [C,8G,8C8E8G8c8] ||
%
[V:1] c2 cB c2d_e |({d_e}(d)c- c2-c3)||
[V:2] [F,8C8F8c8f8c'8] | [G,4D4G4d4g4d'4][C,3G,3C3E3G3c3]||
%
[V:1] (B|d2) (cB) (B_A) ({c}(B)A)| G8 ||
[V:2] [C,G,CEGc]|[G,8D8G8d8g8d'8] |[G,8D8G8B8d8g8] ||
%
[V:1] F2 (FE) F2G2 | G6 z2||
[V:2][^A,8F8^A8f8^a8f'8] |[C,8G,8C8E8G8c8] ||
%
[V:1] d2 ({cd}(c)B)(B_A) (BA) | G6 z2||
[V:2][G,8D8G8d8g8d'8] |[G,8D8G8B8d8g8] ||
%
[V:1] F2 (FE) F2G2 | G8 ||
[V:2][^A,8F8^A8f8^a8f'8] |[C,8G,8C8E8G8c8] ||
%
[V:1]_B2 (BA) ({B}(A)G) (GF) |(E3F E_DE2) ||
[V:2][^D,8^A,8^D8^A8^d8^a8]|[C,8G,8C8E8G8c8] ||
%
[V:1] G2 (GF) ({F}(E)_D)(ED) | C8 |]
[V:2][^A,8F8^A8f8^a8f'8] |[C,8G,8C8E8G8c8] |]
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] !fine! exclamation-point abuse
John Chambers wrote:
(about the !foo! construct)
Hmm ... I'd forgotten who didn't like it, of course. The general
feature does seem to be inherently useful, so I'd suppose that the
objection is to the particular syntax. The other one I've seen is the
one that uses double quotes and positioning stuff, as ^segno or
_da Capo. This strikes me as a usable alternative, though it still
does have the problem of confusion with accompaniment chords. People
might want to position them too. I suppose you could say that chord
symbols can't be positioned this way, and any text with ^ or _ after
the is assumed to be musical annotations.
The placing of guitar chords (above or below the staff) is up to the
application. You are unlikely to want to change that setting in mid-
tune. Text annotations do need to be placed differently within the same
tune, so ^_ and are needed. Text annotations are just text, they're
not intended to be interpreted or substituted in the way that user-defined
symbols and macros are.
| But the !foo! notation itself seems simple. And a header line that
| says something like m:q=!foo! seems like it would be trivial to
| implement. ...
|
| Sure. Just leave out the bangs - they are utterly unnecessary.
How so? That would imply that such macros can only be used for this
purpose. I couldn't use them to abbreviate other common strings. I'd
think a simple substitute this for that would be more useful, in
which case you'd want the bangs included. Sorta like in C you can do
things like:
#define begin {
#define end }
Fine - but C doesn't force you to write
#define begin !{!
and then go through your code writing exclamation points around every
brace. That's what is being proposed for abc. The existing abc
definition gives us the letters H..Z, and they are already in use by
most programs. Any well-written program will ignore one of these
symbols that it doesn't understand. You can use them singly or in
combinations if you really need more than 19 special symbols in one
tune, and you can define their meanings elsewhere. This has got
nothing to do with macros - we're not substituting one bit of text
for another; instead we are choosing which bit of code will be invoked
when the parser encounters that symbol.
So if I write the definition:
U: J = fermata
then an application which knows how to draw a fermata will draw one
over a note which is preceded by the letter J, and an application which
knows how to play a fermata will stretch the duration of the note a bit.
An application which does not recognise the definition should do nothing,
and no real harm will be done.
By comparison, writing the word !fermata! in the music makes the line
eight characters longer than it need be, and makes the abc harder to
read because it breaks up the flow. This is already the case with
guitar chords - they make the abc much harder to read because they
add lots of extraneous symbols to the line of music. I want to limit
what goes into a line of abc to the important stuff; notes, times,
bar lines etc which is what you want to read, and compress the other
less-important stuff into single characters which have less impact
on the readability. In addition, using !fermata! totally breaks
programs which don't understand that convention, and the existence
of large numbers of files which already contain exclamation marks
(for a totally different purpose) means that it's difficult to
implement in a way which will also deal reasonably with abc2win
files. It's not backward-compatible in either sense - old files
break new programs and new files break old programs. The worst
of all worlds in fact.
| Basic substitution macros are very useful, they don't stop you from going
| on to deal with macros which know to transpose (which are even more
| useful).
I've always found that transposing is easiest with a separate program
that just does transposing. Builtin transposers in the fancy music
packages are mostly good for laughs when they produce totally berserk
notation. Thus, I've seen music transposed from F to G, in which all
the ^F notes were written as _G, and there were no Fs in the result.
The problem with this as a builtin is that when it's broken like
this, you can't fix it. If your transposer is a separate program, you
can write your own, or grab something like abc2abc, and it's fixed.
I'm not talking about transposition of a whole tune here, I'm talking
about transposing macros which define the meaning of a musical symbol
in a pitch-independant way, so that the macro does the right thing
whatever pitch of note the symbol is attached to.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] !fine! exclamation-point abuse
One thing about macroes, however, is that you don't _have_ to use them; you can fully expand the macro in the source if you want to for some reason. Your proposal doesn't fit that need, because if I _want_ to write fff (for fortissimo) in the tune, I can't distinguish it from three f notes unless I have some delimiters. If you just want it displayed as text you can use a text annotation ^fff, but if you want it to play as well you have to write some code to recognise it for what it is and do the right thing, so this is not something that can be done with a macro. In other words, I think we do need to separate out the use of the macro (which in my opinion should be a literal text substitution) from the issue of the syntax of special symbols and/or flow control. Yes, I agree, but there seems to be endless confusion over what is a macro and what is not. However, it seems to me that there is no compelling reason to use a different delimiter like !, since it is easy to parse the contents of quoted strings to find out if they are one of a set of reserved words. Any package that doesn't do that will end up treating them like they treat guitar chords. so instead of U:J = fermata use U:J = fermata (not sure if I've helped here...) I think you're falling into the same hole as everybody else, and thinking of the U: field as a macro definition. In BarFly, the definition U:J = fermata will work OK because the program knows what a fermata is, and will display or play one on any note preceded by the letter J. U:J = fermata won't work because the program does not recognise fermata in quotes. You don't need the quotes in a symbol definition, and you never write fermata in the music - you write J (or whatever letter you have defined to represent it). Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] !fine! exclamation-point abuse
John Chambers wrote: Out of curiousity: Are there any abc programs currently that will accept something like ^ffGmG and do the right thing with it? I know that abc2ps won't; it simply ignores all but the first chord symbol. This should be fixed, of course, but today it doesn't work in Michael's abc2ps or in my (jcabc2ps) clone. Either of the quoted symbols alone work, but if you use two of them, only one appears on the page. It works in BarFly, as long as you don't put the two strings on top of each other (i.e. use the global option to put the guitar chords below the staff in this case). Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: abc's biggest problem
Jack Campin wrote: In Barfly, x doesn't print but does play, like a z. So that example is in 5/4 with a rest and chord change on the 5th beat. Neither does the same thing using the y non-printing non-playing space work. Try lining it up with a parallel voice containing four crotchets and see what you get. This ugly mess is the best I can do in BarFly to get those chords to line up with four crotchets in another voice while retaining the semibreve: V:1 A C4 Amy4 | V:2 GyGy Gy2G| and every additional voice would require quadratically more y's to sort the misalignments out. An example of why I don't show other people the ABCs I've written with y's in. Not true. The timing of 'y' counts for vertical alignment only, so all bars should contain the same total amount of time (and therefore the same time value of ys) to align. Each additional voice will need to contain exactly y4 (divided up appropriately to the notes) to keep the alignment right The real problem here is not with abc at all - it's the fact that guitar chords by convention do not contain any timing information. When you write two chords over a single note in conventional notation you are leaving the timing of the chords to be decided by the intelligent musician who reads it. You can't expect a computer to do that. Using invisible rests (x or y) won't help a player program to play the chords in the correct places either. The only way to do that would be to introduce time values into the chords (or put them in a separate voice with rests as Atte did in the first place). Actually, I think I like that method best of all, even if it's not what happens in conventional notation. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] wishlists
Jack Campin wrote: lack of a way to notate non-classical key signatures. Over the five year history of BarFly, I've had exactly one request from a user for more complex repeat structures and nobody has ever asked for global accidentals to be rolled into the key signature rather than placed on the individual notes as the program does now. I've asked for the latter more generally, on this list, as something all ABC implementations ought to support: it's a basic pre-requisite for starting to handle non-Western-European music, and without it ABC can't begin to do microtones in a usable way. I'd have done it long ago if it were easy. It looks as if it ought to be easy, but it would mean changing the way in which the program stores key signatures. Such a fundamental change would have to be handled very carefully, as it would interact with almost everything else. That said, the missing feature I've most wanted in BarFly for years is the ability to define my own graphical ornament symbols (the requirement predates macros, but now we've got them each such sign could perhaps be bound to a macro). Not particularly easy because of the positioning issues and the problem of referencing the graphical elements in a portable way, and I'm well aware that Baroque ornament signs aren't something many folks want to use. Microtonal modes would be a lot simpler and have a far larger potential user base. I'd like to do roll-your-own ornaments but there are, as you say lots of problems. One possibility would be to let you specify the font for annotations. You could then use a font editor to create a special font containing the symbols you want. Font editors are expensive though. And of course tempi in words. Coming soon to a screen near you. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New BarFly problem
From: Phil Sauve Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: New BarFly - Problem Date: Thu, 9 May 2002 22:50:58 +0200 In the new BarFly Using a simple tune, I make an intentionnal mistake in a measure When played, the smily frowns but... When I click on it, it reverts to smile without showing where the mistake is on a separate record, as indicated in Bad tunes. Send me the tune, Phil, and I'll take a look at it. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New BarFly problem
From: Phil Sauve Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: New BarFly - Problem Date: Thu, 9 May 2002 22:50:58 +0200 In the new BarFly Using a simple tune, I make an intentionnal mistake in a measure When played, the smily frowns but... When I click on it, it reverts to smile without showing where the mistake is on a separate record, as indicated in Bad tunes. OK, I figured out how to make this happen. It happens specifically if you play a tune while the display is in split-screen mode and offscreen drawing is turned off. I'll fix it for the next release. In the mean time, turn offscreen drawing on - it's usually a good idea to have this on unless you are running under very tight memory conditions. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Question on 'invisible' rests and chord symbols
I just looked at the online jazz song book (http://home.wanadoo.nl/atte/songbook/) and I was curious about how one of the fields was to be interpreted. The abc file has: v:chords Am x4 GMaj x4| ... v:melody abcd defg|... And then at some point the chords and the melody are 'combined'. Is it always assumed that a voice has chords and melody, so we should always combine them like that? If that's true, how does that combine with the other uses of the voice line where there is a number following then v: symbol. Does each voice have a 'chord' and a 'melody' part, or is 'chord' and 'melody' special voices that are treated differently. I want to incorporate this behavior into my program because I like the convention, but I don't want to break other uses of the voice usage in the 7th symphony (which my program can parse, even though it doesn't all get displayed correctly). There are a lot of problems with usage of the V: field - it's not at all standardised. I wrote a summary of the differences between programs which you might find useful. It's at http://www.barfly.dial.pipex.com/multivoice.txt Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Action against spam, was: KAMPANYALARINIZ iCiN, MUHTESEMKAMPANYA.!! -
1) Let's vote about what the opinion is with spam. Do you think it's a good idea that only subscribers can post here. Yes. Why would non-subscribers want to post (apart from spam) anyway? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Bored with spam discussion. Here's a tune.
X:3
T:Rodney's Glory
C:Guitar arr by Phil Taylor
H:Named for the eponymous admiral, best known in the UK for
his success against the Spanish at the battle of Corunna, and
in the USA for his failure to stop the war of independance by
bombarding various places on the East coast. The Royal Navy
still marches to it. Played as a set dance in Ireland.
N: Tuning DADGBE
R:March
M:C|
K:ADor t=-12
[V:1] ed | c2Bc AB (3cBA | BGEF G2 cd | (3efg ed cdef | gedfedcB |
[V:2] D2 | A,2E,2 =F,2=F2 | G,2E,2G,2C2| B,2 E2 A,2 E2 | G,2D2 D,2 D2 |
%
[V:1] c2Bc AB (3cBA | BGEF G2 ed | c{d}cBA GA (3BAG | A6 :|
[V:2] A,2E,2=F,2=F2 | G,2E,2G,2C2 | A,2 E2 G,2 D2 | D,2 D2 D,2 :|
%
[V:1] cd | eaab aged | (3efg ed c2 A2 | (3gag fg agec | dcAF (3GAG FG |
[V:2] A,2| A,2E2A,2D2| A,2 E2 A,2 E2 | G,2 D2 D,2D2| G,2A,2 G,2 A2|
%
[V:1] AGAB cBcd | ef (3gfe [a2d2A2] ab | {b}aged cdef | ged=f edcB |
[V:2] A,2E2C2E2 | A,2 E2D,2 D2 | D,2 D2 A2E2 | G,2D2 D,2D2|
%
[V:1] c2Bc AB (3cBA | BGEF G2 ed | (3cdc BA GA (3BAG | A6 :|
[V:2] A,2E,2 =F,2=F2 | G,2E,2G,2D2| C2E2 G,2 E2 | D,2D2D,2 :|
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Percussion notation...
On Tue, 21 May 2002, Atte Andre Jensen wrote: All are using regular five-note systems with percussion clef (the official term for the rectangular box replacing the clef). All examples rely on a key to define what notes are where, all though standards more or less include snare on c, hihats and cymbals high and low the stuff being played by the feet (bassdrumm and foot hihat). What's needed to implement this in abc is just the special noteheads + the precussion clef. What is the significance of the two different note heads? Apart from that, it seems to me that abc can already accomodate this, if we add percussion to the list of clefs. If you want percussion abc to be played as well as displayed, you will have to bear in mind that there is a standard relationship between midi instruments and pitch. Phil Taylor (Trying again:-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Percussion notation...
John Walsh wrote; John Chambers writes: Hmmm ... Y'know; that might not be too difficult. For the x note heads, it would have been nice if 'x' hadn't been already taken up as an invisible rest; it would have made an intuitively-correct modifier for this purpose. Maybe we could use '*' for this purpose, so the *e would be an e with an 'x' for the note head. Either clef=drum or clef=perc might be good ways to show the clef. I wonder how long it would take to hack this into your typical abc2ps formatter? Or even, taking a leaf from K:HP, K:perc or K:perc(ADor). Or whatever. A drum clef is bound to be a bit special, to say the least. It could have its own special rules---no need to adopt _all_ the old rules, and carry over _all_ of the old notation, unless they're needed. Most things will carry over, but if something useful and intuitive in drum notation conflicts with something fairly obscure in the rest of abc, it shouldn't be too hard to decide between them. (E.g., the drum clef could even use x for the note-heads and * for invisible rests...if they're needed. It won't break any existing tunes, since no-one has used the drum clef yet.) That's probably the best approach IMHO. It's similar to the way I do Gregorian chant - if you add one of the eight Gregorian clefs to the K: field you get a completely different notation with its own rules, a four-line staff, square note heads and slur brackets used to group the notes into neumes. If you are going to use a five-line staff though you will need to retain pitches to specify which line the note appears on, and if you want to play it via midi you have to specify a pitch to get the correct instrument. That said, how deeply is the invisible rest embedded in abc? I had the impression it was introduced to get around the limitations of the guitar chord mechanism. If ever one could rationalize that... No, it's more important than that. In multivoice abc, when you merge two voices onto one staff you often need to suppress rests in one of the voices, but they still have to play and they're still needed to align the voices correctly. You would probably have even more need for this in a percussion score. Phil Taylor (Trying again:-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] The F F (and F F2) problems
Laura wrote: abc2ly enables you to get both printed and played music from abc. I haven't fixed the ^F-|F problem yet, although it's on my list, but it certainly doesn't have the F F problem. What's the F F problem? Is that due to abc2midi misinterpreting R:Hornpipe to mean some other split of time between the two notes? Another problem I've come across with broken rhythms is that when you use it between notes of different lengths the result seems to be different in different programs. BarFly follows the standard by dotting one note and halving the other, but this gives a different total time duration from the original pair of notes: F F2 is interpreted as F3/ F which adds up to 2.5 rather than 3. It's clear that some other programs do it differently, transferring a fixed amount of time between the notes to keep the total constant so: F F2 is interpreted as F3/ F3/ or as F3 F adding up to 3. Which is correct? At the moment I advise users to avoid using broken rhythms between unequal notes on the grounds that the result is unpredictable - if in doubt write it out in full. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] To tell the dancer from the dance
Laurie wrote: Frank Evil Grin Nordberg challenged Can anybody come up with a clear and consise definition (in twenty words or less) of the difference between musically relevant and purely notational features? A difference between two pieces of notation is musically relevant if and only if it means they should sound different. (20 words) Thus writing in a different key and inserting accidentals to correct is not musically relevant. Writing something in bass clef rather than treble clef with many legers is not musically relevant. Putting guitar chords above the staff rather than below is not musically relevant. An instruction to play a note on fret 9 of the G string instead of the open E string is musically relevant. I agree. However, some features of musical notation which are not musically relevant are nonetheless important beacuse they make the music easier to read (e.g. bar lines and beams) or because they make the notation more compact and efficient (e.g.repeats and the broken rhythm marker in abc). The criterion of musical relevance is certainly something we should consider when discussing extensions to the language, but I don't think it's of overriding importance. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: To tell the dancer from the dance
Bryan Creer wrote: Strike the concertina's melancholy string! Blow the spirit-stirring harp like anything! W.S.Gilbert Laurie Griffiths said - An instruction to play a note on fret 9 of the G string instead of the open E string is musically relevant. My concertina doesn't have E or G strings and I'm not playing top E on the G string of my fiddle for anyone. A difference between two pieces of notation is musically relevant if and only if it means they should sound different. This and the example imply that the instrument being played is relevant. Wouldn't it be best to exclude instrument specific notation from abc? It could get very messy if you don't. That's a purist approach. While it would be nice to have a notation system uncluttered by instrument specific notation it would rule out a lot of useful stuff which is already in abc, e.g. the HP and Hp key signatures, u and v in fiddle music, and even [chords], since they are only relevant to polyphonic instruments. The difficulty is to know where to draw the line. Instrument-specific markings should not make it difficult to read or parse the abc. If Laurie wants to write something like ^F9S3e in his music to indicate that the note is to be played at a particular point on the fingerboard I don't see why he shouldn't. The result _does_ sound different, and is relevant to a guitarist playing from the music, and although I doubt if anybody will ever write a player program capable of dealing with such subtleties, I can see that such hints could be useful to a program which generated tablature from abc. Having said that, it's clear that if he wanted to mark every note with fret/string markings, he ought to be using tablature in the first place, rather than abc. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] re : re: what does that means ?? slurs and ties
Forgeot Eric wrote: I can read it (even if it's not pleasant). But some abc software can't and play badly the legal way of noting slurs. If Barfly has no problem with this, that's good. I've downloaded a mac emulator in order to try it but unfortunatly I haven't managed yet to install a 7.0 system on the emulator so I can't have a look at barfly. (I'd really like to !) System 7.0 was a bit buggy - try and get hold of 7.1, 7.5 or 7.6 as they should all work better. I've tried BarFly on a couple of emulators, Fusion (www.emulators.com) and Executor (www.ardi.com). Of the two, Fusion is free but very complicated to install, and requires a Mac ROM image to work. I couldn't get any sound out of it (probably due to lack of the appropriate sound card driver) but everything else worked fine. It's DOS based, and you have to re-start the machine in DOS mode to use it. Executor is very simple to install and runs under Windows. It doesn't require a Mac ROM or any special drivers to work. It doesn't support Quicktime or the modern Mac Sound manager, so again it won't play, or export midi, aiffs, QT Movies or pictures of the music in any format other than PICT. Ardi tell me that they are currently working to support Quicktime, so this should improve in future. Executor is expensive, but the free demo version does everything but print. If you need any help, mail me offlist. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] P: Field
Luis Pablo Gasparotto wrote: Is the P: field voice dependent or not? All fields in the tune (except possibly those which come before the first V: field) are voice dependent. After the first V: there is nowhere to put a field which is not within a voice, so all fields apply only to the voice in which they are located. If the answer is not, why abc2abc extracts it only for the last voice? Post the tune and the result so we can see what's happening. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: The new BarFly
Phil Sauve wrote: I use the new BarFly I question myself on two points 1- At opening, I get the message Cannot find the macros folder (whyle the macros folder is indeed in the same folder as BarFly) One possible reason for this is a corrupted preferences file. Quit from BarFly (if it's running) and go into the System:Preferences folder. Find the BarFly Preferences file and drag it out onto the desktop. Then re-start BarFly. The last free version of BarFly had a bug which sometimes caused this, so if you still have that, remove it so you don't start it up accidentally. (It's a good idea to search your hard disk with Sherlock for old copies of BarFly and remove them all to make sure you don't start up the wrong one by accident.) 2. When I replay a tune in the split screen mode, the music play always goes back to the first tune entered and then I have to manualy go to the tune I want repeated. When you play a tune in BarFly, the tune which plays is the one where the text insertion point is located. If you move the insertion point yourself you may find a different tune plays than the one whose music is on display. Is that what's happening here? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: To tell the dancer from the dance
John Walsh wrote: One basis of misunderstanding here may be an assumption that instrument-specific notation must be carved in stone in the language--as u and v for upbow and downbow are now, for instance. It doesn't. (It can't, really, for abc doesn't have the resources. In my own case, I have to invent notation which would be quite useless to almost anyone else, and I certainly don't want to saddle others with it.) However, I think that a lot of the instrument specific--and other--notation could be introduced from the users end, if there just is sufficient flexibility in abc. (And there is, at least potentially.) For instance, suppose we had a generalization of the much-overused guitar-chord mechanism which would: (a) put arbitrary text over the staff (b) ditto under the staff (c) ditto over a note (d) ditto under a note (e) ditto in front and behind a note and which could (f) deal with fonts, and (g) have enough flexibility in positioning to keep things from overwriting each other, and even (heresy!) make them look nice. BarFly does (a) - (e) already. (f) is planned for the version after next. The text editor will already let you set the font, style, size and colour of any range of characters (even individual characters if you want), and this information will be transferred to the music display on request. Of course it won't be possible to transfer this information to other programs, as it's not part of the abc. I'd like (g) to be automatic if at all possible, but it remains to be seen if that can be done. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] re : re: what does that means ?? slurs and ties
John Chambers wrote: Jeff wrote: | From: John Chambers [EMAIL PROTECTED] | In any case, most musicians don't consider them to be different. | | This one does. :-) Some folk musicians may not consider them to be | different, but I'd argue that most classical musicians do. Yeah; fiddlers generally distinguish them. Players of plucked strings and keyboard generally don't. I play all three, so I'm completely at odds with myself on the issue ... I'm a guitar player, and I certainly distinguish them. Well, golly; I was expecting to trigger a flame war. And here everyone seems to be very nearly agreeing ... My recommendation for a standard recommendation would be to say that in ABC, these are all legal: A- A (A A) A- B (A B) I don't have a lot of use for A- B (although I suppose you could use it to imply that you get from A to B by bending the note sharp, rather than plucking or hammering on, which is what I would take (A B) to mean). I don't think most people would understand that though, so if I used it for that purpose I'd have to say so in words in the header. We should also attempt an education campaign to teach musicians what the difference is between a tie and a slur. This will be a losing battle, and a lot of ABC will always confuse the two, just as a lot of printed music confuses them. But attempting to restrict usage to some obscure rules isn't very useful; education is much better. Despite all suggestions to the contrary, I haven't yet come across an abc tune where A- B appeared to be a genuine attempt to convey a stylistic nuance rather than a mistake. You see it most often in tunes which are full of other mistakes. This doesn't make life easy for those trying to write ABC players. You can say that again. One idea might be to officially encourage the use of the A: header field to label specific styles. This could help if you want to make sense of such style-specific notation. And, since people won't do this, and because we want to play things in different styles, the software should have options to override any such things and impose a style. This is really how things like and should be handled. Yes and no. and should be handled first exactly as the standard says, but with the option of applying a stress program which shortens or lengthens the notes in each bar in a regular pattern invoked by the R: field. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Defining the non-note letters
John Chambers wrote: As I (sorta) understand the suggestions, they amount to defining a list of standard musical terms, possibly in the !...! form. This would give us a list of things like !fermata!, !mf!, !sfz!, !trill!, !roll!, and so on. These could be used, but the result would be cluttered and not very readable. So then we define the macros as something like: m: T !trill! m: ~ !roll! m: H !fermata! Here we go again. Once more I will try to explain the difference between redefinable symbols and macros. They are not the same. Macros substitute one piece of text for another, while redefinable symbols change the binding between the finite set of characters 'H'..'Z' and a (potentially) infinite set of musical symbols. Macros can be implemented in a preprocessor (or a separate program), redefinable symbols can't be, because you have to write the code to draw the new symbol. If your program doesn't know how to draw an inverted fermata, no amount of text substitution in the abc input is going to persuade it to do that. So forget macros for the moment - they are not what you need here. Suppose I want to add a new symbol to the list which my program supports. I'm doing guitar transcriptions and I need an arpeggio symbol. First I have to write the necessary code to draw a vertical jagged line to the left of a chord. Then I have to give it a name: arpeggio. To invoke it from the abc I then have to define one of the 19 letters which the standard provides for this purpose to mean arpeggio like this: U: R = arpeggio and in the abc I can write R[CEG], and have the chord drawn in the staff display with an arpeggio symbol before it. The default meaning for R is a medium length phrase mark, so a user who wanted to use both of these symbols in the same music would have to use a different letter for the purpose, or define another letter to mean medium phrase mark. Of course you could go on to define a macro which would substitute the symbol R for the word arpeggio, or if you insist !arpeggio!, and then write !arpeggio![CEG] in the abc, but then you've lost all compatibility with the existing standard and cluttered up the abc by adding nine extra characters to invoke a single musical symbol. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: The F F (and F F2) problems
Frank Nordberg wrote: I've been trying to find a piece of music where FF2 actually would make sense. In the end I had to write one myself. Except for the V: header fields - which are idiomatic for BarFly - this should be pretty straight forward ABC. There are a few nasty little details here, though, so maybe it'd be suitable as a test tune for an abc parser. ;-) Ooh that's dirty! Ties across metre changes, across into and out of broken rhythm pairs, broken rhythms used as part of triplets... And it actually works as a piece of music too. Might I suggest An Evil Grin as a title? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] BarFly v 1.1 available
There's a new version of BarFly up for downloading. New in this version: * Split-screen display rearranged to place the text and index panes side by side to make better use of the screen area. * You now have a choice of default font and size for new windows. * There's a fix for the problem of bad sound under OS X 10.1. * A new command Expand Guitar Chords takes a single-voice abc with guitar chords and converts it to two voices with the chords written out in abc in V:2. * The Q: (Tempo) field can now contain a quoted text string. People who have a pre-release version of v 1.1 should download this as there are a few more bugs fixed in the final release. Users who have registered the previous version need take no special action, as your registration will be good for all subsequent versions until futher notice. Get it from: http://www.barfly.dial.pipex.com Enjoy! Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] P: Field
Jack Campin wrote: All fields in the tune (except possibly those which come before the first V: field) are voice dependent. After the first V: there is nowhere to put a field which is not within a voice, so all fields apply only to the voice in which they are located. How on earth does that let you control part playing order in multi-voice music? You have to put each P: field in all of the voices if you want to control playing order. Same goes for M: and K: fields (assuming that you want all the voices to change metre and key at the same point). When playing a tune with a part-order, BarFly seeks for the P: fields in the specified order within each voice in turn, ignoring the contents of the other voices. You could, in fact, make the parts play in a different order within each voice (although I can't immediately think of a reason why you might want to). Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] P: Field
Jeff Bigler wrote: You have to put each P: field in all of the voices if you want to control playing order. Same goes for M: and K: fields (assuming that you want all the voices to change metre and key at the same point). The latter pair is actually useful for some picese. To give a couple of examples, Charles Ives's first string quartet has a section in which the first violin and viola are in one meter, and the second violin and cello are in another meter. Bela Bartok wrote several duets in which the two voices are playing in different keys. Yes, even Bach did it. One of the Goldberg Variations has the two hands written in different metres. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] resons for using abc
Ulf wrote: My conclusion: abc is good for people who (1) are very experienced in the use of a computer, (2) who can do the necessary intellectual abstractions in their mind and type in the tune at the same time (3) who use sheet music - both reading and writing, and who write a lot of musical notes and therefore have a big sheet music output. I see what you are getting at, but I have to disagree to some extent. (1) is true if you are going to use a text editor + abc2ps + ghostscript or abc2midi + midi player. On the other hand, the GUI based programs (abc2win, abcMus, BarFly) are no more difficult to use than any other program, and complete beginners should have no more trouble learning how to use them than they would with MS-Word. (2) is certainly true. However, the intellectual abstraction involved is no greater than it is when learning to write and read staff notation. For complete beginners abc is actually easier, since you don't have to spend lots of time counting E G B D F up the staff to figure out where the note should go - if you know the name of the note you want to write, you know the answer already. (3) I know lots of people who work primarily with the abc itself, and rather rarely print out the sheet music. Quite a lot of them don't read music very well, and use abc as a means of acquiring new tunes. Of course no one should think that they can get away with using abc as a substitute for staff notation. In the end you are going to have to learn how to read the dots, but it can serve as an easy introduction to the concepts of musical notation. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] P: Field
Jack Campin wrote: Secondly, it is MUCH easier for a staff-notation generator to suppress the drawing of P: fields in every voice other than V:1 than it would be for a player program to locate P: fields outside of the voice that it is currently parsing and then figure out which point in the current voice corresponds to that. Eh? You'd have something like P:Trio V:1 x... V:2 y... V:3 z... and you've *already* parsed the P by the time you get to x, y, and z. No. Let's say that your Trio label comes in the middle of the tune: V:1 a... V:2 b... V:3 c... P:Trio V:1 x... V:2 y... V:3 z... The parser will parse the whole of V:1, then the whole of V:2, and will not see the P: field until it's half way through V:3. Remember that the play parser operates on one voice at a time. Then, how is a player supposed to take advantage of having P: within the scope of V:? It isn't that way in the header, so if I *do* write a piece where voice 1 has part order ABA and voice 2 has order CDCD, how do I specify that order in the header P: line? If all the voices are supposed to have the *same* order, why do I have the apparent freedom to give each of them any order in the body, and how is this constraint meant to be checked? Obviously you can't do that because all the voices share the same header. You could do it if you made the P header fields relative to voices, as you've decided to do with P's in the tune body. The way you have it at present is inconsistent. Current behaviour is absolutely consistent. In the tune all fields are voice-dependent, while in the header all fields (except V:) apply to all voices. What you are asking for is inconsistent, in that some in-tune fields will apply to only one voice while others apply to all. It might be possible to make part-order a sub-field of V: in the header as you suggest below, in which case it would be voice-dependent, but you would still have to put the in-tune P: fields in every voice. One place this occurs for real is in pieces built over a ground bass. I have seen several sets of these in the eighteenth century Scottish repertoire, and they are all notated as if they had ABC like this: X:1 T:thingy M:something V:1 P:ACDE V:2 bass P: K:G minor % really - that's the key for 9 out of 10 of these things [V:1] [P:A] ... || [V:2] [P:B] ... || % [V:1] [P:C] ... || % [V:1] [P:D] ... || % [V:1] [P:E] ... || that is, the ground is only written out once, under the melody of the first section. BarFly currently forces the user to copy this out for every variation, taking nearly twice as much paper as necessary. That's a different issue as we're now talking about display rather than playing. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] HP/Hp examples
| Except in pibroch, all gracenotes in pipe | music should have triple stems/beams; BarFly gets this wrong, and | consequently so do all my examples. Yeah; abc2ps won't do the triple beaming, either. Yet another option that oughta be added ... Current version of BarFly uses double beams normally, and triple beams when the keysig is Hp or HP. Single gracenotes still have single tails though (not enough room in the screen display for multiple tails on such tiny notes). I might add these when the music is enlarged for printing though. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] re : page layout in abcm2ps
John Chambers wrote: Actually, there's a consistent problem that no software has a chance of fixing: Different printers (even of the same model) have different borders along the edges that they don't print. There's no way that I've ever seen to ask a printer for the size of its non-printing borders. It can certainly be done. Otherwise how would word-processors be able to let you set the size of the margins? On the Mac, when the user does a Page Setup command to set the paper size, the printer returns a record which is stuffed with information, including two rectangles which give the size of the paper and the size of the printable area. Unfortunately, some Epson printers seem to always return the page size for the largest paper they can take, rather than the size of paper which is actually loaded. This can complicate things a bit, but the printable area seems always to be correct. And when a program like abc2ps is run, it generally can't know what printer you're going to use. So even if a program could ask your printer about its border, it doesn't help; you could send the output to a different printer. Yes, the problem is that in abc2ps you're one stage away from the printing process, so you're always going to have to get that info yourself and supply it to the program, rather than have the program interrogate the printer driver. The real solution is to get printers to print the entire page. But you pay extra for that. Most people don't even think to ask about such things when they buy a printer. If it's at work, someone else probably made the purchase decision. And so on. It'll probably be a very long time before printers all print right up to the edge of the physical page. You see the same problem with copiers, of course. You can have a nice printed page of music, and when you run it through a copier, you find that some of the edges fade out. Good things to bring up when some salesman starts talking about the high quality of their equipment. Yeah:-) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
