Re: [abcusers] abc compliant software
Laurie Griffiths said - Muse uses ; to include fingering hints in ABC. i.e. a3;4 means play the a on the 4th string (probably at the 12th fret for guitar). Great idea. I might use this for cross fingering on English concertina and perhaps I could adapt it to indicate forked F on the oboe. I expect lots of other people could come up with ideas for how to use it for their chosen instrument. Bryan Creer
Re: [abcusers] abc compliant software
Hello, I use w: lines to include extra information with the notes and I use the guitar chord signs too (pos.1 is about the position of the crank and the numbers represent the fingers of the left hand 4=little 1=index). To use w: for the fingering makes sense for my purpose because normally there is a finger to every note. examlpe: X:1 M:none L:1/4 K:C pos.1ABcd | pos.1efga :| w:4 3 2 1 4 3 2 1 Simon Wascher [EMAIL PROTECTED] wrote: Laurie Griffiths said - Muse uses ; to include fingering hints in ABC. i.e. a3;4 means play the a on the 4th string (probably at the 12th fret for guitar). Great idea. I might use this for cross fingering on English concertina and perhaps I could adapt it to indicate forked F on the oboe. I expect lots of other people could come up with ideas for how to use it for their chosen instrument. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
Hello, Anselm Lingnau wrote: Bryan Creer [EMAIL PROTECTED] writes: Great idea. I might use this for cross fingering on English concertina and perhaps I could adapt it to indicate forked F on the oboe. I expect lots of other people could come up with ideas for how to use it for their chosen instrument. That's right, but then when you receive an ABC file you need a way to figure out (...) We would probably need to put in a header saying %%fingering concertina or some such, and software might have the option of including the fingering only if it was desired. (...) Why changing the standards for every personal need every time! there are really good tools within the actual standards to express all those things. Just to mention the N: field where one can include all kinds of usefull and other info about the tune or the weather at transcribing time, the P: field which if not used in the header for playing order is just a string of text above a line of music, the % character which excludes text from being recognized by abc-programs so again can be used to add whatever one wants to write down. In abc2ps a text or block of text can be added using %%text and %%begintext plus %%endtext. In fact if one really needs to get all info into the printed music or just a good looking screen display simpy use abc2ps and (and a .ps viewer and maybe a .fmt file) or something alike. If it is just to get the info ino the abc-file use N: or P: or W: or w: or Guitarchords or simlpy %. I hope this was not to mercyless, I still look foreward to every usefull addition to the standards. Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
Which of course means that we need a header somewhere to say "This is guitar" (or English concertina, oboe or whatever) or else some people will be trying thoroughly bizarre fingerings and wondering why they don't work! L. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 26, 2001 9:23 AM Subject: Re: [abcusers] abc compliant software Laurie Griffiths said - Muse uses ; to include fingering hints in ABC. i.e. a3;4 means play the a on the 4th string (probably at the 12th fret for guitar). Great idea. I might use this for cross fingering on English concertina and perhaps I could adapt it to indicate forked F on the oboe. I expect lots of other people could come up with ideas for how to use it for their chosen instrument. Bryan Creer
Re: [abcusers] abc compliant software
On Tue, 26 Jun 2001, Simon Wascher wrote: Anselm Lingnau wrote: That's right, but then when you receive an ABC file you need a way to figure out (...) We would probably need to put in a header saying %%fingering concertina or some such, and software might have the option of including the fingering only if it was desired. (...) Why changing the standards for every personal need every time! there are really good tools within the actual standards to express all those things. Just to mention the N: field where one can include all kinds of usefull and other info about the tune or the weather at transcribing time, the P: field which if not used in the header for playing order is just a string of text above a line of music, the % character which excludes text from being recognized by abc-programs so again can be used to add whatever one wants to write down. In abc2ps a text or block of text can be added using %%text and %%begintext plus %%endtext. In fact if one really needs to get all info into the printed music or just a good looking screen display simpy use abc2ps and (and a .ps viewer and maybe a .fmt file) or something alike. If it is just to get the info ino the abc-file use N: or P: or W: or w: or Guitarchords or simlpy %. Or just write it as text, in the file; but then people who use 'easy' gui abc programs won't see them / more stress on the developers to cope with this. But, if %%fingering concertina is intended to cause the software to do something ... well, if anything's a 'de facto standard', I'd say it's the use of the %% to indicate not-generally-supported extensions. And a jolly good thing it is too. I wonder whether at some time in the future we are going to find ourselves needing to formalise this namespace too, though. I hope this was not to mercyless, I still look foreward to every usefull addition to the standards. Hear hear. -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
Muse uses ; to include fingering hints in ABC. i.e. a3;4 means play the a on the 4th string (probably at the 12th fret for guitar). But who cares about guitars? L. - Original Message - From: John Chambers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 11:24 PM Subject: Re: [abcusers] abc compliant software Phil Taylor writes: | Laurie wrote: | | For consistency, terminate all the fields in the header with ! Line ends | are then logically optional, but omitting them should be deprecated (on the | grounds of readability for humans). | | It would have been nice to have something like this from the start, but | introducing it now would pose all kinds of compatibility nproblems. Probably true. But there might be a better choice. As far as I know, the semicolon isn't yet used at all in abc, and this is the conventional separator char in all sorts of programming languages. Is there any reason we shouldn't adopt ';' as the terminator for header lines and music staffs? It should be pretty easy to implement. Lots of programming languages have a basic syntax of one line is one command, but then allow semicolons to put several commands on one line, and backslashes to put one command on several lines. There doesn't seem to be any obvious reason we couldn't extend abc to work the same way, and it wouldn't break any existing abc. Looking farther ahead, maybe we could persuade developers to slyly start sneaking semicolons into the abc whenever tunes are written or copied, and then after a while almost all the existing abc would have been silently converted. Then we could decree the newline an ignored char and we'd be free of the line-wrap problems. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
Wendy said ...So even if we adopt the abc2win approach to staff termination (not a bad idea), we don't even start to solve the problems with line wrapping. But hang on. We're not trying to solve all the problems in the world. Just the problems in ABC line wrapping. So how about this: Include some mark at the beginning of the piece so that we know what's coming up - say by terminating the X: line with ! Then the rule would be to ignore all line ends until we see !! to mark the end of the piece. That could be in the form !! or ! ! or even ! I'm in two minds as to whether a space (as opposed to a linend should be allowed between. It's sometimes nice to be able to include a blank line in the printed music somehow. For consistency, terminate all the fields in the header with ! Line ends are then logically optional, but omitting them should be deprecated (on the grounds of readability for humans). X:23! T:Bang! K:C #!C #dim[^CEG_ B^c]! ! Oops - sorry - the e-mail fiend seems to have mangled that. It should have been X:23! T:Bang! K:C#! C#dim[^CEG_B^c]!! Laurie Griffiths http://www.musements.co.uk/muse where you will find music notation software for PCs. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
Laurie Griffiths wrote: For consistency, terminate all the fields in the header with ! Line ends are then logically optional, but omitting them should be deprecated (on the grounds of readability for humans). snip X:23! T:Bang! K:C#! C#dim[^CEG_B^c]!! What about U:s=!D.S.! U:O=!coda! (from John Atchley's 101best.abc, included in jaabc2ps) or !something!s within a tune? -- bert van vreckem If Bill Gates had a nickel for every time Windows crashed... Oh wait! He does! To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
Laurie wrote: For consistency, terminate all the fields in the header with ! Line ends are then logically optional, but omitting them should be deprecated (on the grounds of readability for humans). It would have been nice to have something like this from the start, but introducing it now would pose all kinds of compatibility nproblems. One thing I thought of is to introduce a checksum in the header somewhere. If the checksum doesn't match the tune you know that it's been mangled (or even edited by hand). Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
Phil Taylor writes: | Laurie wrote: | | For consistency, terminate all the fields in the header with ! Line ends | are then logically optional, but omitting them should be deprecated (on the | grounds of readability for humans). | | It would have been nice to have something like this from the start, but | introducing it now would pose all kinds of compatibility nproblems. Probably true. But there might be a better choice. As far as I know, the semicolon isn't yet used at all in abc, and this is the conventional separator char in all sorts of programming languages. Is there any reason we shouldn't adopt ';' as the terminator for header lines and music staffs? It should be pretty easy to implement. Lots of programming languages have a basic syntax of one line is one command, but then allow semicolons to put several commands on one line, and backslashes to put one command on several lines. There doesn't seem to be any obvious reason we couldn't extend abc to work the same way, and it wouldn't break any existing abc. Looking farther ahead, maybe we could persuade developers to slyly start sneaking semicolons into the abc whenever tunes are written or copied, and then after a while almost all the existing abc would have been silently converted. Then we could decree the newline an ignored char and we'd be free of the line-wrap problems. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
Bryan Creer wrote: Yes, it is true that www.irishnet.com makes a bit of a pigs ear of the individually displayed tunes but I downloaded the whole collection and it only gave me one significant problem, an M: 6/8 command imbedded in the tune. There shouldn't be a space after the :. So abc2win's error checking isn't perfect. I've never come across this error before. snip Advertising feature - To see whether your ABCs conform to the standard, try ABCcheck. Does ABCcheck report a space in the M: field as an error? It isn't as far as I can see. A space _before_ the colon would be an error. And does it fail to report all those lines which start with a single colon instead of |:? Or all the extra spaces at the ends of lines and between the tunes? How about all the reels marked at Q:180? I suppose that's not really an error; you might want to play like that at an Old Folks Ceilidh:-) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
On Tuesday 19 June 2001 04:34, Frank Nordberg wrote: Do you mean poor John is supposed to offer free personal tutoring to anybody who wants to write ABC? John has given a lot of good advice on the subject both here at abcusers and on his web site, so I don't think you should criticize him for that. I'll add my voice to Frank's on this one. John's contributions of ideas and help both on and off list have been invaluable. Thanks John! Wendy To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
Frank Nordberg said - Hi Bryan - I had begun to wonder if you were on a vacation trip or something. Hi Frank- no, but after Phil Taylor's descent into puerile personal abuse and the subsequent failure of anyone else to tick him off for breach of etiquette I decided I'd had enough for a while and there's only so much you can say to people who don't want to listen. It is only the value I place on abc and the belief that there are some sensible people on this list that brings me back. Do you mean poor John is supposed to offer free personal tutoring to anybody who wants to write ABC? John has given a lot of good advice on the subject both here at abcusers and on his web site, so I don't think you should criticize him for that. and Wendy Galovich said - I'll add my voice to Frank's on this one. John's contributions of ideas and help both on and off list have been invaluable. Thanks John! I utterly agree. John's tune finder is invaluable and he is the source of excellent advice both on this list and through his website. He contributes some excellent ideas for the development of abc which he generally posts for discussion on the list before implementing them rather than presenting them as fait accompli. Apart from some slightly odd interpretations of my views (I've never believed there was a conspiracy of developers, John) he has been invariably polite in his dealings with me. All of which makes his negativity towards www.irishnet.com and his antagonism against abc2win all the more surprising. I don't expect him to give free personal tutoring but if he'd put as much effort into being positive as he has into his recent negativity it might have been more use. I presume that the developers of www.irishnet.com are unpaid volunteers and Jim Vint is hardly profiteering with abc2win nor is their intent likely to be deliberately malicious. Don't they deserve more respect? but do many of the developers care or are they only interested in their own "extensions to"/"gratuitous violations of" the standard regardless of the affect on anybody else? The latter, I'm afraid. Can't really blame them, though. After all most of them are doing this programming for fund - and for free. This really strikes at the point I've been trying to make all this time. I said some time ago that just because developers were working for free that didn't give them the right to dictate to others, either developers or users. Their software is their own but abc is communal property; it calls for a cooperative approach. The V: command provides an excellent example. A great idea that different developers went off and implemented in different ways before agreeing on a common standard. I doubt if it will ever become part of the standard now since quite a few people will have to back down and change their software. You forgot to mention gender, though. Mea Culpa. Laura has already compared (her interpretation of) my views to male chauvinism. Why is Laura the only profilic *female* abcuser? I genuinely have no idea. Is it true? unsubscribe messages Totally unjustified speculation, but I couldn't resist it. Bryan Creer (My spellchecker offers abusers and accusers for abcusers. How delightful.)
Re: [abcusers] abc compliant software
Phil Taylor says - Does ABCcheck report a space in the M: field as an error? No it doesn't. This is a specific problem to do with abc2win (so it will give you another stick to beat it with.) The problem was not with ABCcheck but with abc2nwc. abc2win allows inline commands just by plonking them in and terminating them with a space. A good idea not very well realised. Standard 1.6 makes no allowance for this and the draft standard suggests putting them in square brackets. Better, but yet another meaning when you hit [ in a tune. The line in question was - !:M: 6/8 F2A ABc|ded cBA|Bcd AGF|BGE EFG| (Interesting use of !) abc2nwc read the M: and then read everything up to the next space (ie nothing) and failed to make sense of the result. If the space is edited out, it works. Hence my comment about abc2win's error checking not being perfect. ABCcheck successfully reports this as an error and, if the space is removed reports it as an abc2winism. Don't get me wrong, this was not the only error ABCcheck found. There were 704 in the whole file, mostly to do with bar lines and repeat starts and ends. And does it fail to report all those lines which start with a single colon instead of |:? No. It reports all those. Or all the extra spaces at the ends of lines and between the tunes? Are these against the standard? How about all the reels marked at Q:180? I'm not a music critic. Nice to have you being polite to me Phil. Bryan
Re: [abcusers] abc compliant software
Just to get this one out of the way... John Chambers says - This is presumably the source of his use of the term "hypocrisy". I've just done a quick check and I can't find the term "hypocrisy" in any posting of mine I've still got on file (and I don't tidy up very often). I didn't actually make any comment at all but just compared the statements. The point I was actually making was that you were saying that abc2win was a minor player and that there were thousands of tune to be corrected. Well, perhaps thousands is minor. If abc2win is 5% of the tunes and half its output causes problems, then this could easily account for all the problems that I see. In fact, abc2win isn't nearly this bad. This is, in part, because I've added code that notices some of its variant syntax and handles it most of the time. So in fact a very small proportion of its output causes problems which suggests that it must be a very major player indeed if it still causes so much trouble. I don't use abc2win much so I'm not being partisan. What worries me is the hostile attitude. You are hardly going to get Jim Vint on board with lines like - abc2win, which seems be the current record holder for gratuitous violations of the standard ... and as for what you said about www.irishtunes.net! Be nice to people. Bryan
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
On Monday 18 June 2001 12:19, Frank Nordberg wrote: Sorry Steve, your way behind modern times too. Fact is, we already have perfectly good (or so the ads say) ways to get computers to compose and play the music without any subjective and emotional human interference at all. Yeah, seems your radiostation plays the same music as mine :-) -- Atte To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
On Tuesday 19 June 2001 10:03, John Chambers wrote: The biggest single problem is the damage caused by email line wrapping. This isn't caused by any single program. It's a systemic problem caused by many of the email packages that have been released in recent years. This isn't just a problem for abc; it is a serious problem that programmers have been fighting for decades. Line wrapping destroys code in most programming languages, and makes hash out of a lot of plain-text data files. So even if we adopt the abc2win approach to staff termination (not a bad idea), we don't even start to solve the problems with line wrapping. Yup. It does hideous things to SQL code too. The scripts I routinely forward to our DBA at work *must* be sent as attachments because of this. While working on my code to handle abc2win's variant syntax, it has occurred to me that bringing abc2win into the main line wouldn't be all that difficult. I haven't seen any messages from Jim Vint for some time, and there aren't any in my archived mail for 2 years, so I don't know whether he's even working on it. In any case, we have no way to demand that he do anything; he gave his program out for free, so all we can do is thank him for his work and then ask that he do some more work for us (for free). If he's too busy, we could also encourage someone with a Windows C development environment to take it off his hands and work on it. I could be wrong, but I think it's in VB. IIRC it requires vbrun300.dll (?) Wendy To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
On Tuesday 19 June 2001 10:03, John Chambers wrote: The biggest single problem is the damage caused by email line wrapping. This isn't caused by any single program. It's a systemic problem caused by many of the email packages that have been released in recent years. This isn't just a problem for abc; it is a serious problem that programmers have been fighting for decades. Line wrapping destroys code in most programming languages, and makes hash out of a lot of plain-text data files. So even if we adopt the abc2win approach to staff termination (not a bad idea), we don't even start to solve the problems with line wrapping. Yup. It does hideous things to SQL code too. The scripts I routinely forward to our DBA at work *must* be sent as attachments because of this. While working on my code to handle abc2win's variant syntax, it has occurred to me that bringing abc2win into the main line wouldn't be all that difficult. I haven't seen any messages from Jim Vint for some time, and there aren't any in my archived mail for 2 years, so I don't know whether he's even working on it. In any case, we have no way to demand that he do anything; he gave his program out for free, so all we can do is thank him for his work and then ask that he do some more work for us (for free). If he's too busy, we could also encourage someone with a Windows C development environment to take it off his hands and work on it. I could be wrong, but I think it's in VB. IIRC it requires vbrun300.dll (?) Wendy To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
Richard Robinson [EMAIL PROTECTED] wrote : On Sun, 17 Jun 2001, Steve Mansfield wrote: But at the end of the day if your OS of choice supports the creation of ASCII characters in a file you've got all the tools you need to generate abc. Mmm. But the ability to do something with it is nice, too. Is this a new wave of fundamentalism, let them all just play the tunes straight from a printout of the abc ? Damn right. In fact why stop there? You're making the old-mindset assumption that in the brave new white-heat world of abc fundamentalism dead tree product is allowed. Unless you can download the abc straight onto a memory card which then plugs into a port on the back of your head, and then play the tune from that, you're history pal! abc2biocomputing - now *there's* something for the sourceforge posse to get their teeth into (providing they can remember their new site password of course). [The entirety of the above post is issued under a General Reading Irony Notice, with parts also covered by the relevant provisions of the Utter Sarcasm Board]. Steve Mansfield [EMAIL PROTECTED] http://www.lesession.demon.co.uk - abc music notation tutorial and other goodies To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
I had planned to watch this thread for a while before adding my thoughts but now there is so much to respond to that it's hard to know where to start so here are a few random hits - John Chambers said - Just a few days ago, I was asked why www.irishtunes.net isn't very well represented in the tune finder's indexes. There are actually a few of their files included, but many of them aren't. I spent a fun hour or so just yesterday looking around the site, and was truly impressed by how badly someone can mangle abc, apparently intentionally. It's like they studied a number of abc tools with the goal of producing abc that wouldn't work with any of them. Did it occur to you, John, as an experienced and knowledgeable abc user and member of the standards committee, that it might have been more constructive to offer some helpful advice rather than slagging them off as wilfully incompetent? Perhaps the fact that they use and endorse abc2win puts them beyond the pale. John Chambers and Phil Taylor produce statistics to prove that abc2win is a minor player in the field and yet John says - Again, the big problem is the abc2win tunes and In the meantime, Chris's 1.6 "standard" is what we have, and abc2win violates it in numerous ways. This could be fixed, if someone were to volunteer to do it, though it would mean a bit of work converting a few thousand old abc2win files. John also says - I sure do wish we could get abc2win in line with the standard. Well you could start off by being polite to Jim Vint and making him feel a bit more welcome within the abc community (I wouldn't mind that myself). I agree that there are some irritating deviations from the standard in abc2win but they are documented and consistent so they can be worked round without too much trouble. Yes, it is true that www.irishnet.com makes a bit of a pigs ear of the individually displayed tunes but I downloaded the whole collection and it only gave me one significant problem, an M: 6/8 command imbedded in the tune. There shouldn't be a space after the :. So abc2win's error checking isn't perfect. I've never come across this error before. The antagonism towards abc2win seems totally out of proportion to any problems it causes. Could people be just a little bit jealous of its success? It seems a little strange that, given the reactions to Gianni's description of abc2win as the de facto standard, nobody raised even a whisper of protest when Wil Macaulay said - if you write your abc/Noteworthy converter to use a version of abc that is not in the 1.6 standard (I'm not even talking about 1.7 extensions here) you will be creating tunes that are not readable by abc2win, which is the most common abc platform for windows. Bad move. (Not that I'd ever considered doing anything of the sort.) Again, from John Chambers - One of our problems is trying to keep abc from splitting into incompatible branches. We do have branches, but so far abc2win seems to be the only one with significant incompatibilities. Interesting, then, that, in reply to Hartmut Wiechern's problems with Personent Hodie, Frank Nordberg said - Use the only second of the two ABCs. The first of them is specially formatted for BarFly, the second one for abc2ps/abc2midi. It's a clumsy way around the present ABC incompatibility problems, but it seems to be necessary with music as comples as Personent Hodie ABC's great strength is as a means of communication between musicians regardless of race, colour, creed, religious affiliation, hardware, operating system or software preference but do many of the developers care or are they only interested in their own "extensions to"/"gratuitous violations of" the standard regardless of the affect on anybody else? Advertising feature - To see whether your ABCs conform to the standard, try ABCcheck. Even if you are not interested in Noteworthy, ABC2NWC can be used to clean up your collections by converting to nwc format and back again since it is, indeed, liberal in what it accepts and conservative in what it produces. Both available from - http://members.aol.com/abacusmusic/ (Windows only, I'm afraid) Happy music making. Bryan Creer PS. I notice that there has been a little flurry of unsuscribes lately. I wonder why.
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
On Friday 15 June 2001 11:20, Phil Taylor wrote: I could equally claim that BarFly is the de facto standard on the grounds that it runs on the platform which is the de facto standard for music production I didn't know BarFly ran on Linux :-) -- Atte To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
Atte writes: | On Friday 15 June 2001 11:20, Phil Taylor wrote: | I could equally claim that BarFly is the de facto standard on the grounds | that it runs on the platform which is the de facto standard for music | production | | I didn't know BarFly ran on Linux :-) Maybe it doesn't now, but if it runs on the latest Mac OS/X, it's only one small step to linux. Now if we could persuade Apple to open-source its code, so the rest of us could start augmenting it ... One of my favorite test cases for music software is the tune at: http://ecf-guest.mit.edu/~jc/music/abc/Intl/tune/JovanoJovanke_D.abc http://ecf-guest.mit.edu/~jc/music/abc/Intl/tune/JovanoJovanke_E.abc Most commercial music software flunks this test rather badly. And, of course, I'd also expect any good software to be able to transpose the first to the second. But I get disappointed a lot. Now if we didn't have to wait for the nice folks at Apple to understand why we might want such strange things ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
John Chambers wrote: One of my favorite test cases for music software is the tune at: http://ecf-guest.mit.edu/~jc/music/abc/Intl/tune/JovanoJovanke_D.abc http://ecf-guest.mit.edu/~jc/music/abc/Intl/tune/JovanoJovanke_E.abc Nice one :-) I made a quick Finale file out of the first one. You can see the results (PDF) at: http://www.musicaviva.com/jovano-jovanke/jovano-jovanke.pdf (sorry about the typo) and hear it at: http://www.musicaviva.com/jovano-jovanke/jovano-jovanke.mid I made one change: isn't there supposed to be a C minor chord in bar 19? I'm not sure about all the details (tempo, which order and in which octaves are the key sig. supposed to be notated etc.) Oh - and yes. I didn't bother to post a version ransposed to E - that's no challenge at all to Finale ;-) Btw, the ABC applications I have didn't do to good a job on these files. BarFly got it mostly right - except it notated a sharp in front of every F instead of incorporating it in ther key signature, while abc2ps and yaps didn't show any key signatures or accidentals at all. Frank Nordberg To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
Frank Nordberg writes: | John Chambers wrote: | One of my favorite test cases for music software is the tune at: | | http://ecf-guest.mit.edu/~jc/music/abc/Intl/tune/JovanoJovanke_D.abc | http://ecf-guest.mit.edu/~jc/music/abc/Intl/tune/JovanoJovanke_E.abc | | Nice one :-) Yeah; it's a pretty tune. I oughta get the words and include them, too. Of course, then we get into the fun of trying to get the proper Cyrillic spelling from equipment sold in the USA ... | I made a quick Finale file out of the first one. You can see the results | (PDF) at: | | http://www.musicaviva.com/jovano-jovanke/jovano-jovanke.pdf | | (sorry about the typo) Yeah; I noticed, and checked to see if that's the way it was in my tune. | and hear it at: | | http://www.musicaviva.com/jovano-jovanke/jovano-jovanke.mid One quibble: It should have one of the instrumental interludes, but not both. Or maybe alternate between them. And a quibble with my transcription: I've heard a number of recordings of the tune, and most don't repeat the first phrase. Of course, that's the sort of thing that people do however they feel like at the time, like optional stretched endings of the phrases. I'm not sure which repeat pattern would be best to put in writing, but maybe I'll change it. Or not. | I made one change: isn't there supposed to be a C minor chord in bar 19? Hmmm ... I'm not sure how you're counting measures. In any case, the chords at several places are quite variable. In particular, the hejaz endings (on D) typically would have Cm chords, but exactly where is somewhat a matter of taste, and I'd guess that's what you mean. I don't think I'd play the endings the same twice in a row. | I'm not sure about all the details (tempo, which order and in which | octaves are the key sig. supposed to be notated etc.) The tempo should be about half the speed of the midi; a measure takes 1.5 to 2 seconds. It's not fast. As for the key signatures, their looks aren't totally standardized. The _B_e^f that you used isn't common, probably because the _e and _f bump up against each other. I've seen both _B_e^F and ^f_B_e, and I'd guess that the reason for those is the more aesthetic layout. What I have my abc2ps clone do is take literally what you give in the K: line. So JovanoJovanke_D.abc has K:Dphr^F, which gives _B_e^F as the signature. My main reason for doing this is so that I can handle signatures that have different accidentals on the same note in different octaves. There was an example some time back of K:G^f=F, meaning that the high f's were all sharp and the low F's were all natural. My code would accept this K line and produce a sharp on the top line and a natural on the bottom space. There are a number of musical traditions that require this. | Oh - and yes. I didn't bother to post a version ransposed to E - that's | no challenge at all to Finale ;-) I do see a lot of output from music software that does silly things like, when transposing to G, writing all the ^F's as _G's. I'm not sure how a program would get it so wrong, but I've seen this far too often. I don't know what software does it, though. | Btw, the ABC applications I have didn't do to good a job on these files. | BarFly got it mostly right - except it notated a sharp in front of every | F instead of incorporating it in ther key signature, while abc2ps and | yaps didn't show any key signatures or accidentals at all. Yeah; while I've gotten a lot of positive responses from my suggestions for explicit lists of accidentals in key signatures, I don't know of anyone else who has actually implemented it. The positive responses come from people who want to use it, of course, and it's possible that I'm the only implementer in that set. Such feechurs are why we need a new standard. (Or a new language that can handle music other than western European. ;-) The Barfly interpretation is consistent with the description of global accidentals in the 1.6 standard. There does seem to be some agreement that this was a bit of a mistake, with the qualification that as an option it could be useful at times. (And the same qualification would imply a second option to spread the entire key signature through the music.) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
I guess you must be an abc2win user then Gianni? As we both know - as anybody else on this list, for the matter! - ABC2WIN is de facto the standard as far as the abc notation is employed on the web, both as far as the mailing list and a number of the abc collections of tunes available for download are concerned. Dont you just hate these unfounded assertions? Once upon a time abc2win was the only GUI abc software around, and it achieved a great deal of success, and helped to popularise the language. However, it has not developed significantly since then, and other programs have far surpassed it in features, ease of use and ability to handle complex abc. I have over 10,000 tunes on my machine, downloaded from all over the web, and less than 5% of them have exclamation marks at the ends of the lines. These tunes do cause problems out of all proportion to their actual numbers, not because of the exclamation marks, but because they are full of syntactical errors (I guess abc2win's error checking is lax, or that the kind of people who use abc2win are not serious enough about their work to check). I could equally claim that BarFly is the de facto standard on the grounds that it runs on the platform which is the de facto standard for music production, or that BarFly's site gets a higher Google page ranking than abc2win does. http://directory.google.com/Top/Computers/Multimedia/Music_and_Audio/Software/Notation/ (The abc home page itself rates 4, after Sibelius, Coda and CERL. BarFly gets position 9 while abc2win scrapes in at 22. No other abc software gets a mention.) And before I get flamed for it I'm not really claiming BarFly as any kind of standard. I was being rhetorical. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
Phil Taylor writes: | I have over 10,000 tunes on my machine, downloaded from all over the web, | and less than 5% of them have exclamation marks at the ends of the lines. Some time ago, I had my tune finder's search bot tell me statistics about such things, and my numbers were about the same. As I recall, a years ago it said that about 7% of the abc tunes it found had symptoms of being from abc2win. Of course, given the error bars on any such estimate, this means that our numbers are the same. After some major rewriting, my search bot no longer reports this sort of data. Maybe I should dig in and make it work again. It could be useful to have data to debunk claims like Gianni's. | These tunes do cause problems out of all proportion to their actual | numbers, not because of the exclamation marks, but because they are full | of syntactical errors (I guess abc2win's error checking is lax, or that | the kind of people who use abc2win are not serious enough about their | work to check). One abc2win thing that I've argued should be added to abc: It produces things like :|| and :|] and other illegal bar-line combinations. I'd like to see these legalized on the grounds that they are obvious and don't break anything. Also, there's the old advice to be liberal in what you accept and conservative in what you produce. At present, software should probably try not to produce such things, but should accept them. | I could equally claim that BarFly is the de facto standard on the grounds | that it runs on the platform which is the de facto standard for music | production, or that BarFly's site gets a higher Google page ranking | than abc2win does. | ... | And before I get flamed for it I'm not really claiming BarFly as any kind of | standard. I was being rhetorical. This is in line with computing tradition. It's standard (;-) for the IBM/Microsoft axis to violate existing standards and then assert that whatever they so is the standard and everyone else should do things their way (which is often not documented, or documented only in Microsoft-format files that can't be read on other systems). At the other extreme, the Apple community produces high-quality stuff that is usually out ahead of any existing standard, but they don't make any claim at all about standards, just that they are the best at what they do. And in the middle is the unix/linux gang, who rightly claim that their OS and a few libraries are standard, and can quote the exact standard to justify this claim, but also point out that the rest of the add-on software is the ad-hoc mess that you'd expect from a crowd that is more interested in easy development than anything else. Note that standard is not a synonym for custom or common. It means that an official government or industry standards body has published the specs for the standard. Strictly speaking, there is no abc standard. We only have Chris's documents as a guideline, and they function as an unofficial standard. This is what most of the abc developers have used, which puts abc2win outside the main stream of abc development. Some of Jim Vint's ideas were good, but since they weren't copied by others and they break the semantics of 1.6 abc tunes, they mostly just cause problems. The recently-formed abc standards group may qualify as an industry standard body when and if they come out with their standard. In the meantime, Chris's 1.6 standard is what we have, and abc2win violates in in numerous ways. This could be fixed, if someone were to volunteer to do it, though it would mean a bit of work converting a few thousand old abc2win files. This conversion could probably be done behind the scene by a new version of abc2win with little pain to the users. Anyone with a Windows C development environment who wants to tackle it? The suggestion that we terminate the ABC line and come up with a new and better music notation is an interesting one, and would probably be the best approach. But I'd predict that the Second System Syndrome would hit such an effort very hard, and the result wouldn't supplant abc at all. It would probably be as bad as MusicML, and unusable by your average musician. I wouldn't mind being proven wrong here. But I'd think that the most practical approach is to try to extend abc as cleanly as we can, while continually insisting that it stay a simple notation that is typable and readable by humans, and let the XML and Lilypond and other folks work on the complete music notation. One of our problems is trying to keep abc from splitting into incompatible branches. We do have branches, but so far abc2win seems to be the only one with significant incompatibilities. Extensions abound, of course, but few of them are actually incompatible. I view this as a healthy sign of an active and (usually) cooperative user community. To subscribe/unsubscribe,
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
On Wed, 13 Jun 2001, Jack Campin wrote: My understanding of the ab construct is that it is specially for hornpipes Your understanding is wrong. Hornpipes don't need any such notation. They are often written in even length notes with the context telling the user to swing them; in ABC, the R: field conveys this information (in fact that's about the only real use for that field). Doesn't follow. -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
Richard Robinson wrote: | On Wed, 13 Jun 2001, Jack Campin wrote: | My understanding of the ab construct is | that it is specially for hornpipes | | Your understanding is wrong. | | Hornpipes don't need any such notation. They are often written in even | length notes with the context telling the user to swing them; in ABC, | the R: field conveys this information (in fact that's about the only | real use for that field). | | Doesn't follow. Maybe not, but R:hornpipe does seem to be the only reported case where existing software uses the R field to decide how to play the music. For teaching purposes, it would be useful if more were done along this line. Of course, to be really useful, you'd need more information than is in the R line. I've thought occasionally that it might be interesting to start a discussion of something like a %%MIDI line that gives information about how to adjust the rhythm. Even with hornpipes, this could be useful. Anyone who has played for Irish step dancers knows that hornpipe covers a range of rhythms. Depending on the specific hornpipe, the ratio of a hornpipe's small notes can range from 3:2 to 3:1. A 2:1 ratio is the most common, of course, which is why some people say that hornpipes should be written in 12/8 or 12/16 rather than 4/4. It could be useful if a midi generator could be told the actual ratio to get the different kinds of hornpipe. And, of course, hornpipes are regularly played as reels. This variability is the basis of the standard argument for writing out music with even notes. If you write a specific rhythm, you imply that this is the correct way to play it. There's no good way in standard notation or abc to indicate variability. The way this is traditionally done is to just write the music out with even notes, and give the musician a hint of some sort as to how it should be played. For an Irish musician, saying hornpipe is a good clue. But this does rely on having a knowledgeable reader. I have a book with several tunes that start with the comment Kato rachenitsa (in Cyrillic script, of course). To a Balkan musician, this is perfectly clear. But I suspect that a lot of people in the world wouldn't quite understand what it's trying to say. In any case, the abc 1.6 standard is fairly clear that ab is just shorthand for a3/4b/4, and ab is shorthand for a7/8b/8. A musician (and a midi generator) is free to interpret this and use some other ratio, but that's a matter of style. The meaning in abc is clear and unambiguous. Writing music with even notes and expecting the musician to know how to modify the rhythm is common in many kinds of music. The classical crowd does this all the time. It's common to write out a detailed rhythm for the first few measures, and then say simile... and write the rest with even notes. This is also done with arpeggiated passages, where you will see a measure or two of written-out arpeggios, and then just the chords. This is done because it makes the music easier to read (and cuts down on page turns). One of the books in my collection is Quantz's On the Art of Playing the Flute, one of the standard references for late Baroque style. (Only around 5% is about the flute itself, and the other 95% is on general musical style.) One section explains that, in slow passages, you should play the small notes in about a 3:2 ratio. Quantz was rather doctrinaire; he said that you should always do this. Others, such as Hotteterre, advised varying the ratio from even to 3:2 or 2:1, to make the music more interesting. The written music never indicated this, and the musician was supposed to just know. Such interpretation of fine details is common to all sorts of music. It's usually not a good idea to indicate it in written music, except for teaching purposes, and abc itself probably shouldn't do much with the idea. But some %%MIDI lines to deal with the subject could be useful to a lot of people, especially music educators. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
Depending on the specific hornpipe, the ratio of a hornpipe's small notes can range from 3:2 to 3:1. A 2:1 ratio is the most common, of course, which is why some people say that hornpipes should be written in 12/8 or 12/16 rather than 4/4. It could be useful if a midi generator could be told the actual ratio to get the different kinds of hornpipe. And, of course, hornpipes are regularly played as reels. ..and the English stage hornpipe of the 18th century was completely undotted anyway. The Village Music Project has a problem with the R: field. As certain hornpipe tunes will be played (by some software packages) dotted when they are not, the only alternative is to leave the R: field blank. This is silly if the tune is called XXX Hornpipe, and also it gives us a database search problem farther down the line if we want to use R: as a tune type field. Johnny Adams - The Village Music Project @ The Institute of Social Research University of Salford, Manchester, UK http://www.salford.ac.uk/media/research/vmpaims.htm To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted:ABC transcription...])
John Chambers wrote: Of course, to be really useful, you'd need more information than is in the R line. I've thought occasionally that it might be interesting to start a discussion of something like a %%MIDI line that gives information about how to adjust the rhythm. Even with hornpipes, this could be useful. Anyone who has played for Irish step dancers knows that hornpipe covers a range of rhythms. You need more info than will comfortably fit in the tune itself, which is why both BarFly and abcMus have a separate file of stress programs which are keyed to the entries in the R: and M: fields. The first hornpipe stress program in the BarFly file looks like this: * 1 % just an ID Hornpipe % the entry in the R: field must match this 4/4 % the entry in the M: field must match this 1/2=90% default tempo (if no Q: field) 8 % divide each bar into eight segments 110 1.4 % first segment, play with velocity 110, length 1.4 x nominal 90 0.6% second segment velocity 90, length 0.6 x nominal 110 1.4 % third, fifth seventh segments same as the first 90 0.6% fourth, sixth and eighth same as the second 110 1.4 90 0.6 110 1.4 90 0.6 Of course this won't work for hornpipes written in broken time, but that's not normally the way they are written. If you want to deal with them you would have to write a separate stress program with hornpipe (broken) in the R: field. There are other hornpipe stress programs for different metres. If you wanted to deal with Johnny Adam's English Stage Hornpipes, you could write one like this: *2 English Stage Hornpipe 6/8% ? 3/8=130% ? 1 100 1.0 which would do absolutely nothing except stop tunes which had English Stage Hornpipe in the R: field being played with any stress at all. You can have as many different stress programs as you want, as long as you can think up a unique name for that genre. Kato rachenitsa is perfectly acceptable, if you can define what it means in terms of length and velocity of notes in different parts of the bar. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
On 13/06/01 at 0.20 John Chambers wrote: Gianni Cunich writes: | Sorry, but I actually got bored about the discussion about the abc2midi behaviour...so bored I actually felt sick! ... | The real problem, IMO, is a totally different one: is there anybody who actually cares about the respect of the standard anymore? I assume the answer is: no... except fot those who actually think to be in charge of its update! Pity the rest of us parias is still waiting for news from the front... Well, I can certainly sympathise. As the one who foisted the abc tune finder on the web, I see an impressive variety of what passes for abc. A number of email exchanges have verified that some people have little if any interest in following any supposed standard. ... I sure do wish we could get abc2win in line with the standard. And that we could get people to stop embedding abc in html. Those two things would solve most of the existing problems with online abc. But I already know the answer to both of those. ... Sorry John, but as have already stated in some private emails - and this, as you know, does not diminish the high esteem I bear to your contribution to the widespread of the abc notation making you tune finder available to the community of the users - I think this is, on your part, pure hypocrisy. In his short history of abc Chris Walshaw was honest enough to admit that: The real explosion in interest came when Jim Vint released his package abc2win in September 1995. The tool was taken up by a large number of the members of IRTRAD-L and abc's of tunes started appearing regularly. As we both know - as anybody else on this list, for the matter! - ABC2WIN is de facto the standard as far as the abc notation is employed on the web, both as far as the mailing list and a number of the abc collections of tunes available for download are concerned. Yet, in your chronology of the abc related software (well.. as far as I can remember, since the link in the abc home page, as I have realized checking it today, now points to your abc notation tutor) actually ABC2WIN wasn't deliberately even mentioned, in pure Big Brother fashion. What are you charging Jim Vint for? Yes, he has derogating the standard ignoring the rule that a line of text means a line of music unless (what a brilliant intuition!) it's too long, and introducing the ! character to force a line break. And so what? That's what any musical typesetting package developer would find sensible, and if abc2mtex (and therefore the original abc standard) would have been written with MusixTex in Chris Walshaw's mind, rather than with MusicTex, that rule wouldn't obviously been part of the standard. And in case someone pretends he doesn't understand the point, what I'm actually stating is that, If we had adopted a line break symbol rather than the inane line of text equal line of music rule, we'd have no reason now to discuss about the problems caused by the unexpected line wrappings produced by some of the email clients... pity the refusal to adopt Jim's sensible choice - that obviously was made as a matter of principle - has led to a number of problems for all the abc notation users! You know, it was like throwing away the baby with the bath water! Anyway, the abc2ps clones introduce a number of other non compliant features, that could be dangerous if there were enough real abc users to employ them, like the ghost rests and the ghost bar lines...I even experienced recently that abcm2ps creates a dotted bar line when it finds a ! character... the problem is that really few people are aware of such obvious pitfalls with the abc native softwares, and the reason is that the diffusion of abc2ps and all its clones put together, compared to the diffusion of ABC2WIn, is in fact irrelevant! Who are you trying to fool, John? Even if we could try to upgrade the abs standard now, it would be too late to persuade the developers that monopolize this list - who actually are those that, not being able to agree about the way to implement quite a number of basic abs extensions that were a vital needing in order to really develop the notation and ensure its growth, are responsible of the actual state of confusion - to make sense of the different options the available software packages offer to solve a number of common problems. Anything that the self appointed, farcical committee actually in charge of update of the standard will be able to do (and considering that they have been working for a few moths, they could easily give up and nobody would even realize they have!) , as far as the real community of the users is concerned, will be too little and too late. Maybe we should call it a day, and think to a brand new ASCII format from scratch - ensuring backward compatibility with the old, all_too_limited, worn out abc standard, of course...- and without regrets! So long Gianni To subscribe/unsubscribe, point your browser
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
On Tue 12 Jun 2001 at 09:29PM +0200, Gianni Cunich wrote: Sorry, but I actually got bored about the discussion about the abc2midi behaviour...so bored I actually felt sick! The problem about the way abc2midi handles the broken rythms shortcut is that it actually playes (and save as midi) any beat using the symbol as a triplet, even if in the R: field you state the tune is a schottische (and English schottisches, at least the oldest ones, are usually played dotted, unlike the recent ones of the hornpipes), or a polka, or anything else... In other terms, the basic thuth is that ac2midi is not an abc compliant software, or, to say better, is unreliable...and that's all we can (and should) say about it! I have to disagree strongly here. My understanding of the ab construct is that it is specially for hornpipes and so you can use it for a 2:1 ratio if that is what you want elsewhere. If you want 3:1, then you can write a3/2b/2. The real culprits are the musicians who have been notating hornpipes in 4/4 when they should have been using 6/8 or 6/16. In other words, you are blaming a piece of software because real musicians have sloppy musical conventions! Remember that abc2midi is intended chiefly to produce playable MIDI files, not for back-conversion into notation programs. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
James == James Allwright [EMAIL PROTECTED] writes: James My understanding of the ab construct is that it is James specially for hornpipes and so you can use it for a 2:1 James ratio if that is what you want elsewhere. If you want 3:1, James then you can write a3/2b/2. The standard says: standard To get shorter notes, either divide them - standard e.g. in 3/4, A/2 is a standard sixteenth note, A/4 is a thirty-second note - or change standard the default note length with the L: field. standard Alternatively, if the music has a broken rhythm, standard e.g. dotted eighth note/sixteenth note pairs, use broken standard rhythm markers (see below). Note that A/ is shorthand standard for A/2. standard Broken rhythms standard == standard A common occurrence in traditional music is the use of a standard dotted or broken rhythm. For example, hornpipes, standard strathspeys and certain morris jigs all have dotted standard eighth notes followed by sixteenth notes as well as standard vice-versa in the case of strathspeys. To support this standard abc notation uses a to mean `the previous note is standard dotted, the next note halved' and to mean `the standard previous note is halved, the next dotted'. Thus the standard following lines all mean the same thing (the third standard version is recommended): standard L:1/16 standard a3b cd3 a2b2c2d2 standard L:1/8 standard a3/2b/2 c/2d3/2 abcd standard L:1/8 standard a b cd abcd I've never seen any documentation anywhere, that suggests that the ab notation is specifically for hornpipes and not for other dotted constructions. And as several people have pointed out, strathspeys and many other dotted constructions are typically played with the dot meaning less time on the shorter note than A or B would imply, not more time as abc2midi is playing it. James Remember that abc2midi is intended chiefly to produce James playable MIDI files, not for back-conversion into notation James programs. And I don't think the abc2midi documentation says this, either. You do document the way you mangle the construction, but this is more than a third of a way down the abcguide.txt file: abcguide Rhythm field and Broken Rhythm Notation abcguide --- abcguide R:hornpipe causes notes written in straight time to be abcguide played in dotted time. The symbol can be used to abcguide achieve a similar effect. abcguide a b is notated as a3/2b/2 but played as a4/3b2/3. abcguide The symbols have similar meanings: I really think the is not special purpose for hornpipes as people actually write ABC; I remember reading that sentence in the standard about it being the preferred construction for dotted rhythms and agreeing that: ab is more readable than: a3/2 b1/2 and always doing it that way. My personal use of MIDI is largely for proofreading, but the reason I put it up on my website is so that other people can use it as a source for back-conversion into other notation programs. I really think there should be an option (preferably the default) that implements the dotted rather than the triplet interpretation of the construction. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (801) 365-6574 233 Broadway, Cambridge, MA 02139 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
I'm assuming your tongue is firmly in cheek here, but a couple of things are useful to mention: - traditional tunes are often notated differently than they are played. Hornpipes are a good example, since they can be written straight and played dotted (Note: I am not talking about abc, just about dots and lines) - the same tune may be played differently in different traditions. Again, a hornpipe may be played dotted in Ireland, and almost indistinguishably from a reel in Cape Breton. - player programs can reproduce the notation exactly, but then it doesn't sound like the tune, so various explicit or implicit stress programs are devised. See BarFly for some nice explicit programs. - MIDI files lose some information in the translation, such as the 'type' of tune (the R: field in abc) which means that a human being must at a minimum interactively put that information back by specifying the stress program to use. By the way, the notation was originally invented to notate strathspeys, not hornpipes (personally I would not use it for hornpipes, but would notate them straight and assume (in my arrogance) that the reader would know how to swing the tune appropriately). As such, it was one of the earliest examples of an extension to notate tunes that were outside the original scope of abc. wil James Allwright wrote: On Tue 12 Jun 2001 at 09:29PM +0200, Gianni Cunich wrote: Sorry, but I actually got bored about the discussion about the abc2midi behaviour...so bored I actually felt sick! The problem about the way abc2midi handles the broken rythms shortcut is that it actually playes (and save as midi) any beat using the symbol as a triplet, even if in the R: field you state the tune is a schottische (and English schottisches, at least the oldest ones, are usually played dotted, unlike the recent ones of the hornpipes), or a polka, or anything else... In other terms, the basic thuth is that ac2midi is not an abc compliant software, or, to say better, is unreliable...and that's all we can (and should) say about it! I have to disagree strongly here. My understanding of the ab construct is that it is specially for hornpipes and so you can use it for a 2:1 ratio if that is what you want elsewhere. If you want 3:1, then you can write a3/2b/2. The real culprits are the musicians who have been notating hornpipes in 4/4 when they should have been using 6/8 or 6/16. In other words, you are blaming a piece of software because real musicians have sloppy musical conventions! Remember that abc2midi is intended chiefly to produce playable MIDI files, not for back-conversion into notation programs. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html -- Wil Macaulay email: [EMAIL PROTECTED] voice: +1-(905)-886-7818 xt2253FAX: +1-(905)-886-7824 Syndesis Ltd. 28 Fulton Way Richmond Hill, Ont Canada L4B 1J5 ... pay no attention to the man behind the curtain ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
On Wed, 13 Jun 2001, James Allwright wrote: I have to disagree strongly here. My understanding of the ab construct is that it is specially for hornpipes and so you can use it for a 2:1 ratio if that is what you want elsewhere. If you want 3:1, then you can write a3/2b/2. My understanding has always been that ab is equivalent to this. The idea that the '' should be peculiar to hornpipes is one I've never come across before, and I don't think it makes much sense. If ab is expected to sound (3a2b, I'd expect to have seen that mentioned in The Standard. The real culprits are the musicians who have been notating hornpipes in 4/4 when they should have been using 6/8 or 6/16. In other words, you are blaming a piece of software because real musicians have sloppy musical conventions! Well, maybe. I remember getting an email from someone remarking that I'd obviously never heard Harvest Home, because I'd written it as even 4/4 quavers, and it's in 6/8. But this _is_ the practice. I'd think an approach like Henriks, reading the R: field for clues on how to mangle the written rhythms, is the right way to handle it (as a musician does, playing from the paper, now I thoink of it). Hornpipe isn't exactly a unitary construct, though, there's a range of different weightings between the notepairs in different sub-styles. -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
Gianni Cunich writes: | Sorry, but I actually got bored about the discussion about the abc2midi |behaviour...so bored I actually felt sick! ... | The real problem, IMO, is a totally different one: is there anybody who actually |cares about the respect of the standard anymore? | | I assume the answer is: no... except fot those who actually think to be in charge of |its update! Pity the rest of us parias is still waiting for news from the front... Well, I can certainly sympathise. As the one who foisted the abc tune finder on the web, I see an impressive variety of what passes for abc. A number of email exchanges have verified that some people have little if any interest in following any supposed standard. Just a few days ago, I was asked why www.irishtunes.net isn't very well represented in the tune finder's indexes. There are actually a few of their files included, but many of them aren't. I spent a fun hour or so just yesterday looking around the site, and was truly impressed by how badly someone can mangle abc, apparently intentionally. It's like they studied a number of abc tools with the goal of producing abc that wouldn't work with any of them. All their tunes are embedded in html, for starters, which accounts for most of the problems. Some of the tunes are double spaced, typically by using p as line separators. Lines are broken in all sorts of weird places, such as within :| and :: symbols. Some is such bizarre html that my poor little parser gives up in bewilderment. And most of the tunes were produced by abc2win, which seems be the current record holder for gratuitous violations of the standard (though it does have some competition for the title). OTOH, there are many good reasons for nonstandard abc. These reasons may be characterised by the term extension. The existing abc standard is rather limited, and a great many musicians have decided that they won't live with the problems. I'm one of the growing crowd that has branched abc2ps so that I can represent music outside the folk tradition of the British Isles. Much as I love that sort of music, I have to admit that abc's limitations make it a poor tool for the other 99% of the world's music, some of which I also like to play. Most of the people making changes aren't actually changing the semantics of abc; they are adding new features to cover music that can't be done right in abc. We aren't going to stop this process. All we can do is try to keep things from diverging, and try to get the extensions implemented more widely. ABC is just too useful, and attracts musicians who learn about it. Then they hit its limitations, and the open source software means they can solve their problems. But the effort to incorporate extensions into a new standard hasn't progressed all that far. The effort so far has been to make a stricter definition of the existing standard. This is itself of much value, of course, and has clarified a lot of ambiguities, but it hasn't yet led to standardizing things outside that standard. Anyhow, as the keeper of the tune finder, what I've been working on in my spare time is to make my abc2ps clone capable of handling as much of the variant abc as I can manage. Most of it seems doable, since few of the extensions are actually in conflict. I haven't made much of a fuss over this; I just find tunes that don't work, I hack up a solution, and a few more tunes now work. Again, the big problem is the abc2win tunes, which are usually not identified as such within the tune, and which do change the semantics of some things. But I've got enough working that when people complain that some file on the web doesn't work, I can often tell them to go to my tune finder and ask it to produce the PS or GIF or whatever, and it usually works. I sure do wish we could get abc2win in line with the standard. And that we could get people to stop embedding abc in html. Those two things would solve most of the existing problems with online abc. But I already know the answer to both of those. (One funny thing is to hear people justifying abc-in-html by saying that HTML is the standard for the Web. How do you argue against such a fundamental misunderstanding? ;-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
