Re: [abcusers] ABC and MusicXML
John Chambers wrote: [...] One of the ongoing challenges with my Tune Finder has been handling ABC embedded inside HTML. This is not a good idea, of course, but you can't stop people from doing it. One of the frequent ways that people do this includes indenting all the ABC to match the indentation of the HTML tags. It looks fine on the screen, because HTML renderers ignore such white space. I've found one site that has all its ABC done this way. (I won't name them, to protect the guilty - and clueless. ;-) Don't protect them. Educate them! ;) -- Bert Van Vreckem http://flanders.blackmill.net/ Te audire non possum. Musa sapientum fixa est in aure. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
Bert Van Vreckem writes: | John Chambers wrote: | [...] One of the ongoing challenges with my Tune Finder has | been handling ABC embedded inside HTML. This is not a good idea, of | course, but you can't stop people from doing it. One of the frequent | ways that people do this includes indenting all the ABC to match the | indentation of the HTML tags. It looks fine on the screen, because | HTML renderers ignore such white space. I've found one site that has | all its ABC done this way. (I won't name them, to protect the guilty | - and clueless. ;-) | | Don't protect them. Educate them! ;) Well, yes and no. When people ask for advice on how to make things work better with tools like mine, I'll make some suggestions. But one of the useful things about the web is that you are free to put your site together however you like, without regard for any stranger's advice on how to do it right. This makes for a bit of a mess, but it also allows people to invent interesting things that wouldn't have ever appeared if we all had to follow someone else's rules. And some people don't want their site indexed by a site like mine. There is even a conventional method (in the robots.txt file) for telling web searchers to stay away, which my search program honors. There's an intermediate level of people who want their sites accessible via browser but not other kinds of web software. I may not like it when people do this, but I have to admit that it's their right to do so. I've seen the this attitude from a number of site owners. A common reaction to suggestions like The ABC tunes inside your web pages are difficult for software to extract is to say All you have to do is cut and paste to your ABC app's window. There's not much you can say in response to this, because it's usually true. And this makes it clear that the person really does want you to do extract the tune by hand, not by using a tool that automates the task. There are also a number of sites whose owners don't want you to download just one tune. This is basically what my Tune Finder does, of course, and I know of a couple of sites that have taken steps to explicitly interfere with this. Again, it's their right to do so. (In a couple of cases, I've given them advice on how to do it. ;-) OTOH, when you put something on the web, it's well within the rights of people like me to attempt to read it and do something useful with it. So sites that do things like putting ABC inside HTML (and maybe indenting it) can be taken as an interesting technical challenge. The growing need to include HTML parsers in every program does make life difficult for software developers, though. Especially when you consider all the bad HTML out there from some of the commercial web site development packages. Your parser has to not just handle standard HTML, but also Microsoft HTML. (Gotta get in the traditional anti-MS bash, y'know. ;-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
I had not considered using separate voicing for chords. Thanks. Regarding lining up barlines... I had thought that spaces in position 0 on a line were illegal. IE, the # here fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| ###d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| Either way, I'm going to use your examples to go back and reformat many tunes. Thanks. //Christian Jack Campin wrote: There's a few things that prove to be making reading ABC on the fly a real difficult task. I wonder what other people feel about my stumbling stones. 1. inline chords. Flotsom floating down midstream making navigation difficult. Yes, better to put them in a separate voice if possible. 2. spacing on either side of barlines... this actually is a very helpful deliniation for me... the problem arises with the numbered repeats |1 and :|2... all the programs I've tried only recognize these 'tokens' provided they do not have those spaces I like so much for readability | 1 aBc aBc :| 2 abc abc | No. Barlines are far less obtrusive if you align your source properly, and taking three characters to express each one can soon run you out of columns in attempting to align a complicated piece. Any readability problem with this? X:1 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| de|f2e2 f2g2|a2ba g2f2|e2b2 b2a2|b2e2 egfe| d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| and if you want repeats, this is more readable than your way, as the [1 notation says clearly what the numeral is for and you only use one way of expressing the repeat boundary rather than two depending on where in the bar the repeat starts: X:2 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2| A4 A2AB|d4 e2de|f2e2 egfe| d2B2 A2F2| A4 A2AB|d4 e2de|f2d2 d2 :| de|f2e2 f2g2| a2ba g2f2|e2b2 b2a2|b2e2 egfe| d2B2 A2F2|[1 A4 A2AB|d4 e2de|f2d2 d2 :| [2 ABAF A2AB|d4 e2de|f2d2 d2 |] Though usually you'd write this instead, making the repeat unit a more meaningful piece of musical structure: X:3 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| de|f2e2 f2g2|a2ba g2f2|e2b2 b2a2|b2e2 egfe| [1 d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| [2 d2B2 A2F2|ABAF A2AB|d4 e2de|f2d2 d2 |] And it's usually easier to find a reasonable staff notation layout for 20 bars than is for 19, e.g,. for five bars to a line: X:4 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2| A4 A2AB| d4 e2de| f2e2 egfe|\ d2B2 A2F2|!A4 A2AB| d4 e2de| f2d2 d2 :|\ de|f2e2 f2g2| a2ba g2f2|!e2b2 b2a2| b2e2 egfe|\ [1 d2B2 A2F2| A4 A2AB| d4 e2de|!f2d2 d2 :|\ [2 d2B2 A2F2| ABAF A2AB| d4 e2de| f2d2 d2 |] - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html -- //Christian Christian Marcus Cepel| And the wrens have returned [EMAIL PROTECTED] icq:12384980 | are nesting; In the hollow of 371 Crown Point, Columbia, MO | that oak where his heart once 65203-2202 573.999.2370 | had been; And he lifts up his Computer Support Specialist, Sr. | arms in a blessing; For being University of Missouri - Columbia | born again.--Rich Mullins To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
What? No xhtml compliance? p / John Chambers wrote: html Neil Jennings writes: blockquote MusicXML is plain text, just as all the markup languages are, but that doesn't mean you don't have to decode it. Can you decode even simple HTML by just reading it?. MusicXML needs to be read along with the DTD. /blockquote p Well, yes, that's technically true. HTML was intended to be a simple, unobtrusive markup that wouldn't interfere with readability. I like to illustrate this by adding HTML to my message, which I'll do now . p But most of the HTML you see in email is utterly unreadable by the typical human. We can expect that most MusicXML will be similar computer gibberish. Neither could be remotely called plain text. p Of course, it's easy to find ABC that's nearly as unreadable. p (Maybe we should refer ABC newbies to Jack Campin for lessons in making readable ABC. ;-) p I hope the list server doesn't strip out this HTML ... /html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html -- //Christian Christian Marcus Cepel| And the wrens have returned [EMAIL PROTECTED] icq:12384980 | are nesting; In the hollow of 371 Crown Point, Columbia, MO | that oak where his heart once 65203-2202 573.999.2370 | had been; And he lifts up his Computer Support Specialist, Sr. | arms in a blessing; For being University of Missouri - Columbia | born again.--Rich Mullins To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
Christian M. Cepel writes: | What? No xhtml compliance? | p / Nah; HTML 0.9. ;-) | John Chambers wrote: | | html |Neil Jennings writes: |blockquote | MusicXML is plain text, just as all the markup languages are, but that | doesn't mean you don't have to decode it. | Can you decode even simple HTML by just reading it?. | MusicXML needs to be read along with the DTD. |/blockquote | p |Well, yes, that's technically true. HTML was intended to be a |simple, unobtrusive markup that wouldn't interfere with readability. |I like to illustrate this by adding HTML to my message, which I'll |do now . | p |But most of the HTML you see in email is utterly unreadable by the |typical human. We can expect that most MusicXML will be similar |computer gibberish. Neither could be remotely called plain text. | p |Of course, it's easy to find ABC that's nearly as unreadable. | p |(Maybe we should refer ABC newbies to Jack Campin for lessons in |making readable ABC. ;-) | p |I hope the list server doesn't strip out this HTML ... | /html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
Regarding lining up barlines... I had thought that spaces in position 0 on a line were illegal. IE, the # here fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| ###d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| No, they're fine by all standards since 1.5 at least - nor, as far as I know, has any ABC software ever had a problem with them in practice. - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 6 Apr 2004, at 21:10, Jack Campin wrote: Regarding lining up barlines... I had thought that spaces in position 0 on a line were illegal. IE, the # here fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| ###d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| No, they're fine by all standards since 1.5 at least - nor, as far as I know, has any ABC software ever had a problem with them in practice. Provided, that is that the line doesn't start with a field letter. A space before a non-inline field is illegal. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
Phil Taylor writes: | On 6 Apr 2004, at 21:10, Jack Campin wrote: | | Regarding lining up barlines... I had thought that spaces in | position 0 | on a line were illegal. | IE, the # here | | fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| | ###d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| | | No, they're fine by all standards since 1.5 at least - nor, as far as | I know, has any ABC software ever had a problem with them in practice. | | Provided, that is that the line doesn't start with a field letter. A | space before a non-inline field is illegal. Funny thing is that I've been lately working on handling ABC that does just this. One of the ongoing challenges with my Tune Finder has been handling ABC embedded inside HTML. This is not a good idea, of course, but you can't stop people from doing it. One of the frequent ways that people do this includes indenting all the ABC to match the indentation of the HTML tags. It looks fine on the screen, because HTML renderers ignore such white space. I've found one site that has all its ABC done this way. (I won't name them, to protect the guilty - and clueless. ;-) My situation right now is that there are some such tunes that my search bot can recognize, but they aren't always recognized by the code that the Finder uses to extract a tune from a page. So you can see a tune listed, and then when you try to get it, you're told that it's not there. This web stuff isn't always easy. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
There's a few things that prove to be making reading ABC on the fly a real difficult task. I wonder what other people feel about my stumbling stones. 1. inline chords. Flotsom floating down midstream making navigation difficult. Yes, better to put them in a separate voice if possible. 2. spacing on either side of barlines... this actually is a very helpful deliniation for me... the problem arises with the numbered repeats |1 and :|2... all the programs I've tried only recognize these 'tokens' provided they do not have those spaces I like so much for readability | 1 aBc aBc :| 2 abc abc | No. Barlines are far less obtrusive if you align your source properly, and taking three characters to express each one can soon run you out of columns in attempting to align a complicated piece. Any readability problem with this? X:1 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| de|f2e2 f2g2|a2ba g2f2|e2b2 b2a2|b2e2 egfe| d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| and if you want repeats, this is more readable than your way, as the [1 notation says clearly what the numeral is for and you only use one way of expressing the repeat boundary rather than two depending on where in the bar the repeat starts: X:2 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2| A4 A2AB|d4 e2de|f2e2 egfe| d2B2 A2F2| A4 A2AB|d4 e2de|f2d2 d2 :| de|f2e2 f2g2| a2ba g2f2|e2b2 b2a2|b2e2 egfe| d2B2 A2F2|[1 A4 A2AB|d4 e2de|f2d2 d2 :| [2 ABAF A2AB|d4 e2de|f2d2 d2 |] Though usually you'd write this instead, making the repeat unit a more meaningful piece of musical structure: X:3 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| de|f2e2 f2g2|a2ba g2f2|e2b2 b2a2|b2e2 egfe| [1 d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| [2 d2B2 A2F2|ABAF A2AB|d4 e2de|f2d2 d2 |] And it's usually easier to find a reasonable staff notation layout for 20 bars than is for 19, e.g,. for five bars to a line: X:4 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2| A4 A2AB| d4 e2de| f2e2 egfe|\ d2B2 A2F2|!A4 A2AB| d4 e2de| f2d2 d2 :|\ de|f2e2 f2g2| a2ba g2f2|!e2b2 b2a2| b2e2 egfe|\ [1 d2B2 A2F2| A4 A2AB| d4 e2de|!f2d2 d2 :|\ [2 d2B2 A2F2| ABAF A2AB| d4 e2de| f2d2 d2 |] - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
P J Headford comments: | Just a reminder ... | ABC is not just a computer thing. | I know quite a few musicians who can play you the tune from the ABC | notation. This is worth repeating periodically as a reminder of one of ABC's main features. One example from last year: I got email from someone saying that their daughter wanted to learn a tune for a musical contest, and it was available online, but they were having problems getting software to convert it to readable music. I recommended that she learn to read the ABC directly, and sent a brief description of how ABC works. A day or so later, I got another message saying that she had learned the tune from the ABC and was busy practicing. One of the benefits of any plain-text data format is that you don't necessarily need any fancy tools to read it. Plain text does work against the fancy formatting, fonts, etc. that you can get with more complex tools. But if you just want the information, plain text can be a lot better than the fancier formats. Of course, there's a lot of ABC that's poorly formatted and difficult to read, justasreadingruntogetherEnglishtextwouldbe. But that's not a problem with ABC itself. | Also, when I'm in a session and someone plays a tune I'd like to remember, | I can simply note down the first few bars in ABC more quickly (and more | legibly) in ABC than stave notation. If you look up Chris Walshaw's story on how he invented ABC, you'll see that this was exactly where he started. He was familiar with TeX and MusicTeX, and it occurred to him that a simple translator could turn his alphabetic notation into music notation. The result was abc2mtex. But the original form of ABC was handwritten music. | From what is being said on the list, I gather MusicXML would not have this | interface to the real world. MusicXML is intended as a computer-friendly music notation. It's not at all a replacement or competitor for ABC. The advent of powerful word processor software hasn't eliminated the usefulness of plain-text documents, and it's likely that ABC will continue to be used despite all the powerful music software that's being developed. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On Thu, Apr 01, 2004 at 03:33:01PM +, John Chambers wrote: P J Headford comments: | Just a reminder ... | ABC is not just a computer thing. This is worth repeating periodically as a reminder of one of ABC's main features One of the benefits of any plain-text data format is that you don't necessarily need any fancy tools to read it. Plain text does work against the fancy formatting, fonts, etc. that you can get with more complex tools. But if you just want the information, plain text can be a lot better than the fancier formats. | From what is being said on the list, I gather MusicXML would not have this | interface to the real world. MusicXML is intended as a computer-friendly music notation. It's not at all a replacement or competitor for ABC. But it's still plaintext ? You could read it if you had to, but no-one here would want to (by definition. It's an ABC list). Myself included. Verbosity is not considered a drawback they say. Not what we want. As the starter of this thread, I can only point out that I wasn't proposing MusicXML as a competitor or a replacement for ABC, I was proposing it as a complement. ABC is nicer for humans, xml is nicer for machines. Since we do hand our tunes over to computers to do things with, as well as writing them on the backs of envelopes, some things might be nicer for them to do in xml, if we could get the ABC back from it next time we want to interact with it directly. Though, having gone further into investigating this, I'm getting my original enthusiasm into perspective grin. XSLT makes it _really_ easy to parse notes (or anything else) out of musicxml, which is the tricky bit for abc. But having done that, it's not easy to see what you can do with it. Have W3C really given us a toy language with next to no storage ? The only variable type is a scalar, and they can only be assiged to on creation; nor can functions return values. Odd. I think I must be missing some sort of mindset thing. -- 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 and MusicXML
MusicXML is plain text, just as all the markup languages are, but that doesn't mean you don't have to decode it. Can you decode even simple HTML by just reading it?. MusicXML needs to be read along with the DTD. (By the way, I am slowly adding MusicXML export to HARMONY) Neil At 05:05 PM 4/1/04, you wrote: On Thu, Apr 01, 2004 at 03:33:01PM +, John Chambers wrote: P J Headford comments: | Just a reminder ... | ABC is not just a computer thing. This is worth repeating periodically as a reminder of one of ABC's main features One of the benefits of any plain-text data format is that you don't necessarily need any fancy tools to read it. Plain text does work against the fancy formatting, fonts, etc. that you can get with more complex tools. But if you just want the information, plain text can be a lot better than the fancier formats. | From what is being said on the list, I gather MusicXML would not have this | interface to the real world. MusicXML is intended as a computer-friendly music notation. It's not at all a replacement or competitor for ABC. But it's still plaintext ? You could read it if you had to, but no-one here would want to (by definition. It's an ABC list). Myself included. Verbosity is not considered a drawback they say. Not what we want. As the starter of this thread, I can only point out that I wasn't proposing MusicXML as a competitor or a replacement for ABC, I was proposing it as a complement. ABC is nicer for humans, xml is nicer for machines. Since we do hand our tunes over to computers to do things with, as well as writing them on the backs of envelopes, some things might be nicer for them to do in xml, if we could get the ABC back from it next time we want to interact with it directly. Though, having gone further into investigating this, I'm getting my original enthusiasm into perspective grin. XSLT makes it _really_ easy to parse notes (or anything else) out of musicxml, which is the tricky bit for abc. But having done that, it's not easy to see what you can do with it. Have W3C really given us a toy language with next to no storage ? The only variable type is a scalar, and they can only be assiged to on creation; nor can functions return values. Odd. I think I must be missing some sort of mindset thing. -- 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 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On Thu, Apr 01, 2004 at 06:20:00PM +0100, Neil Jennings wrote: MusicXML is plain text, just as all the markup languages are, but that doesn't mean you don't have to decode it. Can you decode even simple HTML by just reading it?. Sure. Anything can be made hard to read if you have a machine generate it, even ABC. But things are usually easier to read if they're written by hand - html is, for certain. MusicXML needs to be read along with the DTD. ?? Try looking inside one, it's not often hard to see what things mean. -- 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 and MusicXML
html Neil Jennings writes: blockquote MusicXML is plain text, just as all the markup languages are, but that doesn't mean you don't have to decode it. Can you decode even simple HTML by just reading it?. MusicXML needs to be read along with the DTD. /blockquote p Well, yes, that's technically true. HTML was intended to be a simple, unobtrusive markup that wouldn't interfere with readability. I like to illustrate this by adding HTML to my message, which I'll do now . p But most of the HTML you see in email is utterly unreadable by the typical human. We can expect that most MusicXML will be similar computer gibberish. Neither could be remotely called plain text. p Of course, it's easy to find ABC that's nearly as unreadable. p (Maybe we should refer ABC newbies to Jack Campin for lessons in making readable ABC. ;-) p I hope the list server doesn't strip out this HTML ... /html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 1 Apr 2004, at 18:39, Richard Robinson wrote: On Thu, Apr 01, 2004 at 06:20:00PM +0100, Neil Jennings wrote: MusicXML is plain text, just as all the markup languages are, but that doesn't mean you don't have to decode it. Can you decode even simple HTML by just reading it?. Sure. Anything can be made hard to read if you have a machine generate it, even ABC. But things are usually easier to read if they're written by hand - html is, for certain. MusicXML needs to be read along with the DTD. ?? Try looking inside one, it's not often hard to see what things mean. No, it's not difficult to understand, in fact you can pretty much guess what most of it means, since everything is labelled. The problem is the sheer volume of text you have to wade through. In abc, each note occupies one or two characters, in MusicXML it occupies half a page. A page of music in MusicXML can take up 100K of text. I found it very difficult to debug my software because I was spending most of my time wading through the MusicXML source looking for the specific construct that was causing the problem. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
With this in mind, I've been struggleing while editing ABC lately. I'm not real good at reading music or ABC on the fly due to learing disability (latent cognition between reading and comprehending). There's a few things that prove to be making reading ABC on the fly a real difficult task. I wonder what other people feel about my stumbling stones. 1. inline chords. Flotsom floating down midstream making navigation difficult. 2. spacing on either side of barlines... this actually is a very helpful deliniation for me... the problem arises with the numbered repeats |1 and :|2... all the programs I've tried only recognize these 'tokens' provided they do not have those spaces I like so much for readability | 1 aBc aBc :| 2 abc abc | anyone else struggle with these? P J Headford comments: | Just a reminder ... | ABC is not just a computer thing. | I know quite a few musicians who can play you the tune from the ABC | notation. This is worth repeating periodically as a reminder of one of ABC's main features. One example from last year: I got email from someone saying that their daughter wanted to learn a tune for a musical contest, and it was available online, but they were having problems getting software to convert it to readable music. I recommended that she learn to read the ABC directly, and sent a brief description of how ABC works. A day or so later, I got another message saying that she had learned the tune from the ABC and was busy practicing. One of the benefits of any plain-text data format is that you don't necessarily need any fancy tools to read it. Plain text does work against the fancy formatting, fonts, etc. that you can get with more complex tools. But if you just want the information, plain text can be a lot better than the fancier formats. Of course, there's a lot of ABC that's poorly formatted and difficult to read, justasreadingruntogetherEnglishtextwouldbe. But that's not a problem with ABC itself. | Also, when I'm in a session and someone plays a tune I'd like to remember, | I can simply note down the first few bars in ABC more quickly (and more | legibly) in ABC than stave notation. If you look up Chris Walshaw's story on how he invented ABC, you'll see that this was exactly where he started. He was familiar with TeX and MusicTeX, and it occurred to him that a simple translator could turn his alphabetic notation into music notation. The result was abc2mtex. But the original form of ABC was handwritten music. | From what is being said on the list, I gather MusicXML would not have this | interface to the real world. MusicXML is intended as a computer-friendly music notation. It's not at all a replacement or competitor for ABC. The advent of powerful word processor software hasn't eliminated the usefulness of plain-text documents, and it's likely that ABC will continue to be used despite all the powerful music software that's being developed. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html -- Christian Marcus Cepel | And the wrens have returned [EMAIL PROTECTED] icq:12384980 | are nesting; In the hollow of 371 Crown Point, Columbia, MO | that oak where his heart once 65203-2202 573.999.2370 | had been; And he lifts up his Computer Support Specialist, Sr. | arms in a blessing; For being University of Missouri - Columbia | born again. --Rich Mullins To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 1 Apr 2004, at 22:19, Christian M. Cepel wrote: With this in mind, I've been struggleing while editing ABC lately. I'm not real good at reading music or ABC on the fly due to learing disability (latent cognition between reading and comprehending). There's a few things that prove to be making reading ABC on the fly a real difficult task. I wonder what other people feel about my stumbling stones. 1. inline chords. Flotsom floating down midstream making navigation difficult. You mean guitar chords? I agree with you. They do interrupt the flow of information. 2. spacing on either side of barlines... this actually is a very helpful deliniation for me... the problem arises with the numbered repeats |1 and :|2... all the programs I've tried only recognize these 'tokens' provided they do not have those spaces I like so much for readability | 1 aBc aBc :| 2 abc abc | Yes. Bar lines are much more visible when they have spaces on either side. I don't have much problem with the numbered repeats though. You can, of course write them as | [1 aBc aBc :| [2 if you really need the space here. (The programs are correct to object to | 1 aBc aBc :| 2 abc abc |, since that's specifically declared illegal in the standard.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
From: Richard Robinson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 25, 2004 9:01 PM Subject: [abcusers] ABC and MusicXML Is anybody else here looking much at MusicXML ? I've been having a look over the last few days, and I must say, I'm rather impressed. It seems to me that this could all be tremendously useful to us, as ABC users. Starting from the position that as far as our site is concerned, abc's importance lies more in a simple storage method and having nice programs to produce graphics and MIDI than in human readability of abc. (perhaps John Chambers for example to confirm or deny this... Do most casual visitors to a site want a MIDI to play back or a GIF or to download the abc itself for a tune?).. If there were abc2MusicXML and MusicXML2abc converters, would it possible to produce abc that always conformed to the same set of abc rules? One problem I have that has been commented on by Jack Campin for one is that our abc is not always as clear to read as it could be. I agree with that but on the otherhand, on a site stuggling to get any contributers, the last thing I want to do is stipulate rules as to how the abc should be written (especially given our main aims above - that it works on abcm2ps and abc2midi is the priority... but it would be nice to improve in our abc for those who want to read it) or even what software should be used (e.g. our main contributer uses Harmony Assistant) as the tougher I make it, the fewer will be willing to try. A big problem with abc for me is the multiple ways abc has of doing the same thing, e.g. broken notation vs explicit note lengths, the ability to write 3/2 or 3/, etc. particularly when not everyone [and that pretty much includes me because of music reading difficulties] can use abc directly.) Also, if other programs can export XML directly, I guess that will help to if we can produce abc from that? Jon To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
as far as our site is concerned, abc's importance lies more in a simple storage method and having nice programs to produce graphics and MIDI than in human readability of abc. (perhaps John Chambers for example to confirm or deny this... Do most casual visitors to a site want a MIDI to play back or a GIF or to download the abc itself for a tune?).. Most people want GIFs. But if they're going to do it on their own machines, rather than via the TuneFinder interface, the ABC better be straightforward and easily editable, since the usual reason for wanting a different score than the way it comes off the Web is if you want to change the notes themselves in some way. If there were abc2MusicXML and MusicXML2abc converters, would it possible to produce abc that always conformed to the same set of abc rules? It would be, but it would throw away many of the distinctive things ABC can express. For eample, look at the pibroch example in my modes tutorial. I put the canntaireachd form of the music at the right margin as an ABC comment (it would be messy to include it as if it were a song text). Unless your ABC - XML translator retained the original ABC source, there'd be no way to recover that information after a round-trip translation. What I've done there is perfectly standard and works in any reasonable ABC implementation, but it's not invariant under translation to anything else whatever. One problem I have that has been commented on by Jack Campin for one is that our abc is not always as clear to read as it could be. I agree with that but on the otherhand, on a site stuggling to get any contributers, the last thing I want to do is stipulate rules as to how the abc should be written (especially given our main aims above - that it works on abcm2ps and abc2midi is the priority... but it would be nice to improve in our abc for those who want to read it) or even what software should be used (e.g. our main contributer uses Harmony Assistant) as the tougher I make it, the fewer will be willing to try. The answer to that one is a human editor. How much is there on your site? Maybe I could help if it isn't going to mean hours of connect time link-hopping. A big problem with abc for me is the multiple ways abc has of doing the same thing, e.g. broken notation vs explicit note lengths, the ability to write 3/2 or 3/, etc. particularly when not everyone [and that pretty much includes me because of music reading difficulties] can use abc directly.) It needs to be like that to handle different kinds of music. Default note length is the one that makes the largest difference - for songs, you usually get the most readable source by making it 1/4, whereas for 2/4 pipe marches it's usually 1/16, and the default is in between. No way round that, there really are different numbers of notes per bar in each, and if you pick the wrong one you will reduce readability by introducing superfluous numerals or /'s. (Bruce Olson made a very bad decision of this type; his default length is twice what it should be, so nearly every note on his site has a /2 associated with it). Also, if other programs can export XML directly, I guess that will help to if we can produce abc from that? Only given a *very* sophisticated translator. Why use ABC as an intermediate format if you aren't using its distinctive advantages? As a base for computer-translation-to-anything, XML is surely going to outdo ABC as its toolbase grows. ABC only wins out when you need to tinker with the music yourself, and that needs readability. - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
Jack == Jack Campin [EMAIL PROTECTED] writes: Jack It would be, but it would throw away many of the distinctive Jack things ABC can express. For eample, look at the pibroch Jack example in my modes tutorial. I put the canntaireachd form Jack of the music at the right margin as an ABC comment (it would Jack be messy to include it as if it were a song text). Unless Jack your ABC - XML translator retained the original ABC source, Jack there'd be no way to recover that information after a Jack round-trip translation. What I've done there is perfectly Jack standard and works in any reasonable ABC implementation, but Jack it's not invariant under translation to anything else Jack whatever. The only translator I know at all well is the abc to lilypond one, and it retains ABC comments as lilypond comments. Wouldn't that be a standard thing for any translator to do? -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (501) 641-5011 233 Broadway, Cambridge, MA 02139 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On Sat, Mar 27, 2004 at 05:17:14PM +, Jack Campin wrote: as far as our site is concerned, abc's importance lies more in a simple storage method and having nice programs to produce graphics and MIDI than in human readability of abc. (perhaps John Chambers for example to confirm or deny this... Do most casual visitors to a site want a MIDI to play back or a GIF or to download the abc itself for a tune?).. Most people want GIFs. But if they're going to do it on their own machines, rather than via the TuneFinder interface, the ABC better be straightforward and easily editable, since the usual reason for wanting a different score than the way it comes off the Web is if you want to change the notes themselves in some way. Or, maybe, to print ? web-gifs aren't normally (sensibly) at a decent resolution for that. Though I know I've seen a lot of 72dpi screen-dumps ... If there were abc2MusicXML and MusicXML2abc converters, would it possible to produce abc that always conformed to the same set of abc rules? It would be, but it would throw away many of the distinctive things ABC can express. For eample, look at the pibroch example in my modes tutorial. I put the canntaireachd form of the music at the right margin as an ABC comment (it would be messy to include it as if it were a song text). Unless your ABC - XML translator retained the original ABC source, there'd be no way to recover that information after a round-trip translation. What I've done there is perfectly standard and works in any reasonable ABC implementation, but it's not invariant under translation to anything else whatever. Also, if other programs can export XML directly, I guess that will help to if we can produce abc from that? Only given a *very* sophisticated translator. Why use ABC as an intermediate format if you aren't using its distinctive advantages? As a base for computer-translation-to-anything, XML is surely going to outdo ABC as its toolbase grows. ABC only wins out when you need to tinker with the music yourself, and that needs readability. That's the way I see it, yes. If it catches on. ABC for people to interact with, xml where machines are dealing with it (possibly up to and including transferring it from one system to anoter), and storage could be either depending on which of those 2 you're most interested in. Depending on, as you say, sophisticated translation. There are several different dialects of ABC - defined, on the ground, by the parsers that people use, which ABC program they're feeding it into (plus comments, layout, etc, intended for the direct benefit of humans, so far as it can be shoehorned in). Neatest here would be if the abc parsers came to feel it was worth their while to translate the ABC that they can parse into xml - rather than trying to build a one-program-fits-all universal abc-xml translator that understands everything about all dialects. The reverse translation, back into ABC - some programs are already importing xml, presumably they generate ABC tailored to suit whichever parser, style of ABC, that program uses. In the long run, we might have .xls stylesheets independent of any particular ABC parser (decent ones, I mean) - these might become a central point for bug reports, wherever they generate ABC of a style that doesn't work as input to a particular parser, in which case they could (presumably) be tweaked till they generate your particular choice of dialect. In, as I say, the long run; that's not the case yet. The question that gets raised at this point, which I don't know the answer to, is - how easy is it to translate abc to xml ? How well does xml accomodate the concepts of ABC, how much of the possible information in an ABC file does MusicXML have encodings for ? So far as there are things in an ABC file that MusicXML can't represent, we'd have to invent some way of wrapping them up in comments, or something - find a way of shoehorning it into ABC - in a way that xml-abc translators could recognise, preferrably a way generally agreed upon (rather than carry the issue of dialects across to our generated XML). (A further question here; are there descriptions of MusicXML anywhere ? I have Recordare's Tutorial (V1.0), and I know the DTDs give all the sordid details, but they're a bit bulky for a beginner to find their way around). And, yes, I guess that points of formatting would the trickiest to preserve, recording whitespace between ABC elements, comments and so on. Not impossible, but I can imagine a temptation to cut corners in the coding. Easy to test, of course. Take an ABC file, translate to MusicXML, translate back to ABC, and keep on sending in bug reports until the 2 abc files match up ;-) And vice versa ... I imagine the reverse case would be harder, preserving all xml information that ABC doesn't represent inside an ABC file for xml-abc-xml. -- Richard Robinson The whole plan hinged upon the natural
Re: [abcusers] ABC and MusicXML
- Original Message - From: Jack Campin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 27, 2004 5:17 PM Subject: Re: [abcusers] ABC and MusicXML Most people want GIFs. But if they're going to do it on their own machines, rather than via the TuneFinder interface, the ABC better be straightforward and easily editable, since the usual reason for wanting a different score than the way it comes off the Web is if you want to change the notes themselves in some way. OK, for the sake or argument, how about pdf? We try to make a png available (instead of the gif) as a draft and try to produce the other for quality print output. An example, probably given before here is: http://www.folkinfo.org/abctest/getpdf.php?SongID=2paper=a4 If there were abc2MusicXML and MusicXML2abc converters, would it possible to produce abc that always conformed to the same set of abc rules? It would be, but it would throw away many of the distinctive things ABC can express. For eample, look at the pibroch example in my modes tutorial. I put the canntaireachd form of the music at the right margin as an ABC comment (it would be messy to include it as if it were a song text). Unless your ABC - XML translator retained the original ABC source, there'd be no way to recover that information after a round-trip translation. What I've done there is perfectly standard and works in any reasonable ABC implementation, but it's not invariant under translation to anything else whatever. The inability to recover that information would be what I want but, yes, I do see it is important that abc can be entered and used in other ways. One problem I have that has been commented on by Jack Campin for one is that our abc is not always as clear to read as it could be. I agree with that but on the otherhand, on a site stuggling to get any contributers, the last thing I want to do is stipulate rules as to how the abc should be written (especially given our main aims above - that it works on abcm2ps and abc2midi is the priority... but it would be nice to improve in our abc for those who want to read it) or even what software should be used (e.g. our main contributer uses Harmony Assistant) as the tougher I make it, the fewer will be willing to try. The answer to that one is a human editor. How much is there on your site? Maybe I could help if it isn't going to mean hours of connect time link-hopping. Feel free to take a look. I've been promising to sort out long line abcs for ages for example but never got round to it mainly as I know how long it would take me... Everything as entered in abc form can be found at: http://www.folkinfo.org/songs/allabc.asp It's only a few 100K and 500 songs. You may need to change the file type or an extension on the download to get it to save or view. Only given a *very* sophisticated translator. Why use ABC as an intermediate format if you aren't using its distinctive advantages? As a base for computer-translation-to-anything, XML is surely going to outdo ABC as its toolbase grows. ABC only wins out when you need to tinker with the music yourself, and that needs readability. The distinctive advantages to me are that it is very easy to store and makes for a small compact file and that quality and reliable command line tools such as abcm2ps I can run on the fly from the website (as well of course as other good abc programs) exist. Maybe one day perhaps a move to XML would make sense for me, but not yet and when I started, I was quite keen to get out of the dt/mudcat songwright/midi to hold songs thinking. One thing I will openly confess to is that I hadn't realised how much there was to abc and the visual aspects. Also, whatever we become (assuming we last as a site), I'd like to think we can at least supply abc in a visual user friendly format in time. Jon To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 27 Mar 2004, at 18:53, Richard Robinson wrote: The question that gets raised at this point, which I don't know the answer to, is - how easy is it to translate abc to xml ? How well does xml accomodate the concepts of ABC, how much of the possible information in an ABC file does MusicXML have encodings for ? So far as there are things in an ABC file that MusicXML can't represent, we'd have to invent some way of wrapping them up in comments, or something - find a way of shoehorning it into ABC - in a way that xml-abc translators could recognise, preferrably a way generally agreed upon (rather than carry the issue of dialects across to our generated XML). MusicXML is a very comprehensive music description language. For example, it is possible to include in a MusicXML file both the information to construct the staff notation, and that needed to construct a midi file. These are fairly independent of one another, so you can specify e.g. a mordent to be printed, but the notes which correspond to be played. The only feature I can think of which is present in abc but not MusicXML is the bagpipe key signatures. So abc - MusicXML is relatively easy. The reverse translation is much more difficult. (e.g. MusicXML permits multiple voices within the same part, so in a piano part, which may include four or more voices, each bar has several backup tags to allow the different voices to coexist. The voices can move independently across staves, change clefs and so on, and there's no way to do that in abc.) (A further question here; are there descriptions of MusicXML anywhere ? I have Recordare's Tutorial (V1.0), and I know the DTDs give all the sordid details, but they're a bit bulky for a beginner to find their way around). I think that's all there is. There is also a MusicXML mailing list, which is quite active, and is usually the best place to go to ask questions. And, yes, I guess that points of formatting would the trickiest to preserve, recording whitespace between ABC elements, comments and so on. Not impossible, but I can imagine a temptation to cut corners in the coding. Yes, whitespace which doesn't convey any information (as opposed to that which determines beaming) would be very hard to preserve. Since MusicXML is not intended to be read by humans, comments in the source would be useless, so abc comments would have to be preserved differently. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
--On Thursday, March 25, 2004 5:08 PM -0500 Jeff Szuhay [EMAIL PROTECTED] wrote: Try looking at LilyPond. Their is also Pmw which produces some beautiful music. A Win32 release is going to be available in a few days also. http://www.quercite.com/pmw.html Jeremy To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On Fri, 26 Mar 2004, Phil Taylor wrote: On 25 Mar 2004, at 22:14, I. Oppenheim wrote: Are many ABC programs currently capable of generating MusicXML ? There's a command-line Windows/Linux abc2xml There's also BarFly (Mac) and Noteedit (Linux). At the moment, BarFly only imports MusicXML. Export is still to come. I really don't know why I announce the newest version of NoteEdit (http://rnvs.informatik.tu-chemnitz.de/~jan/noteedit/noteedit.html) to this list. Again: NoteEdit is able to: - import MusicXML - export MusicXML - export ABC music, thus converting MusicXML to ABC music and ... On Thu, 25 Mar 2004, Jeff Szuhay wrote: Try looking at LilyPond. export LilyPond, thus converting MusicXML to LilyPond (BTW: and export MusiXTeX and PMX and implicitely MUP) NoteEdit-2.5.2. which comes soon can even export/import guitar chord diagrams from/to MusicXML and export to ABC music. Please have a look at: http://rnvs.informatik.tu-chemnitz.de/MXML/mxml.html There you find: - Your original files file1.xml, file2.xml, and file3.xml. - The NoteEdit files made by importing file1.xml, file2.xml, and file3.xml. - The ABC music files, made by NoteEdit's ABC music exporter, - The Postscript files made by abcm2ps (http://moinejf.free.fr), - The LilyPond files made by NoteEdit's LilyPond exporter - and the scores as image, again the abcm2ps output. Ok, NoteEdit is not prepared to import File Four. This is outside of NoteEdit's scope. -- J.Anders, Chemnitz, GERMANY ([EMAIL PROTECTED]) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On Thu, Mar 25, 2004 at 11:14:45PM +0100, I. Oppenheim wrote: On Thu, 25 Mar 2004, Richard Robinson wrote: I concur: musicxml is a wondeful development, which will finally make it feasible to exchange scores between different music processing software, without loosing too much information. http://www.qualmograph.org.uk/musicxml/ There's a small error in the example files on your webpage: the DOCTYPE tags refer to local file:// URLS, which won't work on other computers. That's be the file:/c:/Program Files/MusicXML/partwise.dtd bit ? It doesn't work on mine, either. But it doesn't seem to stop things doing what they should - perhaps because I have a permanent net onnection so the external DTD reference can be used. Did it stop you being abe to use/render the files ? My processor also seems able to process without validation, which seems to stop it trying to use either (so the complaints go away). I did say the converter I'm using isn't perfect. But from the responses so far, it seems to be the only one. That's disappointing. -- 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 and MusicXML
On 26 Mar 2004, at 16:23, Richard Robinson wrote: There's a small error in the example files on your webpage: the DOCTYPE tags refer to local file:// URLS, which won't work on other computers. That's be the file:/c:/Program Files/MusicXML/partwise.dtd bit ? It doesn't work on mine, either. But it doesn't seem to stop things doing what they should - perhaps because I have a permanent net onnection so the external DTD reference can be used. Did it stop you being abe to use/render the files ? My processor also seems able to process without validation, which seems to stop it trying to use either (so the complaints go away). I did say the converter I'm using isn't perfect. But from the responses so far, it seems to be the only one. That's disappointing. You haven't actually included the external DTD reference. In place of the file:/c:/Program Files/MusicXML/partwise.dtd you should use http://www.musicxml.org/dtds/partwise.dtd;, then it should work for anybody who has an internet connection. The original file:// specification will only work if you happen to have a disk named c with the appropriate file on it. Tried it on my Mac with three different browsers: Internet Explorer objected to that file reference; if I download the file and change it as above, IE downloads all the DTDs, but then just displays the source. Safari gave this, so it's clearly trying: the Female Rake abc2xml 2004-03-23 Richard Robinson URL:http://www.leeds.ac.uk/music/Info/RRTuneBk/contact.html Jig England 960 2 major 6 8 G 2 A 4 480 eighth D 5 480 eighth begin etc. iCab opened the source. You can, of course download the source and import it with BarFly, but I noticed a snag here too. Safari downloads the file as untyped, and BarFly won't recognise it as a text file. Curiously, if you change the file extension to .txt it works fine. (One more little thing to fix.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On Thu, Mar 25, 2004 at 10:24:58PM +, Bernard Hill wrote: In message [EMAIL PROTECTED], Richard Robinson [EMAIL PROTECTED] writes Is anybody else here looking much at MusicXML ? I've been having a look over the last few days, and I must say, I'm rather impressed. It seems to me that this could all be tremendously useful to us, as ABC users. Why? It doesn't have the ability to write your own, and isn't a format you could play from as ABC is on both counts. Not sure what you mean ? Write your own - if you mean convert from abc, no it seems we can't do much of that, yet. But write directly in a text editor, you could do that. I doubt if anyone would want to, given ABC, which is nicer. Play from - you mean to look at directly ? Likewise (if you were using, for example, abcMIDI, it would be possible to convert it and carry on doing that). I'm not proposing it as an alternative to ABC, but as a complement. ABC is a very good way for us, people, to interact with computers on the subject of music. The advantages of MusicXML come into play when computers interact with each other. Easy interconversion would give us the best of both worlds. So, why ? 1) the traditional advantages of a transfer format. Export our ABC to Sibelius-users, gain access to stuff written in Finale. If/as it becomes a well-known readable format, it could become the obvious format in which to archive/distribute stuff, for greatest readability. For example, to the extent that the examples on the webpage I put up work for people here, I should perhaps already be considering making http://www.leeds.ac.uk/music/Info/RRTuneBk/ available in that format. I notice nobody's yet said whether they do or not ? 2) if easy interconversion became possible, between the various ABCs and MusicXML, that advantage of transferability could extend to ABC softwares. See the comparison on the website - I took 2 files, and put them through abcm2ps. One was Finale-generated xml, one was native ABC, which I knew to have been tested against an ABC-parser I don't use (ie, a different dialect of ABC). Both, it's fair to note, had an element of selection - there is much about MusicXML that couldn't have been handled by the conversions I have available, and the ABC was chosen as being likely to be correct but challenging. Both generated errors, which required editing to fix, but the first was much easier to fix up than the second - MusicXML _can_ already be more accessible to an ABC user than a different dialect of ABC. If ABC writers were able to convert ABC into MusicXML when they need to pass their work onto anyone else, and ABC users were able to convert this back into ABC, this would give us all a new and useful handle on The Question Of The Dialects. The ABC file in question, by the way, was Jack Campin's McLennan.abc. I await BarFly's MusicXML-export with interest ... 3) doing things to MusicXML with XSLT stylesheets is, I propose, a possibility of great interest to the coders, hackers, tinkerers and question-askers among us - there are a vast number of things that are much easier done that way to a tune than by parsing the ABC. Since XML/XSLT proposes itself as a write-once-run-anywhere, platform-independent technique, it might be possible to develop libraries of useful tricks, open to any ABC user who can convert into xml (and, indeed, maybe, non-ABC users who come to xml from elsewhere. There's potentially a much wider pool of interested people here). And even more tricks would be possible if you could convert results back to abc when appropriate. For example, Jack Campin was asking a few months back about looking through a collection of tunes and finding those with a range suitable for a specific instrument. I can't remember if it was here or elsewhere, but I remember seeing it. Did you ever get any answers, Jack ? I have ways of doing things like that. You need to parse the ABC, unroll the repeat-loops, and so on, and then identify the note-pitches. This is not trivial. I've been using James Allwright's abcMIDI parser for this (because it seemed the closest to being quickly adaptable). Having obtained a list of pitches, I pick the information I'd like out of it, using whatever hack seems convenient. Perl, for nstance. For Jack to use this, he'd need to get my C source (somewhere under my Leeds tunebook), compile it, install perl ... and get used to working that way, which I doubt seems very natural in his environment, if it was even possible, which I doubt - my C wasn't written with Macs in mind, and even if it compiled, it probably wouldn't accept his ABC input. Techniques and tricks for processing ABC are not nearly as transportable as the data is to other people/platforms/ways of working. Whereas, when I started looking nto MusicXML, one of the first stylesheet example I saw is noteReport.xsl. Which works through the notes of a tune, counting lengths and pitches, and
Re: [abcusers] ABC and MusicXML
On Thu, Mar 25, 2004 at 04:31:56PM -0500, Steven Bennett wrote: Richard Robinson wrote: Is anybody else here looking much at MusicXML ? I've been having a look over the last few days, and I must say, I'm rather impressed. It seems to me that this could all be tremendously useful to us, as ABC users. I looked at it and can see a number of places where it could be useful as a computer music storage and interchange format, but I don't see it as something that fits my own needs. It seems mostly useful as a intermediate step when converting from one music format to another - and not as useful as a native format, IMHO. Nobody is likely to write in MusicXML directly -- it's almost certainly going to either be a conversion from some other format, or someone using a computer program to enter notation. MusicXML is kind of the opposite end of the spectrum from ABC -- it's computer friendly, but not very human friendly, whereas ABC is very human friendly, but not so much computer friendly. That's what attracts me about seeing if they could be brought closer together. It's the opposite end of the _same_ spectrum. They're the same sort of thing - a textfile containing one or more tunes - people could manage them pretty much in the same ways they're already managing ABC. Indeed - ABC is better for humans, MusicXML is better for machines. So the best thing would be if we could interact with a tune as ABC and let the machines interact with it as MusicXML. One thing I've gained from looking at a different language is an appreciation of just how good ABC is, for humans. It's a perl among music-description languages (heh heh, sorry), in that it's suprising how often it _can_ see what you mean. It's a *good* interface (and that was a bad analogy, of course, ABC isn't the interpreter). And if it could become an interface into MusicXML as well as to screen, printing, MIDI, tab, storage, and so on, the world might become a bigger and more interesting place ... -- 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 and MusicXML
On Fri, Mar 26, 2004 at 05:41:01PM +, Phil Taylor wrote: On 26 Mar 2004, at 16:23, Richard Robinson wrote: There's a small error in the example files on your webpage: the DOCTYPE tags refer to local file:// URLS, which won't work on other computers. That's be the file:/c:/Program Files/MusicXML/partwise.dtd bit ?... You haven't actually included the external DTD reference. Thanks for this. There are things I need to look into here, I'll get back on this when I've had time. I'm experiencing 2 different New Language Learning-Curve Syndromes at the same time. *grin* Tried it on my Mac with three different browsers: Safari gave this, so it's clearly trying: the Female Rake abc2xml 2004-03-23 Richard Robinson URL:http://www.leeds.ac.uk/music/Info/RRTuneBk/contact.html Jig England 960 2 etc. Odd. The information's being extracted from the tags so the file's being parsed in some way, but not according to the supposed file sheet. Perhaps Safari supports XML but not XSLT ? Safari downloads the file as untyped, and BarFly won't recognise it as a text file. Curiously, if you change the file extension to .txt it works fine. (One more little thing to fix.) It's served from the website as Content-Type: text/xml and the filename extensions are .xml. I don't know how a Mac manages these things ? -- 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 and MusicXML
On Fri, Mar 26, 2004 at 09:48:11PM +, Richard Robinson wrote: On Fri, Mar 26, 2004 at 05:41:01PM +, Phil Taylor wrote: On 26 Mar 2004, at 16:23, Richard Robinson wrote: There's a small error in the example files on your webpage: the DOCTYPE tags refer to local file:// URLS, which won't work on other computers. That's be the file:/c:/Program Files/MusicXML/partwise.dtd bit ?... You haven't actually included the external DTD reference. Thanks for this. There are things I need to look into here, I'll get back on this when I've had time. I'm experiencing 2 different New Language Learning-Curve Syndromes at the same time. *grin* Ah, I see. I failed to RTFM. The abc-xml program has an option that you're supposed to use when making files to be distributed. Having done that, the files on the website now contain a DOCTYPE whose system part points to http://www.musicxml.org/dtds/partwise.dtd. And if you don't do that it emits a local-filesystem thing (which you can choose). Now fixed, perhaps it works better ? I notice also, the public part of this refers to a 0.6 spec, whereas someone (Stephen Kellet, I think) posted a reference to a v1.0 spec a couple of months back. -- 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 and MusicXML
On 26 Mar 2004, at 22:40, Richard Robinson wrote: I notice also, the public part of this refers to a 0.6 spec, whereas someone (Stephen Kellet, I think) posted a reference to a v1.0 spec a couple of months back. Current spec is 1.0. See http://www.recordare.com/dtds/versions.html. Quite a lot has been added, but everything in v0.6 is a still there in 1.0, so it should be backward-compatible. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 26 Mar 2004, at 21:48, Richard Robinson wrote: Safari downloads the file as untyped, and BarFly won't recognise it as a text file. Curiously, if you change the file extension to .txt it works fine. (One more little thing to fix.) It's served from the website as Content-Type: text/xml and the filename extensions are .xml. I don't know how a Mac manages these things ? That's fine. It's just that at the moment the Mac is in transition between two different systems for identifying the type of files, and which program owns a particular file. Safari makes no concession to the older way of doing things, and in some respects BarFly hasn't yet caught up. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
Richard Robinson wrote: Is anybody else here looking much at MusicXML ? I've been having a look over the last few days, and I must say, I'm rather impressed. It seems to me that this could all be tremendously useful to us, as ABC users. I looked at it and can see a number of places where it could be useful as a computer music storage and interchange format, but I don't see it as something that fits my own needs. It seems mostly useful as a intermediate step when converting from one music format to another - and not as useful as a native format, IMHO. Nobody is likely to write in MusicXML directly -- it's almost certainly going to either be a conversion from some other format, or someone using a computer program to enter notation. MusicXML is kind of the opposite end of the spectrum from ABC -- it's computer friendly, but not very human friendly, whereas ABC is very human friendly, but not so much computer friendly. I've often considered the idea of designing a more structured variant of ABC that would still be easy to read and write, but at the same be more flexible, expandable, and more computer friendly. I pretty much know exactly what needs to be done, but need to find time to write it up and create a sample parser. One of these years I may get around to doing just that... :) IMHO, --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
Try looking at LilyPond. On Thursday, March 25, 2004, at 04:31 pm, Steven Bennett wrote: I've often considered the idea of designing a more structured variant of ABC that would still be easy to read and write, but at the same be more flexible, expandable, and more computer friendly. I pretty much know exactly what needs to be done, but need to find time to write it up and create a sample parser. One of these years I may get around to doing just that... :) -- The penalty that good men pay for not being interested in politics is to be governed by men worse than themselves. -- Plato, philosopher (427-347 BCE) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On Thu, 25 Mar 2004, Richard Robinson wrote: I concur: musicxml is a wondeful development, which will finally make it feasible to exchange scores between different music processing software, without loosing too much information. http://www.qualmograph.org.uk/musicxml/ There's a small error in the example files on your webpage: the DOCTYPE tags refer to local file:// URLS, which won't work on other computers. Are many ABC programs currently capable of generating MusicXML ? There's a command-line Windows/Linux abc2xml There's also BarFly (Mac) and Noteedit (Linux). Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* ABC Standard: http://abc.sourceforge.net/standard/ Chazzanut Online: http://www.chazzanut.com/ Synagogue Choir: http://www.ask-choir.org/ Business: http://www.amsterdamhotelspecials.com/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 25 Mar 2004, at 22:14, I. Oppenheim wrote: Are many ABC programs currently capable of generating MusicXML ? There's a command-line Windows/Linux abc2xml There's also BarFly (Mac) and Noteedit (Linux). At the moment, BarFly only imports MusicXML. Export is still to come. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
