Re: [abcusers] how well supported is the overlay operator
On Fri, Nov 12, 2004 at 10:35:11AM +, Phil Taylor wrote: On 12 Nov 2004, at 02:16, Richard Robinson wrote: On Thu, Nov 11, 2004 at 11:23:59PM +, Phil Taylor wrote: On 11 Nov 2004, at 20:32, Atte André Jensen wrote: Hi I'm wondering how standard the overlay operator is? Which programs supports the following for instance: L:1/8 | G3G- G2FG [C8D8] | AFAIK only abcm2ps supports it at the moment. I intend to support it in BarFly in due course. abc2mtex did something with it, didn't it ? But I forget the details. Did it really? There's no mention of it in the docs, and I don't have a working copy at the moment to try it out. From usrguide.tex :- the character is carried straight through to the TeX output and the characters produce a \enotes\notes pair. Thus the input DEFG ABcd A4 e2 c2| produces [2 staves] To explain this to those unfamiliar with MusicTeX, the DEFG are put on the lowest stave. The then tells MusicTeX to move up a stave, where it puts the ABcd. The first notes of each group are aligned. The (or a bar line) moves the output back down to the lowest stave and resets the alignment, so that in this case, the A4 is on the lower stave, and is aligned with the e2 on the upper stave. ah ... related, then, but not altogether similiar. -- 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] how well supported is the overlay operator
On Fri, Nov 12, 2004 at 05:53:21PM +, Phil Taylor wrote: On 12 Nov 2004, at 14:07, Richard Robinson wrote: the character is carried straight through to the TeX output and the characters produce a \enotes\notes pair. Thus the input DEFG ABcd A4 e2 c2| produces [2 staves] To explain this to those unfamiliar with MusicTeX, the DEFG are put on the lowest stave. The then tells MusicTeX to move up a stave, where it puts the ABcd. The first notes of each group are aligned. The (or a bar line) moves the output back down to the lowest stave and resets the alignment, so that in this case, the A4 is on the lower stave, and is aligned with the e2 on the upper stave. ah ... related, then, but not altogether similiar. I see - it's a MusicTex function then, rather than part of abc2mtex? Um. I don't know. It was a thing you could write in an ABC tune, once upon a time. -- 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] how well supported is the overlay operator
On Thu, Nov 11, 2004 at 11:23:59PM +, Phil Taylor wrote: On 11 Nov 2004, at 20:32, Atte André Jensen wrote: Hi I'm wondering how standard the overlay operator is? Which programs supports the following for instance: L:1/8 | G3G- G2FG [C8D8] | AFAIK only abcm2ps supports it at the moment. I intend to support it in BarFly in due course. abc2mtex did something with it, didn't it ? But I forget the details. -- 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] abc2xml
On Wed, Oct 27, 2004 at 09:33:25PM +0200, Kristian Nørgaard wrote: Does anyone know if abc2xml is a work in progress? I myself miss support for lyrics, and according to http://home.austin.rr.com/johner/abc2xml/abc2xml.htm#features there are a lot of other limitations. I don't know for sure, but don't have the impression it's being actively maintained. It's buggy, too. Strikes me as one of those little projects that would be more sensible under an open-source license ... -- 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] Is the list back again?
On Mon, Oct 25, 2004 at 10:00:20AM -0700, Toby Rider wrote: I'll communicate with the folks at mail-archive and let them know how to get a feed from the list again, now that I've tightened up security and squashed the spam problem (for now). Thanks for doing that, it was getting to be a nuisance. Much appreciated. -- 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] ABCp output data structure
On Sat, Sep 11, 2004 at 02:17:00AM -0400, Paul Rosen wrote: First of all, I was working from the 1.6 document, I probably should have been using a newer one. I noticed that http://www.gre.ac.uk/%7Ec.walshaw/abc/abc-draft.txt contains some interesting stuff. Is that the latest that has generally been agreed upon? elemskip - arbitrary length string.[What does this do?] It's a hangover from abc2mtex. I don't think it's meaningful to any other program. We could either carry it forward, knowing that no one will use it, but some will be confused by it, or we can deprecate it. Or we can define it so that it is useful. I've just seen John W's comments - that nonesssential information should be preserved, and agree with it. It's conceivable that someone would use this new parser to transpose a piece (or do something else with it - who knows where the parser would end up ?) and then want to feed the transformed piece back through abc2mtex. So itwould have to be possible to carry any contents of this field forward. Since the default length can have only a limited number of values an int or enum would probably be more appropriate? What about the Balkan-style signatures ? In BarFly I opted for representing it as two integers, representing C and C| by making the numerator negative, but it's a kludge and I have no sensible way of extending it to deal with complex metres. It needs some serious thought. I'm not familiar enough with the odd meters to know what they are supposed to look like when printed. And do playback programs need to be aware of them? For stressing purposes, maybe. I'd still support a specific copyright notice. It's definitely a thing that some of us need to be able to write. ignore some of them. Is there a recommended place that each of the header text fields should go? Apart from X: and K: they can go in any order. What I do in BarFly is rather than parsing the header from top to bottom I seek for the fields that I actually need, ignoring everything else. I didn't state that clearly, and two out of two people misunderstood. Whoops! I meant, where the header fields go on the printed music. In other words, is there anything that says that Composer should go on the top right hand corner of the music instead of underneath the music? If I put vital info in the History field, will all programs display it somewhere? I'dlike to see this handled with something like a printf-style format string. I maybe want different fields printed, in different positions with respect to the tune, for different purposes, any attempt by a printer program to place them once and for all would be less than ideal. But I'm not sure this is a problem for the parser ? Now my head is really starting to hurt. Whenever I see these obscure cases, I want to scream, But this is for FOLK music! But I try to contain myself, because the more complete we make this, the less likely the first person who tries to use this won't be frustrated. Perhaps different folk-musics are simple in different ways ? (if at all). -- 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] spam
On Sun, Aug 29, 2004 at 08:32:54PM -0500, Chuck Boody wrote: Lots here with abcusers headers too. It includes some that is bounced back to the list from addresses that don't exist. Chuck Boody On Sunday, August 29, 2004, at 08:06 PM, John Walsh wrote: Hi, Am I the only one getting lots of spam (apparently) coming thru the abcusers list? I haven't heard any other complaints yet, but the score this morning when I opened my email was two genuine emails, one spam directly sent to me, and four with headers mentioning abcusers, like this: Yes. Same here. -- 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 parser output data structure.
On Thu, Jul 29, 2004 at 11:59:44AM -0400, Steven Bennett wrote: Bernard wrote (portions snipped): I disagree entirely on the maximise portability. The maximum is ascii. You can even read it without a computer. ... Sorry, but it seems archaic to me (in a situation such as we are talking about) not to write the file in ascii. First off, we're talking about a general purpose parser here, not a file conversion program. In all likelihood, most, if not all, of the programs it will be used with will probably link directly to it, and there will be no intermediate file or storage involved - just a data buffer of some sort returned from a function call. The output isn't intended for an end user - it's intended for a program. I suppose callbacks might be an alternative ? Honestly, it makes absolutely no sense to me whatsoever to be making an intermediate ASCII text format the output of a general purpose parser. It defeats the entire purpose of there *being* a parser in the first place. Of course, one of the things you could use a parser for, would be in an application that would generate, say, MusicXML, or other ascii, output ... -- 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] Copyright Issues ... One More Kick At The Can
On Wed, Jul 28, 2004 at 07:42:58PM +, Bernard wrote: I've read a number of discussions of this, in which the only conclusions seemed to be that nobody could find anyone who had ever received any money from these license fees. Most musicians know at least a few people who have written music, and you probably know many who have made recordings. Try asking them about it, and see if you can find anyone who has received any such royalties. I do have a friend who has made tunes, had them recorded, and received money from the record company by way of licensing them for the recordings. I don't think it went through the MCPS (the relevant UK body), though, I think it was done directly between him and the recording company. Greentrax. BICBW (he's away just now, I can't ask him). Though, my impression is that, in the UK, the MCPS seem much more sensible than the PRS, the performance rights people. -- 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] Copyright Issues addressed (fwd)
On Fri, Jul 23, 2004 at 06:58:14PM +0100, Stephen Kellett wrote: In message [EMAIL PROTECTED], John Chambers [EMAIL PROTECTED] writes (A lot of the readers here probably already know this story. Note that the Girl Scouts caved on this one; they are paying an annual license fee so that the girls can sing songs around a campfire.) My reaction to that is For fucks sake. That is just plain ridiculous. I didn't know about that story. I'm sure if these things were publicized with more coordination there would exemptions for things like this, or better still, better law. impressed Are you ? Mind you, its the exact same mindset that ... Oi ! NO !! It was tedious enough, there. Please don't export it. -- 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] reusable parser
On Tue, Apr 27, 2004 at 12:01:00PM -0400, Steven Bennett wrote: Here's a compromise: perhaps the parser can have a function like the above that takes only one tune, that is, takes a string that starts with X:, and ends just before the next X: command. Then there would be a super-parser (trivial to write) that breaks the string on X: boundaries. I'm guessing that most applications would be concerned with just one tune at a time, anyway. Actually, this is sort of close to what my parser is doing, but you're missing one *very* important thing -- the file fields. At the beginning of the file (prior to the first X: or T:) and in-between tunes (ie. After the first blank line in a tune, which ends the tune, and before the next X: or T:) there may be a variety of settings which can affect the remaining tunes in the file. In the ABC spec, these are the fields marked Yes for File. Their existence complicates the job considerably. Note that while ABC 1.6 and 1.7.6 explicitly allow these fields in-between tunes, ABC 2.0 draft states they can only be at the beginning of a file. (There really ought to be a note about this in the Deprecated Syntax section... Or the restriction should be lifted.) Yes. One consequence of this restriction is that abc files can become invalid just by being cutpasted together. If you have 2 files, each with file-scope fields at the top, a simple cat file1.abc file2.abc file12.abc will produce a file with headers between tunes. Forbidding this may make life easier for simple parsers, but I don't think it's desirable for users. -- 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] reusable parser
On Tue, Apr 27, 2004 at 09:25:27PM +0100, Neil Jennings wrote: Do we need a single executable? e.g. Although a common executable would be ideal, executables derived from a common source would be acceptable. I think a library would be better. So that other people who want to write programs that need ABC parsing can use it. People using ABC already have their own favourite programs; if you provide just one more ABC executable, it'll have to be extraordinarily all-singing, all-dancing, multi-output, etc etc, to persuade people to switch. If it's a library, other people can do the work of producing whatever behaviour they want from their executables. -- 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] reusable parser
On Sun, Apr 25, 2004 at 06:15:21PM +0100, Stephen Kellett wrote: typically an egocentric bunch of programmers with vastly different skills and backgrounds. You know your target audience :-) grin These comments aren't really intended to follow on from that, it's just a convenient way of jumping in. Honest. No, really ... (I have the same perception of sourceforge, by the way. I find it difficult and confusing, sometimes impossible, to find my way round it.) Mainly, I'd like to back off from the details - languages, websites, c - and ask, what is the purpose of this project; what are people intending to produce here ? It seems to me that a lot of attempts over the last few years to clarify thing have tended to become part of the situation that subsequent attempts then need to clarify, and it'd be nice if this didn't go the same way ... As an ABC user, with some ability (not huge) to write various languages, I have schemes from time to time, to put together code to do various things to/with ABC files. I took a deliberate decision, quite a long time ago, that I was really going to try and avoid writing an ABC parser. because, the more parsers there are, the more it seems impossible to write one that will deal with everything that all the others collectively deal with; it's too likely that another parser woud just introduce another variant dialect. On the other hand, if somebody is brave enough to try this ... well, if there was one that other coders could then plug into their projects, that would help, in the long run - it would be possible for people to build their own applications around it, that would then all be able to parse in the same, known, way. Is that the idea, here ? Parsing code, with a clear, clearly documented, API for 3rd parties to make use of in applications ? Maybe, ideally, a standalone library package ? Though, languages techniques _are_ relevant :- it seems to me that part of the problem is that, most of the popular ABC applications are specific to one platform (or one way of working - a Windows bod can use abcm2ps, but try explaing a cli program to someone who's never used one ...), so there's mutual ignorance. It _would_ be valuable to have one that could be usable on as many platforms as possible. Apart from Java, WxWidgets seems to be the most viable framework (that I know of), so maybe C++ that would be compatable with this ? And, lastly, I note that the abc-ps family are GPL'ed already. Do any of their people have comments about this ? I think Jeff suggested once that abcm2ps might be a suitable starting point ? -- 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] ANOUNCEMENT
On Wed, Apr 14, 2004 at 02:23:43PM -0700, Toby Rider wrote: Sometime in the next few weeks, I will be upgrading the mailserver software from Majordomo to Mailman. This change will be transparent to all users, but will allow me to better control the user lists as well as keep up with the never-ending battle to prevent spammers from squeezing messages onto the lists. That'll be nice. Thanks. Just at the moment, the only spam I'm receiving is via the abc list. -- 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 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
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
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
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 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
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
[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. I was going to compose a wild-eyed rant on the subject, but sadly I don't have time just now because I'm going out in a minute. But I've put some things together into an introductory webpage, plus a few examples to show some existing possibilities. http://www.qualmograph.org.uk/musicxml/ Main points are, that to be able to convert abc into musicxml, and vice versa, has lots of interesting possibilities for useful and fun new tricks. And also, that many of us may be nearer to being able to take advantage of this than they'd realised, one way or another. In short, it hopes to persuade people that this is worth looking into. Are many ABC programs currently capable of generating MusicXML ? There's a command-line Windows/Linux abc2xml (it's incomplete, it's buggy, it's closed-source and email to the author bounces, but apart from that it's great. It exists, for a start), what other ways are there to turn abc into xml ? -- 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] smaller notes among others
On Mon, Mar 15, 2004 at 03:08:05AM +, John Chambers wrote: Kristian Nørgaard asked: | Is it possible to write a part of the melody with smaller notes than | then rest. | This is often used when you want to show a short melodyline, which isn't | part of the main melodi. | | It should show up in the same staff as the rest. I think this has been asked before, but it hasn't led to any discussions that I know of. Current abc doesn't have any way to express this. Sorry. I don't think it's what you're lokking for, but just in case, for the sake of completeness, there is %%scale. I've just tested this in abcm2ps, and it can be applied to a whole staff, but not to less than that. And then there's %%multicol ... -- 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
[abcusers] multicol alignment (margin units) in abcm2ps
I've been typing some things up that require a bit of annotating; alternate versions of particular bars, for example. The neatest way I've found is to use %%multicol to drop a new (partial) staff underneath, showing just the bar in question (%%scaled down). To be comprehensible, this bar must line up vertically with the one it refers to. I've been using %%leftmargin and %%rightmargin to do this, but I think it's not quite ideal, because - I don't see a specific note as to the units these accept, but they all seem to be absolute lengths ? whereas, the position of the bar it's referring to will be proportional to the paperwidth, so wouldn't the alignment only work for one size of paper ? In other words, I tried %%leftmargin 50% and it didn't complain, but it didn't do what I hoped it might either. Not suprising, for a couple of reasons ;-) but, can anybody see a less hardwired way to do this ? -- 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] Converting accented characters
On Tue, Feb 10, 2004 at 03:13:56PM +0100, Bert Van Vreckem wrote: Hello all. For maintaining the website for my abc collection http://flanders.blackmill.net/music/collection.html, I have written a perl script that generates a webpage from a set of abc files. Only thing missing is some subroutine that converts the LaTeX-style accented characters in the abc source (e.g. \`e) to html (e.g. egrave;). Has anyone already written something like this? I use a thing called charconv, that I found on an FTP site years ago. Works well for me ... google google google http://www.tug.org/tex-archive/support/charconv/ -- 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] abc2mtex newbie problems
On Mon, Jan 19, 2004 at 12:56:58AM -, Plymale, Jesse William wrote: Then I'm not sure what to do, but running both musixtex and tex on music.tex gives the folowing errors: [EMAIL PROTECTED] abc2mtex]$ musixtex music.tex This is TeX, Version 3.14159 (Web2C 7.4.5) (./music.tex (/usr/share/texmf/tex/musixtex/abc2mtex/header.tex ! I can't find file `musicnft'. l.9 input musicnft Seeing as you are familiar with TeX, there's a good chance you know much more about it than I do, but I ran into some similar problems with abc2mtex running on my RedHat distro, and it mainly had to do with the fact that MusicTeX wasn't installed. You might have already done the following steps, but maybe they can get it to work for you: 1. Download musictex-520.tar.gz, un-tar it in your texmf/tex/latex directory There's a Debian package. I'm using stable, but it probably hasn't changed. If that's the problem, apt-get install musixtex should fix it. (2 'x's is right). Thinks some more ... have a look in the abc2mtex header.tex - there are conditionals for musictex and musixtex. musixtex does better justification across the page (anyone remember seeing asterisks at the end of ABC lines ? They caused justification when using the (older) musictex). So you may need to comment out the right blocks - musicnft seems be called from the musictex stuff. Good grief, it's a long time since I've looked at that. -- 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] abcm2ps questions
On Fri, Jan 02, 2004 at 11:55:23AM +0100, Frank Nordberg wrote: Bernard Hill wrote: I don't think there should be any standard for paper size - you should be allowed to specify your own. I can symphatize with that view. There are some practical issues involved though. For example, when you post documents on an internet site for the visitors to print out themselves, you often need them and/or want them to be formatted in one specific way which means you need to know what paper size the visitor will print the document on. Having to take two different paper sizes into account when creating the documents is more than enough of a time-waster. (In fact this discussion has led me to the conclusion that I'm not gonna waste more time on that anymore. From now on all PDF files produced for Musica Viva will be optimalized for A4 prints. If users want to print on some local/personal paper size, it's their problem, not mine.) It's another argument for providing the source as well ... -- 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] abcm2ps questions
On Fri, Dec 19, 2003 at 09:46:44PM -0500, [EMAIL PROTECTED] wrote: This is very interesting here . . . I recently started using precompiled binaries (from Guido's abcplus site), and also noticed that it was using A4 instead of US letter size. I got around it by adding the %%pageheight directive at the top of every file. I don't know why I didn't realize that this was the problem - I just figured it was something I did wrong, since it was working before when I compiled it myself on my Linux box. So, Guido - why are you compiling with A4 instead of US letter? Don't most people print sheet music using standard 8 1/2 x 11 inch paper? (I do realize that many of us are not in the US, so this may be pure ignorance here as well). Certainly, A4 seems more-or-less standard in Britain. I have the impression it is for (at least a lot of) Europe. -- 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] Bar Lengths
On Wed, Nov 19, 2003 at 09:26:40PM -, Phil Headford wrote: I may have missed this from an earlier discussion; apologies if so. Real, working musicians in bands need to be able to choose (often in a matter of seconds) a tune to go with the next dance. With a repertoire of hundreds (or a thousand or two) of tunes, the characteristics of each tune or set are not always easy to bring to mind. So, many of us have little 5 or 6 page lists, which give some of our favourite tunes aranged by the following criteria: Tune type (polka, jig, reel, etc) Key (and modulations) Bar length So which field in ABC do I use for bar structure? I have been putting this info into a J: header field - eg 32=8*2+8+8 for Galopede, 40=8*2+12*2 for Herbert Smith's Polka, 40=8*2+8+8*2 for Waterloo Dance. Some might think this academic, but for practical musicians, it's the second thing you want to know about a tune. It's a good question. I've wished, several times, that I'd done such a thing from the start. And maybe one day I'll get round to it, but in the meantime I've occasionally cheated, with things like R:32-bar Jig; which is better than nothing, but not the Right Way. As to what would be the Right Thing To Do ... I can't seem to find a definition for J: - I'm probably looking at the wrong standard - but would be reluctant to use up the main namespace (some people would regard this as vital, others will say it's no use to them, cue many of the usual arguments), so I'd think about about using the %% to invent my own, for what would be, to start with, an individual usage. Something like %%PH-barstructure: 40=8*2+12*12, where the PH helps mark it as yours, ie keeps it clear against the day when somebody else invents their own variant with a different layout or subtly diferent meaning. Or you could pick up Barry's proposal for I: , something like I:PH barstructure: ?? -- 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] Re: Tune identification
On Mon, Oct 13, 2003 at 12:29:20PM +0100, Jon Freeman wrote: From: Frank Nordberg [EMAIL PROTECTED] It is. I'm planning to hook it up with Irish Rover (stole that idea from somewhere - don't remember who). Let's if anybody in the audience can manage to stay seated through that combo ;-) I can't remember what song we (as residents at the Llandudno Folk Club) used to follow with the Rakes of Mallow Winster Gallop is its usual pairing here. -- 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] Tune identification
On Sun, Oct 12, 2003 at 04:08:27AM +0200, Frank Nordberg wrote: Can anybody help me identifying this tune? I'm pretty sure I *should* know it, but can't place it! Frank Nordberg http://www.musicaviva.com X:1 T:? C:? O:? R:Polka? M:C L:1/8 Q:1/4=180 K:G G.G.B.G.B .G.B c/B/A/G/|D7.F.A.F.A .F.A d/c/B/A/|\ G.G.B.G.B .G.B d3/B/|Cc/B/A/G/ D7FA/c/ GB.GG2:| |:Ggf/e/ .d.c B.cd2|Ggf/e/ .d.c D7B.cA2|\ Ggf/e/ .d.c B.c d3/B/|Cc/B/A/G/ D7FA/c/ GB.GG2:| I have it as Rakes of Mallow. -- 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] Clarification wanted on abc draft standard 2.0 (fwd)
On Sun, Oct 12, 2003 at 02:17:14AM +, John Chambers wrote: Richard Robinson writes: | On Sat, Oct 04, 2003 at 03:11:33PM +, John Chambers wrote: | | In general, it seems that rests should almost always be treated as | notes. The only way they're different is that a rest doesn't have a | pitch. | | And is tricky to play staccato ? Well, you could make the rest very short, and immediately play another note. Or, if you're a John Cage fan ... ... you could call that a strathspey ? (Sorry it took so long to reply. I've been on the road for a week. Now I'm in Mammoth Lakes, California, where there's one of the few motels that actually has the Internet access that they advertise. Who knows when I'll be able to reply to a reply to this reply ...) On a subject of such importance, too. Heck. -- 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] Clarification wanted on abc draft standard 2.0 (fwd)
On Sat, Oct 04, 2003 at 03:11:33PM +, John Chambers wrote: In general, it seems that rests should almost always be treated as notes. The only way they're different is that a rest doesn't have a pitch. And is tricky to play staccato ? -- 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] suggested modifications to the ABC standard
On Fri, Sep 26, 2003 at 11:33:34AM +0100, Stephen Kellett wrote: In many places you are taking an already existing tag (for want of a better word), such as X: or T: or t:, whatever and adding overrides with no prefix to indicate it is an override. For example, the CAPTION override for the T: field which currently indicates a text field describing the tune title. T: CAPTION my snippet What if a tune starts with the word CAPTION? Stranger things have happened. From Barry's suggestion about using the space caracter as delimiter. As you give it above with a space after the T:, CAPTION is indeed the 1st word of the title. If it was T:CAPTION, without the space, then that's the field an my snippet would be the value. No ? -- 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] suggested modifications to the ABC standard
On Mon, Sep 15, 2003 at 06:15:51PM +0100, Barry Say wrote: After much consideration and a little discussion, I have devised some modifications to the ABC standard, which I think could make the structure considerably more elegant without doing to much damage to existing applications. As they are rather complex I have described them on a web page: www.nspipes.co.uk/barry/abc2propos_r1.html I would welcome any comments on or off list. Slow following this up, I'm sorry, I've been a bit taken up with other things. And - I'm not sure where to start, with commenting on this. As you say, it doesn't necessarily imply very much change in the way ABC is written, but requires changes in the understanding we have of what we write/read. Interesting. And elegant, yes. The field:optional labelspacevalue could be a very neat way out of what's been a problem, the limited number of single letters for fields; but could lead to a mess of proliferation similar to what we have now with the %% directives, if everybody starts inventing their own labels. Would we want to write some standard labels into the definitions of the fields in a new new proposed standard, in the same way that you propose some for the I: field ? - which, likewise, offers a neat way out of the mess of proliferating directives. I like it. minor comments ... You remark, having all music lines fit into a field, either explicitly or 'virtually' means that there is now virtually no need for a continuation character. But, as you also remark elsewhere, it's still needed for hiding the linebreak=staffbreak behaviour, which I guess is maybe its most common use. Y: for copyright - yes. I think copyright is important enough to need a field of its own, the lack of a general way to write this has been conspicuous for a long time. As for the questions at the end ... what changes would be needed ? I can't see many ways in which existing ABC wouldn't be readable by software written to these ideas, except for the possible lack of a space after a fieldkey, and that free text wouldn't be marked wih a t: field, both of which would be fairly fixable. I've probably missed lots of points, though. ABC written to these ideas would be more of a problem for existing software, with key-labels being understood as part of the field values; and maybe an unvalued V: would break some software ? As for whether the developers would write software ? ...???...??? And the perennial question - ABC is easy for humans. The worst I can think of is that the text-editor brigade would omit the space after the field-key if they did't want to use the labelling syntax. Which would revert it to the existing syntax. It would be interesting to see a new abc2mtex, after all these years :) -- 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] Uppity typesetting (was: gchordfont and alternate repeats)
On Tue, Aug 26, 2003 at 06:05:48PM -0400, Ewan A. Macpherson wrote: On 25 Aug 2003 at 11:59, Jean-Francois Moine wrote: I find this (new to abcm2ps) business of adding in notational elements not specified in the abc a bit disturbing. If a player program needs to insist on correct notation of repeats or whatever, fine, but a typesetting program shouldn't care. Any way to turn this off, Jef? I don't see what you expect... What I'm getting at is that I don't think an abc typesetting program should be making corrections like this. There is a fairly direct correspondance between the notational symbols in the abc file and what shows up on the rendered page. If a user *wants* a double bar they can write it in the abc file, and if they want something else they can specify that, and the typesetter should typeset it as specified. This seems to make sense. Well, to me, anyway ... couldn't these symbols just be treated literally. ie print dots where you see a :, a normal barline where you see | and a thick bar line where you see ], in any combination ? Would this cause any issues. maybe for player programs, if people started writing free-form combinations of these ? -- 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] Page break formatting
On Fri, Aug 15, 2003 at 08:47:16AM -0400, Jeff Bigler wrote: From: Laura Conrad [EMAIL PROTECTED] Date: 15 Aug 2003 07:15:15 -0400 Jeff This seems so simple that I must be forgetting some obvious Jeff reason that it couldn't work. Can anyone enlighten me? Traditionally, one of the reasons to use ABC rather than other input languages is ease of typing. True, though this is mostly in terms of inputting the actual tune. People who want something that simple probably won't use %% directives anyway. There could also be a sort of simplicity to it, in that such a scheme would make these things easier to understand, and possibly to remember ? Especially if they were all consistent in their use of hyphens, spaces, colons, whatever, as delimiters - it might be possible to remember write them without having to consult a big list each time. Also they'd be a bit easier for programs to parse, which is an invisible advantage for users, but might still exist. -- 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] Page break formatting
On Wed, Aug 13, 2003 at 05:08:55PM +, John Chambers wrote: Richard Robinson writes: | | usual rant | I really _wish_ the layout/typesetting command could have been marked, | with, eg %%abc2ps newpage, in the same way as the original midi ones | were. It might have at least made issues like this easier to think | about. | /usual rant There was the suggestion that all these should be marked as formatting things by using %%FMT This would be a good hint that other programs interested in music formatting might want to implement them. This would also go along with the abc2ps gimmick of reading global formatting info from a *.fmt file. I wonder if anyone has implemented this? Some of the abc2ps %% commands don't properly fall under the formatting classification. One is slurgraces, which says whether grace notes are slurred to the next note. Another is writehistory, which says whether the H header lines should be shown in the output (but doesn't say how to show such lines). But most of abc2ps's %% commands are for control of formatting. Yes. But mostly, at least, display-related. Some of them are tune-specific, some of them work on the page level. And then there's %%propagate-accidentals which has a musical meaning. It would be easy to add this to an abc2ps clone, so that it accepts the older form without the FMT. Maybe I should do it, and convert a lot of my files. Not that I use %% much; I usually use a *.fmt file. But we could probably do this very easily to all the clones. Then, after a few years, we could decree the FMT-less notation deprecated and try to discourage its use. Strikes me as a constructive move, to provide people with a way that all these magicwords can be marked as to what they relate to, and encourage them to use it. With a view to eventually being able to deprecate the existing formless confusion, yes. If the display ones can be neatly-enough separated, perhaps even something like %%PageFMT and %%TuneFMT ? And I suppose such a scheme would imply [PageFMT], [MIDI], etc, section headers in the proposed include files ? So, what spaces would be needed ? We already have MIDI; along with a note that there may be issues (volume ?) that relate to all sound-generation rather than being midi-specific And format - possibly subdivided into page and tune levels ??? And the abc-related ones; %%abc-creator, %%abc-include etc And some oddments - copyright charset are currently stated as %abc- but I can't see that they relate specifically to the abc-ness of a tune in the same way that the others do ? And %%propagate-accidentals, which is more than a style issue altogether. -- 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] Page break formatting
On Wed, Aug 13, 2003 at 12:25:19AM -0400, Tom Keays wrote: The system Phil proposes below wouldn't work at all for me. That is to say, I know I wouldn't use it even if he went to the trouble to implement it. I think, therefore, that I can only support them if they are placed immediately adjacent to the tune to which they apply - either immediately before the X:, or at the end of the tune before the blank line which indicates its end. Umm. Somebody's already mentioned the TuneFinder here, haven't they ? And it's a point - An app that picks selections of tunes out of an abc file would treat the 2 cases differently, no ? %%newpage X:1 T:What ? K:C aaa aaa|] and the parser kicks in at the X: and the tune is extracted starting with the X:, the %%newpage isn't part of the tune. But X:1 T:What ? K:C aaa aaa|] %%newpage and the parser stops on the blank line, the %%newpage is extracted as part of the tune. I'm not sure this is desirable behaviour ? It runs into a much more general question, actually - if you re-order tunes in an ABc file, how do you handle any interposed non-ABC text, where should it go ? I don't think there's a clean answer to this. -- 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] gchordfont and alternate repeats
On Thu, Aug 14, 2003 at 09:53:13PM +0200, I. Oppenheim wrote: On Thu, 14 Aug 2003, Ewan A. Macpherson wrote: I was hoping to be able to use this to implement the mid-repeat variant notation, e.g. |: A A | B B | [1 c c] | [2 d d] | e e :| but unfortunately, abcm2ps also puts in a thick barline after the ']' instead of just closing the bracket. Since you typed a | after c], it seems logical to draw a barline. If you want an invisible barline, type [|]. If you don't want a barline at all, don't type |. Is the [ repeat a bracketed construct ? - ie is the closing ] necessary ? -- 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] Page break formatting
On Wed, Aug 13, 2003 at 11:54:30AM -0400, Tom Keays wrote: On Wed, 13 Aug 2003, Laura Conrad wrote: Are you assuming that all tunes fit on one page? If not, it seems like one very well might need %%newpage or some such within a tune. Ah, yes. Good point fx:worms sing louder What usually happens when tunes won't fit? I am assuming that programs like abcm2ps simply continue them onto a second page as a matter of course. I suppose you might occasionally want to fine-tune where the split occurs (such as making a split come between parts rather than in the middle of a part) and here the %%newpage might be used in the middle of a tune. But mostly, not. [Hopefully the abc, in such an instance, wouldn't end up on the web.] I hadn't thought to test that before ... abcm2ps does The Right Thing with a pagebreak inside a tune. Once people get involved with tunes that spread over more than one page (which is itself, of course, a page layout concept rather than a tune concept), I'm sure there would be complaints if they couldn't get control of where it happens. And if it comes to that, once paged tunes hit the web (and if people write them, they will), should they be A4, Letter ... ? -- 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] Page break formatting
On Wed, Aug 13, 2003 at 12:04:10PM -0400, Laura Conrad wrote: I've spent all these years struggling to learn LaTeX, and I'm not going to learn abcm2ps %% directives to replace that with, but as someone who has had the flexibility of LaTeX for all these years, I assure you that one of the things people often want to use it for is to specify where page breaks come. Hear hear. and \vfill / \hfill. I find TeX and its friends really horrible, I've never really understood what I'm doing with it - but, it _works_, it does the job, once you've managed to tell it what the job is. Likewise, I reckon the %%abc2ps directives aren't a very satisfactory substitute. Basically, I think the original abc2mtex model was a good and helpful way to look at it - go through the file replacing each individual tune with something that a typesetter can treat as a tune, and then hand the whole issue over to the typesetter. Like I said before, keep things separate. And I think lilypond-book is like that too ? I suppose the abc2ps equivalent would be to drop all the directives except the %%postscript pass-through. Which makes me feel much more kindly towards LaTeX. -- 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] Page break formatting
On Wed, Aug 13, 2003 at 02:29:19PM +, John Chambers wrote: Richard Robinson writes: | | X:1 | T:What ? | K:C | aaa aaa|] | %%newpage | | and the parser stops on the blank line, the %%newpage is extracted as part | of the tune. I'm not sure this is desirable behaviour ? Very good point. And the Tune Finder does exactly what you suspect: Of course :) And anything else that reads tunes out of a file, I imagine. How _else_ could you parse it ? fx:noise of can-opener, worms sing offstage inside the tune). A better way to write the second would be: X:1 T:What ? K:C aaa aaa|] %%newpage Well, but I thought Phil's point was that BarFly could only handle them if the %%newpage wasn't separated from the tune like that. However, there's not a lot that can be done to enforce such suggestions on other people's web sites. So a better idea would be for programs to have options that override such things. The abc2ps clones will all recognize and act on %% lines whether they're inside tunes or not. But this particular %% line will cause grief if it's part of a tune in a file that has been pasted together from single tunes. So you either need a way of ignoring %%newpage, or you must edit the file before formatting it for printing. There are so many problems like this that I always edit any downloaded files before printing them. I just know that the result isn't going to be something that I like. True, and likewise. But an app that asks people to write such constructs can only increase the amount of editing we have to do. -- 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] Page break formatting
On Wed, Aug 13, 2003 at 09:53:59AM +0100, Phil Taylor wrote: The point is that the program treats tunes as individual entities, displaying an index of titles which can be sorted in various ways (alphabetically, numerically by ID or by position in file). When the user issues a print command, the program retrieves the selected tunes from the index in the current order, creates a picture of each, and then fits the pictures together to make printed pages. Under these circumstances, %% directives which are not attached to a particular tune are meaningless. ISTM more that directives like %%pagebreak (or is it %%newpage, sorry ?) refer to the layout of a collection of tunes, not to a single tune - they are only meaningful when the collection stays in that order; as soon as you start thinking about reordering tunes, or selecting only some, anything referring to the overall structure of the original becomes meaningless. Like the example given - start a new page before the first of a bunch of reels and print a page-heading. If this has to be attached to a particular tune, what happens when you sort them in a different order and that one's no longer the first ? -- 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] Page break formatting
On Wed, Aug 13, 2003 at 03:32:03PM +0100, Phil Taylor wrote: Richard Robinson wrote: It runs into a much more general question, actually - if you re-order tunes in an ABc file, how do you handle any interposed non-ABC text, where should it go ? I don't think there's a clean answer to this. I think you are right. BarFly doesn't re-order the original file though, it just pulls the tunes out for printing in the specified order, ignoring the interstitial text. You can always read the text, and if you want you can print the contents of the file as text. Since BarFly's editor can handle embedded pictures, I could also at some point add a command which would replace the abc tunes with pictures, leaving the interstitial text between them. Printing that would be a nightmare though. On the whole though I think that forced pagebreaks and other such printing options are better handled outside of the abc in my case. Perhaps I could add a symbol to the index to indicate that this tune should start a new page. If the index was sorted differently that tune would still carry the mark, so it would be obvious to the user. Yes. This is the point at which an ABC GUI has to shift onto an entirely different level - it moves from being a tune editor/interface into becoming an entire page-layout scheme, which is a whole separate issue. usual rant I really _wish_ the layout/typesetting command could have been marked, with, eg %%abc2ps newpage, in the same way as the original midi ones were. It might have at least made issues like this easier to think about. /usual rant I've played around with trying to build GUIs for this (don't hold your breath - nothing likely to be fit to use, or even look at, for a long time. Anybody got any favourite perl/gui toolkits ?), and the only approach that works for me (that I've been able to think of so far) is very like what you describe - a layout mode, with interstitial text (good phrase) displayed and editable and the tunes presented as some kind of link (title, picture, whatever) to an editing interface on that tune (and a facility to print/postscript the whole thing by passing it through abcm2ps, or some such external), and a separate database mode - just list the tunes, with searching sorting filtering and so on, where you can print each tune individually or select them somehow for adding into a page-layout. The 2 situations, tune and page, have to be kept separate somehow, it seems to me, they're on different levels. -- 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] chords accidental semantics
On Sun, Aug 03, 2003 at 12:44:28AM +0100, Jack Campin wrote: And it's a bit confusing to call these accidentals when they are in fact systematic (I'm not sure what the correct term is and don't have a reference handy to locate it, but I'm sure there is one). Deliberates ? -- 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] expandable information field
On Sun, Aug 03, 2003 at 12:46:07AM +0100, Jack Campin wrote: (I'm going to be away for a week, OS 1:5 sheet 48 302241, a mile off the nearest road with no modem). Take plenty of Jungle Formula. I hear the midgies are especially ferocious this year! Hardly saw a midge the first couple of days. Then I tried playing the flute outside at the end of the house around midnight, looking across to the lights of Iona. Within a minute or two I was in the middle of a cloud of them and had to beat it back indoors. My host suggested I should have kept playing until they were *all* gathered round and then marched off over the hill taking them with me. Heh. People are always so keen to volunteer someone else for these jobs. I hope you had a good time there. I'm off next week, down to Sidmouth to play with the Scandy dancers. I know a newsgroup where it's traditional to ask people to keep the volume down while someone's away. The traditional response, of course, is for everyone else to up their posting rate by a factor of largenumber. So, have fun, don't do anything I wouldn't do chorus: bwahahaa. -- 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 Standard 2.0 revision III
On Wed, Jul 30, 2003 at 02:51:45PM -0400, Laura Conrad wrote: Phil == Phil Taylor [EMAIL PROTECTED] writes: Phil Also I don't like the idea of Phil %%MIDI nobarlines Phil because it means something totally at odds with what it says. Bar Phil lines have nothing to do with midi - the midi standard provides Phil no way of representing them because they are a purely visual Phil feature of printed music I think it's a pretty good description of the music that would want to tell a MIDI (or lilypond) writing program what I want to tell it, though. The barlines are not purely visual, because any program that translates standard notation into MIDI has to use them to decide how to interpret the accidentals. Phil If you want to specify that accidentals are non-persistent you Phil should not use %%midi becuase the implication is that a program Phil which plays abc directly without using midi can ignore it. I'm perfectly willing to live with some other terminology if other people feel it communicates the idea better. The standard does need a way to communicate this idea, though, and as far as I know, this is the only method in current use. Though, since this would be new behaviour, which programmers would have to write in, they could look for any %%magicword at all to trigger it ? Though, yes, the use of the existing %%midi namespace would be a clue - helpful in general (since it gives a rough idea of what sort of work it does) and misleading in particular (since, as Phil says, it's all player apps that would need to look at it, not just midi ones). I really think we should have some thought for this question of proper namespaces. The original use of them, in abcMIDI, had %%MIDI thisthatortheother which was a good idea, to make it clear what area they were in. Then the typesetters added a _lot_ of others with no such information about what sort of uses they apply to. More recently we've had some proposals for %%abc-thisthatorthother, and just now I see more proposals for some without any particular namespace. If these are only ever going to be used by one program, this may not be a particular problem; anybody that gets bored with picking their interesting ones out of this disparate chaos can invent their own identifier and ignore all the others. But if there is any idea that any of these should be understandable to more than one program, then I think it would be a really good idea if we could introduce some organisation into this. I would say before it gets too late, but I've said that in the past, and it's later now, and there are more of them. Like, the case in question maybe should be %%play nobarlines if it applies to all player programs. And then midi programs would know that these apply to them and would also look for %%midi whatever which apps that play, eg direct to the speaker, could ignore. And we'd have things like %%abc include filename %%abc version X.Y.z-sectb_breakaway_faction_of_3rd_Sept_2004 %%abc charset for things which do refer to the ABC itself (I've followed the namespace id with a space rather than Irwin's hyphen, btw, just so I can show it the same as the original midi, to try and sneak in the idea that these things could all be parseable in the same way). (Small note. %%abc-copyright isn't right. Maybe some people would have a need to coyright the abc itself, but there is also a need to record the copyright of the tune itself; abc isn't the right namespace for this, it has nothing to do with abc) I am aware that this would create a problem with the existing ones that don't use this technique. And if we go on inventing these willynilly, it'll grow up to be a bigger problem. While we seem to be busy redefining everything anyway, let's get it right. I mean, do we really want some of these to have namespace specifier and others not to, but just to throw %%papersize, %%loudness, %%staves, %%continueall, %%infoline, for example, all into the same space ? Is it clear and simple, for either humans or applications ? -- 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] ABC20-draft review
On Wed, Jul 30, 2003 at 10:27:07AM -0400, Wil Macaulay wrote: It will be interesting to see where the next explosion (of content, I mean, not of personality!) takes place. I'd love to see it in the area of vocal music - hymns and such-like. My personal opinion is that abc is most useful for large bodies of similarly-styled music to be used by musicians as a rough guide to repertoire instead of an exact guide to performance. I guess that's why I don't expect an explosion of content when/if Finale supports abc output... I think you could be riht. My guess is that, if programs like this do start speaking ABC it could be rather a one-way process (that's not in any way an argument against it) in the same way that lilypond currently seems to be. You could take ABC and feed it into something else that gives, eg, explicit layout, and all the rest of the goodstuff that yourpackageofchoice gives you. And then you can't re-export that to ABC without losing ggodstuff, which after all you want, because if you're content with what ABC gives you you'd be using that primarily. Um. And there again, you're importing it from ABC because you want the goodstuff that ABC gives you that, eg, Finale doesn't. Like the ability to _handle_ an explosion of content. I had getting on for a thousand tunes typed up in Finale, once, before I discovered ABC. It needed a separate database app to keep track of filenames and header info. -- 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 Standard 2.0 revision III
On Thu, Jul 31, 2003 at 10:42:15AM -0400, Laura Conrad wrote: Richard == Richard Robinson [EMAIL PROTECTED] writes: Richard Though, yes, the use of the existing %%midi namespace Richard would be a clue - helpful in general (since it gives a Richard rough idea of what sort of work it does) and misleading Richard in particular (since, as Phil says, it's all player apps Richard that would need to look at it, not just midi ones). It isn't just player apps -- it's any app that expects an absolute note value rather than a description of the note's appearance on the staff. So abc2ly, which you would normally think of as a typesetter, needs it just as much, and for the same reason, as abc2midi. Ah. Interesting, yes. Also, come to think of it, ny abc_compare, which borrowed the abcMIDI parser, to unroll ABC into a stream of notes. Does abc2ly also unroll repeats, etc ? If so, maybe what we're actually talking about is a distinction between 2 parsing methods - unroll into a stream and then re-parse, vs do something with each symbol in the order (moreorless) given by the ABC. ?? Not that I'd suggest phrasing any possible structuring of %% namespaces like that ... -- 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] Announcement: Current state of ABC online
On Thu, Jul 31, 2003 at 04:58:52PM +0200, I. Oppenheim wrote: On Thu, 31 Jul 2003, Guido Gonzato wrote: While you at it, please explain to me what is the use of the G: field? ooops - typo. Used by ABC database apps. Do you know which database applications use it and for what purposes? It was originally described as Group. Which is open to interpetation, of course. I've seen an example of G:Flute. And, yes, people might want to groups tunes together by instrument. I have used it in the sense of what groups of people have I played this one with, which is an entirely different way of grouping things, but useful to me because I've played with lots lots of different bunches of people, so it's another way of filtering for tunes related to this one. And I daresay other people might understand it in a lot of other senses. I'm not sure this is any kind of a problem, it's nice to have a field that people can use to group things together in whatever ways they find useful ? There is the question of what happens if people publish tunes using this, what other people should understand by it ... I filter G: out of my public ABC, since my use of it is kind of personal. Maybe that's a definition we could tie it to ? G:You are not expected to understand this Um, rephrased, of course. -- 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 standard changelog
On Thu, Jul 31, 2003 at 03:25:29PM +, John Chambers wrote:
Laura Conrad writes:
|
| Speaking of advisory accidentals, that seems to me to be something
| that we've talked about fairly often, and it still hasn't made it into
| the standard. That is, for an accidental which isn't strictly
| necessary by the normal standards for notation, but which the
| transcriber believes will help a performer, there should be some
| typographical distinction, like putting it in parentheses, and ABC
| printing programs should allow you to indicate this.
Some time back, someone (maybe several someones) pointed
out that notation like (^)G is not in conflict with current
abc syntax, and would be obvious to most users.
It isn't the same meaning as with other parentheses, but it
might be the best way to handle this specific case.
Maybe I should try implementing it, and see just how
difficult it really is. The main parsing problem is
distinguishing the '(' it from the start of a slur.
It would be nice to be able to do them, somehow.
--
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 Standard 2.0 revision III
On Thu, Jul 31, 2003 at 11:01:34AM -0400, Laura Conrad wrote: Richard == Richard Robinson [EMAIL PROTECTED] writes: Richard If so, maybe what we're actually talking about is a Richard distinction between 2 parsing methods - unroll into a Richard stream and then re-parse, vs do something with each Richard symbol in the order (moreorless) given by the ABC. ?? No, we're really talking about a parsing method that insists on getting an absolute note value (so you have to know what accidentals the transcriber *meant* in addition to the ones he or she typed) and one that only cares about what the note looks like on the page (so you can assume that if the transcriber didn't type one, they don't want to see one). You're right, of course. So the underlying namespaces would just be something like %%sound and %%sight -- 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 2.0 Compatibility with ABC2MTEX
On Wed, Jul 30, 2003 at 10:51:40PM +0100, Barry Say wrote: I am concerned about the lack of backwards compatibility of the proposed standard with abc2mtex. Since this was the original program for ABC, I think these issues deserve some consideration. 2.This version of the standard has gone overboard in specifying %% type directives. As I understand it, this is a postscript notation. No, it's TeX :) All these are based on the fact that ABC uses % as a comment - which is TeX, via Chris W, for obvious reasons. All these %%whatever usages are based on the point that the first character makes it a comment, and thus anything behind that will be ignored by any ABC application unless it takes the trouble specifically to look for it. Though I agree with your overboard in the sense that, as I say elsewhere, this ad-hoc proliferation is likely to leave us with problems later. In abc2mtex, lines starting with \ were used to pass information directly to the typesetting level. These must be allowed in the new standard This is a good observation. I didn't even remember TeX when there was all the discussion of backslashes. Though I did notice that we seem to have strayed from the TeX special characters, as well, there would need to be a little translation layer before all of these newlydefined ones would get printed via TeX. I particularly notice the comment in Irwin's abc-drafts, that Chris's original abc examples will need to be edited to conform to the standard. In fact, abc as it is currently being written is increasingly unlikely to go thrugh abc2mtex, and abc written for that is not likely to go through anything written to conform to this draft. More on this elsewhere. One untested thought - is abc2ly and lilypond a possibility for you ? It at any rate keeps the TeXness that other abc apps don't. But I've never used it in anger, just a thought. Another thought. I suspect several of the people here will never have used abc2mtex, or TeX, and won't see the point unless you show some examples of what you're doing with it that no other app. can do instead. -- 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] Revising the ABC standard.
On Thu, Jul 31, 2003 at 09:13:36AM +0200, Guido Gonzato wrote: On Wed, 30 Jul 2003, Barry Say wrote: How are we going to reach decisions on a new standard? I don't think we'll ever reach decisions this way. How come the proposal by Guido was suddenly expanded? because I got overwhelmed by Irwin's burning desire to revolutionise ABC, so I gave up... And, I thought Henrik was involved with this original attempt, too ? so I gave up... now I'm writing documents that concentrate on _existing_ extensions to the standard. That seems like a good idea. It will be useful to have statements of what is actually the case. Increasingly, I begin to wonder if this should be seen as a fork. I've been arguing the toss over a lot of these new proposals, on the grounds that they might as well be done right if at all, but I'm also beginning to wonder whether I'd actually be prepared to update to software that conforms to it, if/when anybody changes the code to do so. -- 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] Higher notation anyone?
On Thu, Jul 31, 2003 at 04:48:04PM +, John Chambers wrote: | On Wed, Jul 30, 2003 at 03:31:50PM +, John Chambers wrote: | When I first ran across abc, I was quite impressed by the fact that | it (abc2ps actually) accepted M:7/8 without complaint and did the | Right Thing. When I tried M:4+3+4/16, it also did exactly what I | wanted it to do. | | Yes, that was a thing that impressed me, too. On the other hand, when I first tried transcribing some Zwiefacher tunes, I also discovered that abc2ps accept M:23/44 and did the, uh, Right Thing with it, too. I was appalled! ;-) laughter. I suppose the bug will have to be fixed, now it's been mentioned ? -- 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] 8.3. Accidental directives
On Thu, Jul 31, 2003 at 04:59:44PM +, John Chambers wrote: And, of course, we'll have the objection to that, that much of English music terminology is stolen from Italian and French anyway, so what does it matter? There is the old rule among musicians: If you hear a good tune, steal it (and claim it's part of your tradition). Though, of course, it doesn't matter whether the tunes are traditional or not, because really the tradition is not a matter of which tunes you steal - just so long as some get stolen. -- 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] Re: 8.3. Accidental directives
On Thu, Jul 31, 2003 at 01:11:04PM -0400, [EMAIL PROTECTED] wrote: From Irwin's standard - 8.3. Accidental directives %%propagate-accidentals not | octave | pitch When set to not, accidentals apply only to the note they're attached to. When set to octave, accidentals also apply to all the notes of the same pitch in the same octave up to the end of the bar. When set to pitch, accidentals also apply to all the notes of the same pitch in all octaves up to the end of the bar. The default value is pitch. but as Richard Robinson points our elsewhere - All these %%whatever usages are based on the point that the first character makes it a comment, and thus anything behind that will be ignored by any ABC application unless it takes the trouble specifically to look for it. If this one is ignored, it will affect the playback of tunes. It is a necessary function but it should be part of the abc standard not part of the stylesheet specification. That's my point about trying to get organised namespaces for these things. We need a coherent way of organising all the magic words so that people, and software, can see what sort of things they apply to and when they can safely be ignored. (And I suppose some of those spaces should be in the standard, and others off somewhere quieter). -- 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] Revising the ABC standard.
On Thu, Jul 31, 2003 at 02:51:53PM -0400, Laura Conrad wrote: Richard == Richard Robinson [EMAIL PROTECTED] writes: Richard Increasingly, I begin to wonder if this should be seen as Richard a fork. I've been arguing the toss over a lot of these Richard new proposals, on the grounds that they might as well be Richard done right if at all, but I'm also beginning to wonder Richard whether I'd actually be prepared to update to software Richard that conforms to it, if/when anybody changes the code to Richard do so. I agree with this. One thing that seems to me missing from this effort is a codification of exactly where this standard is incompatible with previous versions of the standard. That is, not where ABC which works with one or more current applications will fail with a program designed to the new standard, but where something written with a sincere desire to adhere to the standard will have to be modified to adhere to the new standard. The '*' for right justification seems like an example of this, and midline fields with a continuation character before them may be another. I haven't got round to checking this very hard yet, but I think some of the new special-character-sequences don't play in TeX (??has anybody checked this, can anybody say??, in which case any app. that uses this to print text fields will need to start checking them and translating. -- 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] musicXML
On Thu, Jul 31, 2003 at 08:13:59PM +0100, Phil Taylor wrote: I. Oppenheim wrote: On Thu, 31 Jul 2003, Richard Robinson wrote: Has anybody seen any of the XMLish schemes do anything useful, yet ? I haven't had a look round recently, ibut whenever I have it's all looks kind of maybe one day-ish. musicXML is a format that actually works. Finale can import and export it, and barFly can also deal with it. BarFly can import it (up to a point - it can express stuff which abc can't) but not yet export. There are third-party plugins for both Finale and Sibelius. The great white hope is Project Xemo, a free modular environment for working with MusicXML (to do something like what BarFly does with abc), but I haven't heard much about it recently. Project Gutenberg is using MusicXML for music books. Ah, okay. Thanks. Good, the more the merrier. I'll keep a copy of that for when I next have a look round ... -- 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] Changelog of ABC 2.0
On Wed, Jul 30, 2003 at 12:03:03AM +, John Chambers wrote: Richard Robinson writes: | What about the cases where notes in different octaves | have different accidentals ? I don't see why notes in the key | signature couldn't take the full normal ABC value, with uppercase | and lowercase and , and ' as necessary, so that somebody could | express a key signature with different accidentals for a note in each | octave right up and down the scale. Why do we have to forbid everything | we can't think of a use for ? Other people have already expressed a wish | for this, John has already said so for anybody that missed it. That's basically what I implemented. Except that I haven't gotten around to debugging leger lines in key signatures. ;-) I wonder if there are actually any musical styles where this would be useful? I don't know of any, but that's not much evidence. Likewise. We're missing Jack's input, aren't we ? ;) But actually, given that there have been expressions of a need for /interest in 2-octave scales ... you wouldn't have to go very far on those lines (hah ! sorry) before leger-lines started showing up. You've only got one B C without them, for instance. ... | Is K:D exp _b _e ^f different from K:D _b _e ^f ? | Where does this come from, has it been mentioned before ? That exp is a new one with me. But we did have a discussion some time back in which several people expressed the desire for a no mode symbol. The discussion then seems to have settled on '*' as the symbol, so you'd say K:D*_B_e^f for example. I didn't see any real need for this, but I actually spent a couple of minutes implementing it. I haven't used it myself, because it's not logically necessary. But it is easy enough to implement. I think that Irwin just made up the exp. It's probably as easy as *. Neither is really necessary. But then, key signatures aren't really necessary, are they? So, on the assumption that the mode has to be explicitly stated if there are following accidentals, the 2 are the same ? -- 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] Changelog of ABC 2.0
On Wed, Jul 30, 2003 at 09:22:12AM +0100, Bernard Hill wrote: In message [EMAIL PROTECTED], Richard Robinson [EMAIL PROTECTED] writes Is K:D exp _b _e ^f different from K:D _b _e ^f ? Where does this come from, has it been mentioned before ? As I have always understood the standard, the accidentals following it *modify* the key sig. So K:D _b _e ^f actuall leaves also a c^. The point of the exp is to *override* the normal key sig of D. I thought that discussion had already happened. -- 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] Higher notation anyone?
On Wed, Jul 30, 2003 at 09:38:29AM +0100, Bernard Hill wrote: There has been quite a bit of discussion about features which are not part of standard notation and yet are acceptable in abc. Fine. But I propose that all such things are NOT implemented in version 2 but wait for version 3. This would include strange key signatures. N-times repeats ::| etc (and possibly more I can't think of just now) If you leave such constructs in version 2 you are actually inviting existing music software (such as Sibelius or Finale or any software which does not have these constructs implemented) never to implement abc as a format. But if you *did* persuade just one of the big software companies to implement abc then just imagine the explosion of abc files out there in public domain. I'm probably going to get shot down but I'd like to see what the reaction here is first. PS I don't actually *know* that Sib Fin can't do those constructs, but the principle stands. I note that Dave Webber of Mozart has been silent here for a good while and wonder if he has abandoned the projected implementation. I know that I have certainly been getting cold feet because of all the new features required. One possible counter-argument would be, that if ABC was able to express things that no other software can, just imagine the explosion of usefulness. Tunes might start turning up containing information that people previously didn't have any way of expressing. Some people believe this has already happened, to borrow from Douglas Adams. -- 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] Let's move on
On Wed, Jul 30, 2003 at 11:19:44AM +0200, I. Oppenheim wrote: On Wed, 30 Jul 2003, Bernard Hill wrote: Is K:D exp _b _e ^f different from K:D _b _e ^f ? Where does this come from, has it been mentioned before ? As I have always understood the standard, the accidentals following it *modify* the key sig. So K:D _b _e ^f actuall leaves also a c^. The point of the exp is to *override* the normal key sig of D. You have fully understood it. I think that the problems of possible ambiguity in key signature notation are now solved. To me, the existing jcabc2ps understanding of it [1] seems much more elegant and I can't see any reason to require this change, but I suppose that's between you and the people who write the code. [1] The given example actually produces 1 sharp and 2 flats, ie is equivalent to D exp. If you want the D to mean the normal key sig of D you can get it by saying, explicitly, K:Dmaj _b_e^f, which will get the c# -- 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] Let's move on
On Wed, Jul 30, 2003 at 12:36:17PM +0200, I. Oppenheim wrote: On Wed, 30 Jul 2003, Richard Robinson wrote: K:D _b _e ^f actuall leaves also a c^. The point of the exp is to *override* the normal key sig of D. [1] The given example actually produces 1 sharp and 2 flats, ie is equivalent to D exp. Nope. As I have explained earlier, K:D _b _e ^f is equivalent to K:D maj _b _e ^f. If you want a key sig with only _b _e ^f you *must* specify K:D exp _b _e ^f Please. This is getting daft. My statement, I hope, made it clear, as it isn't in the quote here, that it described the actual behaviour of an actual program. If you disagree with it, as that, I suggest you test it for yourself and see. I *know* that behaviour is not as you say it should be. If there are still questions about the key signatures syntax, please send them to me off-list. It's not a question, but I've left it here in case anybody else is getting confused. hollow laughter -- 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] Let's move on
On Wed, Jul 30, 2003 at 10:16:37AM -0400, Wil Macaulay wrote: I agree with Richard wil Richard Robinson wrote: On Wed, Jul 30, 2003 at 11:19:44AM +0200, I. Oppenheim wrote: If I could have a couple of meta-whatsits, for a moment ? All Wil's messages appear in my mailer as above (though without the quote marks, you pedants) - very spaced out vertically. At least 2 0x0a newlines, sometimes more, sometimes interspersed with 0x20s. Do other people see this, or is it an artefact of my system ? In my posting that Wil quotes, where I wrote the existing jcabc2ps understanding of it [1] seems etc the [1] construct was intended as a pointer to a footnote. It never occurred to me that this wouldn't be obvious to all concerned, or that it could be read in any other way. I gather I was wrong in this, for which I apologise. -- 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] ABC20-draft review
On Wed, Jul 30, 2003 at 03:27:13PM +0100, Phil Taylor wrote: Arent Storm wrote: * ~ I always thought that ~ is used for a prall-trill by default. Hardly anybody will know what an Irish-roll is (is it eatable?) I'll bet there are at least a hundred times as many abc users who know what an Irish Roll is ... I think the long roll is currently deprecated, in favour of the baguette. Though this may be a regional usage. -- 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] Added starter...
On Wed, Jul 30, 2003 at 09:53:19AM -0400, [EMAIL PROTECTED] wrote: I am one of the world's only specialists in Thuglarki music, which as you know is performed by three or four elderly yak herders in the Kletnuf Mountains of Central Asia when they have nothing better to do. Oh, splendid. I knew there were more voices out there. Thuglarki music, which is horribly (and perhaps needlessly) complex, appears to have a different key signature for each measure. Or maybe it's just that lads are getting a little tone deaf as they age - hard to tell. In any case, I recently ABC'd one of their favorite songs, the Bu Shpremt yig Platsl 'c Uv (roughly Who Was that Nanny Goat I Saw You with Last Night?), and had to use the following K: field: K: D =c^g[?]^A[maybe]=f[are you serious?]_B[aw come on]=D,, ...and that was only for the first measure. Is there any way we can expand the standard to satisfy my (admittedly) peculiar requirements? These guys won't be around forever - the young lad of the group is 113 (gotta love that mountain air and simple diet). A C-style /*...*/ comment syntax would deal with a lot of these, but I think the trailing commas may be a more serious problem. These are intended to represent different intonations on each occurrence of a specific note, are they ? I take it that your needs for the M: field would probably need a separate thread. Oh dear. I just remembered ... one of the first things that happened to me when I got a net connection was a discussion, somewhere in the stranger reaches of alt.*, concerning marching bands and imaginary time signatures. Now, let's have a look at this. The standard says It is also possible to specify a complex meter. Bwahaha. jcabc2ps will accept both 4i/4 and 4/4i without complaint, but only displays the 1st of these correctly. Interesting. Perhaps a better solution would have been to arrange for an acceptable collateral damage due to friendly fire incident, but now you've blown the gaff on this we may have to ... er, just stay where you are, okay ? Don't move. Damn unpredictable creature, Johnny Yak. aside I'll keep him talking, right, while youNO CARRIER -- 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] Let's move on
On Wed, Jul 30, 2003 at 06:54:42PM +0100, Phil Taylor wrote: Richard Robinson wrote: All Wil's messages appear in my mailer as above (though without the quote marks, you pedants) - very spaced out vertically. At least 2 0x0a newlines, sometimes more, sometimes interspersed with 0x20s. Do other people see this, or is it an artefact of my system ? Yes, I see it too. I guess it's a peculiarity of Wil's email program. Good, good. Just so long as it's not a peculiarity of mine. Ta. -- 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] Let's move on
On Wed, Jul 30, 2003 at 02:26:03PM -0400, Wil Macaulay wrote: hopefully this fixes the problem (text only, no html in netscape mailer) wil Looks good here. Thanks, you just became a lot easier to read. -- 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] (no subject)
On Wed, Jul 30, 2003 at 02:45:58PM -0400, [EMAIL PROTECTED] wrote: Richard Robinson wrote - The standard says It is also possible to specify a complex meter. Bwahaha. jcabc2ps will accept both 4i/4 and 4/4i without complaint, but only displays the 1st of these correctly. Interesting. I think you will find that, with a little rearrangement, 4/4i is equal to -4i/4. Negative Meter? Tricky. Play this piece backwards from the beginning. Oh, yes ! Technically, since neither of these has a real component, they are not really complex but completely imaginary. *sigh*. So it is. But not to worry. jcabc2ps will accept, and display correctly M:(4 - 4i) / 4 BWAHAHAA ! I'm impressed, John :) -- 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] (no subject)
On Wed, Jul 30, 2003 at 09:49:33PM +, John Chambers wrote: Richard Robinson writes: | On Wed, Jul 30, 2003 at 02:45:58PM -0400, [EMAIL PROTECTED] wrote: | Technically, since neither of these has a real component, they are not | really complex but completely imaginary. | | *sigh*. So it is. | | But not to worry. jcabc2ps will accept, and display correctly | M:(4 - 4i) / 4 | | BWAHAHAA ! | | I'm impressed, John :) I don't take credit for this. If you try it with Micheal's original abc2ps, you'll find that it works there, too. It certainly makes your point that the abc-midi converters often have it harder than the typesetters. One of the abc files in my collection is the Mozart piece that is to be placed between two players on opposite sides of a table. Each reads it from their own viewpoint. Each is playing it upside-down and backwards from the other. It's a shame he couldn't have had ABC. God only knows what he might have done with it ... One of the things wrong with the abc2ps output is that it should have inverted treble clefs on the right end of each staff. If we take M:-4/4 to mean to Play it backwards, we are halfway to what we need. We just need a way to say Play it upside-down, and we'll be able to properly represent this important historical work in abc. Uh-oh ... -- 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 Standard 2.0 revision III
On Mon, Jul 28, 2003 at 11:15:14PM -0700, John Walsh wrote: Wil Macaulay writes: --- Due to popular demand, +...+ is now the preferred syntax for notating decorations; !...! has been deprecated, although it is still allowed. I thought ** was proposed? although deprecated, ++ is still around as an alternate to [...] for chords. They were both proposed. In addition, +..+ looks ugly, to me, at least. Looked ugly for chords, still looks ugly for decorations. Oh well. But this raises another question: shouldn't the standard mention obsolete notation to alert future developers to stuff which might be expected to show up in old abc files? (It's not a very long list: +..+ for chords, s..s for slurs, and [1, [2 for repeats come to mind. **, *, + and/or !---depending on what is finally decided---are other cases in point. There are probably a couple more, but not many.) Abc2mtex has some flags: oldchords, oldslurs, which allow it to process these; I don't know if other programs handle them at all. Should they? AT least to list them, would be a good idea, so that if someone meets them in a tune and their program doesn't handle them, they'll know what they mean and be able to do the appropriate translation by hand. WRT [ repeats - this document gives the impression they are the preferred form, all the examples given use it. I notice that the way it notes that When adjacent to bar lines, these can be shortened to |1 and :|2 give the implication that [ repeat constructions can be used in mid bar. I've just checked, and see that the abc2pses will do this - is it generally acepted ? If so, there is reason to not regard these as obsolete, since this is something that can't be done with the |1 form (following on from which, I also notice none of them accept that A dotted bar line can be notated by preceding it with a dot, e.g. `.|') -- 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 Standard 2.0 revision III
On Mon, Jul 28, 2003 at 08:55:54PM +0200, I. Oppenheim wrote: Please help me with identifying the errors and the mistakes in the draft. 1) It starts by saying The ABC standard itself deals only with structured, high-level information; how this information should be actually rendered by e.g. a typesetter or a player program, is dealt with in a separate standard. It then goes on to state where each field will be printed. This is at least inconsistent, and I don't think this is the right place for this level of detail. Better (IMO) would be if the proposed style-sheet mechanism allowed a way to control where, and which, fields the typesetting programs print, so that people can decide for themselves how they'd like things printed (I want different layouts for different purposes, for example) and still get consistent behaviour across different programs. One possibility My abc_rip, for instance, uses a %%RR-TextFormat: magic header line, which is a format string sort of thing in which any instances of T:, C:, etc are treated as fields and replaced by their values. Any including any %% specials. Including a %TUNE variable which is replaced by a picture of the tune (with no text), so that I can put things below as well as above. That's how I manage to print a copyright string under the dots. It's probably less than perfect, but for me it works better than anything else I've seen. 2) I'd like more discussion of the redefining of A: as Author (of lyrics), and consequent redefining of O: to hold the area information that A: has been used for in the past. Jack suggested this, and it may may well be a good idea, but I haven't heard much comment from anyone else here, and I'd like to be sure we've thought it through. I have an interest here, since I use A:==area heavily; and since, as Jack noted, I use this with multiple O:'s, relying on human intelligence to make sense of possible confusion, it wouldn't be a simple editing job; so I'd like to be sure we all agree it's The Right Thing To Do before I do it. One thing I notice about the proposal for O: is that it introduces (for the first time, I _think_) a hierarchical structuring of information within a field (A: as area did that across different fields, of course, and I agree with Jack that it's not altogether nice). I wonder if there are maybe any catches to this ? One minor point, for example - the recommendations for which fields to print where (see 1 above) would lead to the whole lot getting printed, without any associated syntax for picking out sub-fields (I might want to print just the country, as I can at the moment, for example). Does any other software do anything with these information fields ? There are possibilities with external programs, of course, like the $ grep O: | cut -d ',' -f 1 example I gave earlier, which is why I argued (and repeated offlist to Irwin) the case for most-significant-first ordering rather than Jack's little-endian example. Special-case treatment of the O: field. That's what bothers me. It's the need for a delimiter character. My scripts, for example, which generate the listings for my web collection - since I list (and allow searching) these by country, and definitely don't want separate entries for, eg, England and England, NW I'll have to pick out all info up to the first comma. If I do that to any other field things'll go wrong, since comma doesn't mean delimiter anywhere else (and I can't think of any other character to which this wouldn't apply). Which is not the end of the world, of course. I can do that if I have to. But it's the sort of complication that makes me wonder if it's really the right way to go. -- 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 12:26:09PM +0200, Bert Van Vreckem wrote: Bernard Hill wrote: In message [EMAIL PROTECTED], Bert Van Vreckem [EMAIL PROTECTED] writes Bernard Hill wrote: 2. What's a roll (+roll+ in the decorations)? I've checked 6 music dictionaries and books on notation and the only rolls mentioned are for timpani or other percussion and notated as either tr or a tremolo. It is used at least in Irish music as a general ornamentation mark. I've come across the notation a.o. in Traditional Irish Music: Karen Tweed's Irish Choice, Dave Mallinson Publications, 1994. Thanks. But what does it mean? What would say an autoharp make of it, say perhaps to make it a tremolo. It means play any ornamentation here. The exact meaning is unspecified. I rather like ~ - play a squiggle. -- 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 11:41:39AM +0100, Bernard Hill wrote: Strange key sigs such as the above (while clear in intent) are very non-standard. Are they really necessary? I've never played from one and would actually find it very difficult to play _b ^f See http://www.leeds.ac.uk/music/Info/RRTuneBk/gettune/0c54.html for an example of how they can be useful. Helpful for the typing, and (IMO) more helpful in that they show the rules that apply, instead of just confronting people with lots of accidental notes. (note to self. fix middle sections, so that D maj. doesn't look strange either) -- 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 Standard 2.0 revision III
On Mon, Jul 28, 2003 at 08:55:54PM +0200, I. Oppenheim wrote: Please help me with identifying the errors and the mistakes in the draft. Order of ABC constructs should include all possibilities. Tuplets are missing, for example. I suggest structuring this list - like, spell out the ordering of symbols which apply to a single note, then treat this as a note in an ordering of larger constructs ? -- 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 04:03:23PM +0100, Phil Taylor wrote: [EMAIL PROTECTED] writes There are to supported syntaxes: [A] K:tonicmode accidentals [B] K:tonic accidentals This is actually a bit counterintuitive, since K:D means D major (= 2 sharps) while K:D ^f means D mix (= 1 sharp) Not that there are many tunes about currently which use global accidentals, but the second interpretation of the symbol D breaks the old standard. Yes. The least necessary change would be to require explicit Dmaj, which would label a bare D as tonic. But all of this breaks with what's Already Out There. If the symbol D is to be interpreted in a new way (i.e. as tonic, rather than as a D major key signature) I'd rather it was explicitly labelled as such, i.e. K: tonic=D ^f or some such. As with Bryan's suggestion, I'd prefer to keep the simplicity of searching for K:tonic to find all tunes that sit on tonic. -- 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 03:17:52PM +, John Chambers wrote: Richard Robinson writes: | On Tue, Jul 29, 2003 at 01:15:54PM +0100, Bernard Hill wrote: | | And from the abc source you have written | | K:A_b^f^c | | shouldn't that have a G# also since you've written K:A? | | It definitely shouldn't have a G#, since the Gs aren't sharp. | | It's K:Asomething since A seems, to me, the root note. Amix would have | been better - I have a vague memory that I tried that and it didn't work | at the time, so the result's a kludge. But it does now. | | It would seem more logical to write just K:Amix _B to get Bb and the | usual 2 sharps, but in abc2mps that produces a sig with 1 flat, only, | so the full spelling out seems necessary. OTOH, the shorter version | works with jcabc2ps, but that doesn't accept spaces in it. I rather | prefer the appearance from abcm2ps - and, spelling all the accidentals | out seems to let me control which order they're shown in, which is nice ... | If I use K:Amix_B^f^c in jcabc2ps it prints the sharps twice. (Hmmm ... I tried to make it accept spaces. Maybe I'd better do a bit more debugging.) jcabc2ps vjc.1.1.0 (2003.01.27, std) compiled Jul 11 2003, by the way. (Maybe I'd better a do a bit more checking) ... the Amix was upsetting it. It'll take K:A ^f_B^c correctly, but a space after the ^f hides subsequent accidentals. Anyway, after playing around with such key signatures a bit, it quickly became obvious that, if an explicit list of accidentals is included, then the mode should *not* default to major. This would produce some very baffled users. The right default is no mode, i.e., no accidentals other than what is listed. To see why, consider a simple case like E hejaz/freygish, which is E F ^G A B c d e Any musician who knows what this sort of scale is will write this: K:E^G If the default is major, then the musician will get a result that is indistinguishable from E major. The ^G may be shown twice (in both octaves), which will be even more confusing. The only solution would be to write this: K:Ephr^G Or K:E=f=c^G=d ? Longer, but maybe clearer. Now this may seem reasonable, because in fact it's exactly right. But it has one serious problem: You need to use a different mode for each tonic note. This will make sense to someone intricately familiar with the classical European modes. But to the other 99% of the musicians in the world, it will be utterly baffling. If I want to do the same thing with a tonic of A, I'll have to write something like: K:Amin_B^c These are the same sort of scale. That is, they really are the same mode. But I'd have to write a different mode name for each, and the name has no obvious relation to the actual mode. The reason is that the mode would be used solely to cancel the major key signature. This would be hopeless, and would defeat the whole purpose of having an explicit key signature. So the right way to do it is to accept either a mode or a list of accidentals, or both. Only if both are missing do you assume major. This makes sense to me, I think. My experience if transcribing things like this is the actual pitch of the notes becomes clear fairly quickly, while actually trying to get the thing down. But I may then want to change my mind about the root note later. So it's nice to be able to change just the one letter without any implications on the rest of the line. OTOH, I do like to use both. If you use K:Ephr^G, you can tranpose it down a step by just writing K:Dphr^F, and transposing it to A is then K:Aphr^c. You just do the same shift to the tonic and to all the accidentals. If you use K:E^G, then transposing to A would give you K:A_B^c, which isn't quite as trivial. *sigh* yes. So how to reconcile these ? If accidentals are given on a K: line, then if a mode is given you get the second usage, just above, and if it's just a bare notename you get the first usage ? -- 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 04:12:38PM +, John Chambers wrote: Richard Robinson writes: | The only solution would be to write this: |K:Ephr^G | | Or K:E=f=c^G=d ? Longer, but maybe clearer. Actually, I do include accidentals with this scale at times. The main reason is that with: Oh, dear, confusing. I'm sorry, I meant on the opposite assumption, that that implied Emajor. K:E=F^G This is *really* obvious that there's something funny going on. I do like the look of this one. It's so blatantly non-classical. Cor. yes, it's definitely eye catching. Anyway, the best way to approach this is probably to treat bo the mode and any explicit accidentals as giving the key signature, so major should not be assumed. You only assume major if there is no key-signature information at all. This seems both expressive and comprehensible, and retains backwards compatability as well. -- 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 05:11:44PM +0100, Bernard Hill wrote: In message [EMAIL PROTECTED], Richard Robinson [EMAIL PROTECTED] writes And from the abc source you have written K:A_b^f^c shouldn't that have a G# also since you've written K:A? It definitely shouldn't have a G#, since the Gs aren't sharp. So you are saying that K:A has 3 sharps K:A _b has no sharps and one flat instead? This is totally illogical. I can understand K:A _b to mean 3 sharps and add a b flat but what now is the significance of the A? As I said, Amix would have been better. What I was trying to notate was a key signature of Bb f# c# So, having clarified my mind, I hope, thanks to John, either K:Amix Bb or K:A _Bb ^f ^c since in the 1st, stating the mode brings its keysig in, and in the 2nd, not stating it doesn't imply any key signature. In either case, the significance of the A is that it's the root note of the tune. The root note is totally irrelevant to anything. I don't think so. As you indicate, sometimes there is argument about it anyway. I said I might change my mind about what it is. That hardly implies that it doesn't exist. But the indication that I'd think about it suggests that I'd then like to record it. As I can. Now I don't really mind having minor keys as they are well established, and maybe even the modes Very tolerant of you ;) but in the case of made-up key signatures described exactly in a K: format I don't see the point. Make that K:_b^f^c in your example above. As above, I wouldn't want to have to throw the root note away. Why should I, what's the advantage ? -- 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 05:20:26PM +, John Chambers wrote: Bernard Hill writes: | In message [EMAIL PROTECTED], Richard Robinson | [EMAIL PROTECTED] writes | | Or K:E=f=c^G=d ? Longer, but maybe clearer. | | K:C ^g looks fine to me. Well, it looks fine, but it has the wrong tonic. This doesn't matter on paper. But there are those of us who take advantage of the computer's ability to find stuff for us. This would cause it to match a search for tunes in C, which is not what you want if the tonic is E. This is part of the argument for making the tonic optional. K:C^g is misleading and causes bad matches. K:^g would be better, because it wouldn't give a mismatch. It wouldn't match a search for any tonic, of course, which is one of the reasons you'd prefer to have the tonic present. But at least it wouldn't match the wrong tonic. Of course, such searches are always prone to failure because people just give the wrong key. It's common to see K:G for tunes in E minor or A dorian. There's not a lot we can do about this except try to educate people. If I had them locally (the tunes, not the people) it might be worth considering a single-character key sig as a flag for this might need changing :-) -- 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 06:23:26PM +0100, Bernard Hill wrote: In message [EMAIL PROTECTED], John Chambers [EMAIL PROTECTED] writes Bernard Hill writes: | In message [EMAIL PROTECTED], John Chambers [EMAIL PROTECTED] writes | | If I had my druthers, I'd put a rule in saying that beginnings of | repeated sections *must* be marked properly. But of course that's | dreaming yet another impossible dream. | | Well in Music Publisher it refuses to play the music observing the | repeats until you *have* put a |: in. (Excepting the first repeat of | course). And I don't expect to remove that restriction. What I've thought a player should do if any phrase after the first is missing its initial repeat is to split into a polyphonic mode and start playing simultaneously from the beginning and just after the last end-repeat. This would be an accurate rendition of how a group of musicians would be expected to read such notation. ROFL! (Also known as Hey, let's play it as a round! ;-) Another fine product for abc international. Reminds me, I still haven't got round to that random pipe-march generator. This is probably a Good 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 06:26:21PM +0100, Bernard Hill wrote: In message [EMAIL PROTECTED], Richard Robinson Now I don't really mind having minor keys as they are well established, and maybe even the modes Very tolerant of you ;) Well they're not really needed now, are they? There's no separate notation for them. What, modes ? There's a notation for them, yes. They're needed, yes. In that, it's another of those things that you can do with ABC key signatures that you can't do on paper. Same idea as the explicit accidentals, that you can give the tonic as well as the accidentals. However I had not allowed for the use of abc files as a database. In that case I can see a use for a tonic= or mode description. Ah. That's how we were talking at cross purposes, then. Yes, that's the point of things like that, that you can search a collection of ABC files for them. And that's one of the really huge advantages that ABC has, for my purposes. Perhaps this should have a mention in the spec., if people can currently overlook it ? As I have proposed in another post, how about K:_b^f^c tonic=A ? I'd think the usage that John was clarifying (see the K:E ^G discussion) does the same job rather more neatly without breaking the orginal usage. -- 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 05:32:51PM +, John Chambers wrote: It's quite logical. K:A has a tonic but no scale information, so we assume major (^f^c^g). K:Amix has a tonic and a mode; the signature is ^f^c. K:A_B has a tonic and a key signature, which is _B K:_Bhas no tonic, but a signature, which is _B. Maybe it's F or Dm. This last has the potential to be misunderstood, I think. The key signature would be K:Bb ? Easy to mis-type, or misunderstand. -- 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 08:42:32PM +0200, Arent Storm wrote: From: I. Oppenheim [EMAIL PROTECTED] They are non standard in Western music, but you will find something like [K:D _b _e ^f] often in e.g. Klezmer (Ahavoh Rabboh) or Arabic music (Maqam Hedjaz). My first thing will always be to remove any non standard explicit accidentals, replacing them with inline accidentals and inform the player textwise that he/she is playing an unusual mode/key. Anyway lots of klezmer tunes change mode/key every few bars so the need for non-classical is rather limited IMO. The mode/key/accidental stuff is way too complicated for the average folk player (in the Netherlands anyway - wer'e not so smart you know ;-) I remember when I first heard mention that modes could be introduced into the ABC key signature (or maybe it was when I discovered they had been. I don't remember it *that* well). I felt the same about that. Complicated, academic, abstract, who on earth needs it ? But I had a poke around with it, one rainy Sunday afternoon, just to see what happened. And I discovered, to my suprise, that it worked better than what I knew. It was a better description. I could get the key signature I wanted _and_ say what the tonic was, both in one move. So it became worthwhile to understand them; and now, years later, I can even remember whether I mean dorian or mixolydian without having to look them up, though I don't use the others so much. If there are people who use ABC, or are considering using ABC, for music where non-standard signatures are less non-standard, they might make the same discovery. -- 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 07:19:17PM +, John Chambers wrote: Richard Robinson writes: | On Tue, Jul 29, 2003 at 05:32:51PM +, John Chambers wrote: | | K:_Bhas no tonic, but a signature, which is _B. Maybe it's F or Dm. | | This last has the potential to be misunderstood, I think. The key | signature would be | K:Bb ? | | Easy to mis-type, or misunderstand. Don't look now, but we already have that problem. I've seen a fair number of abc tunes with key signatures like K:_B or K:^Fm, where the person was obviously confused on this issue. It's too bad that abc copied the traditional confused notation. I suppose the people who do this will eventually figure out why abc programs produce the wrong key signature with their tunes. This confusion is probably not helped by an extension that makes K:Bb and K:_B both legal but with different meanings. But since it's exactly the same sort of confusion that is in conventional music notation, the same sort of learning experience applies to both. Yes. A case where the usual recommendation that parsers be liberal in what they read could, given the extension, have unfortunate results. But not if they implement it, of course. Now if there were only a way to make conventional music notation more rational ... Then it would become unconventional notation ? -- 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 06:07:16PM +, John Chambers wrote: Richard Robinson writes: | | Of course, such searches are always prone to failure | because people just give the wrong key. It's common to see | K:G for tunes in E minor or A dorian. There's not a lot we | can do about this except try to educate people. | | If I had them locally (the tunes, not the people) it might be worth | considering a single-character key sig as a flag for this might | need changing :-) Well, this might not be all that bad an idea. I've thought that it would be nice if a transcriber could write something like: K:?Adorian This would mean that the transcriber is guessing the key. The software would just ignore the '?', of course, and give ^f as the signature. But it would warn interested readers (humand and software) that the transcriber had some doubt about the accuracy of the key. Implementing this would be easy for most abc software: Just ignore the '?'. Yes. There's nothing to prevent K:Adorian % ??? is there ? Though some GUI software may hide it, I suppose, I don't know (I prefer to use a few of them, to avoid textual ?s in searches). But it might be nicer if we could put it/them straight in the fieldvalue and have it ignored. But, if in, say, a T:, it wouldn't want to be ignored to the extent of not getting printed ... -- 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 09:58:42PM +0200, Arent Storm wrote: If there are people who use ABC, or are considering using ABC, for music where non-standard signatures are less non-standard, they might make the same discovery. For the church-modes part I agree, the explicit accidental signature will confuse anyone trying to play the music from paper (except for the authors band perhaps) No, not fair. It's there on the paper, it's clear what's meant. It might *suprise* some poeple, if they haven't seen it before, but it's not confusing. Except the business of learning to remember non-standard groupings of notes, but if people want to play music that uses them, why shouldn't it be possible to describe them ? -- 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 Standard 2.0 revision III
On Tue, Jul 29, 2003 at 08:47:27PM +0100, Phil Taylor wrote: John Chambers wrote: that it would be nice if a transcriber could write something like: K:?Adorian This would mean that the transcriber is guessing the key. The software would just ignore the '?', of course, and give ^f as the signature. But it would warn interested readers (humand and software) that the transcriber had some doubt about the accuracy of the key. Implementing this would be easy for most abc software: Just ignore the '?'. Unnecessary. You can already write: K: Adorian %? but nobody does. People who get the mode wrong are mostly not aware of their errors, and don't question their mode decisions as long as it gets the right key signature. True. But what about us pedants who aren't sure they've got it right ? grin -- 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] Changelog of ABC 2.0
On Tue, Jul 29, 2003 at 10:08:13PM +0200, I. Oppenheim wrote:
-- The debated section on Key sigs reads now as
follows:
...
The key signatures may be modified by adding
accidentals, according to the format K:tonic mode
accidentals. For example, K:D Phr ^f would give a
key signature with two flats and one sharp, which
designates a very common mode in e.g. Klezmer (Ahavoh
Rabboh) and in Arabic music (Maqam Hedjaz). Likewise,
K:Dmaj =c will give a key signature with f sharp and
c natural. Note that there can be several modifying
accidentals, separated by spaces, each beginning with
an accidental sign ('__', '_', '=', '^' or '^^'),
followed by a letter in lower case.
What about the cases where notes in different octaves
have different accidentals ? I don't see why notes in the key
signature couldn't take the full normal ABC value, with uppercase
and lowercase and , and ' as necessary, so that somebody could
express a key signature with different accidentals for a note in each
octave right up and down the scale. Why do we have to forbid everything
we can't think of a use for ? Other people have already expressed a wish
for this, John has already said so for anybody that missed it.
It is possible to use the format K:tonic exp
accidentals to explicitly define all the accidentals
of a key signature. Thus K:D Phr ^f could also be
notated as K:D exp _b _e ^f, where 'exp' is an
abbreviation of 'explicit'.
??
Is K:D exp _b _e ^f different from K:D _b _e ^f ?
Where does this come from, has it been mentioned before ?
--
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] expandable information field
On Sat, Jul 26, 2003 at 11:00:11AM +0100, Phil Taylor wrote: Jack Campin wrote: I'd like to catch the use the the Y: field for future extensions like Y:someinfofield=some info field value This way we've maintained compitiblity with existing abc files while having the possibilty of future expansion. Perhaps Phil (as the person whose program has the strangest parser) No stranger than its author:-) Ah. Double-take. I had read that as strongest parser. What bothered me about the previous suggestion was the prospect of having to deal with METRE: 4/4 KEY: C etc. And then there's the multi-language-support issues. :-) -- 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] Re: About the choice of '!'
On Fri, Jul 25, 2003 at 05:58:42AM -0400, [EMAIL PROTECTED] wrote: Irwin Oppenheim wrote - Using ! and !..! in one and the same tune may lead to disaster if you make a small typo. So, while ! should definitely be supported, I encourage you to support * as well. It just seems to make a messy situation more complicated. I agree. I'm unhappy and confused about this. I have just become able to use ! staffbreaks, in the last few days, with their addition to some of the abc-ps family (or perhaps, my awareness of that, following the discussion here). Simultaneously with this, I'm hearing that they shouldn't be mixed with !decoration!s. But if I need decorations in a tune, and want to control the printing layout, and keep it readable ? Pick any 2, sure. But, if all 3 can be done, it's asking a lot of people to suggest they not do them. I really don't think the idea of constructs that shouldn't be used in the same tune is a flyer. If I have a tune with decorations, and want to add a staffbreak somewhere, I'm just not going to delete the decorations. And I'm one of the people that's at least trying to pay attention. I suppose what I'm saying is that asking the general abc-writing public to have symathy with the poor developers in coping with stuff that's murder to parse properly is just something that won't happen. And, is this reccomendation on the level of a single tune, or does it, actually, apply on the file level ? How about alternate tunes in a file, one using just ! staffbreaks and the next using just !...! decorations, will software be happy with this ? BarFly wants the user to tell it which, I gather ? And along with this, the new draft says the the character to use for staff-break is something that no software I have implements. So I'm not in a position to follow such a standard however much I'd like to. I'm not very sure what I think of a spec. that tries to tell developers what meanings they have to change in their existing code, but _if_ that's where we are ... Either the ! is used for both purposes and parsers will have to accept this as normal, rather than tryng to persuade people not to do it, or something'll have to change ... As far as I can tell, !...! is much less widely used, the collections that use it and the software that implements it are still maintained. It could be changed. I hear the cry Why should we? I reply For the greater good of abc. I agree. I'd think ! should be staffbreak, both for the amount of existing stuff, and usability with abc2win, and for Jack's point about visual intrusiveness. And that then suggests *decoration*, which - as Bryan says - _could_ be done in abcm2ps, etc, *if* Jeff agrees; and visually, I think it works better; by analogy with my emphasis in the previous line - it follows the general ascii conventional usage. But, the raw fact is, in the case of conflict between software and spec. people will do what their software implements. There's no choice. And they seem to be headed in different directions - which is where we came in. -- 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] Installing abcm2ps on OS X
On Fri, Jul 25, 2003 at 01:29:11PM +, John Chambers wrote: This is much of why unix users haven't generally switched over to full-time GUI use. Pretty pictures are fun and flashy, but if you actually want to accomplish something without constantly gritting your teeth about the idiocy of the user interface, you need a command language that you can type and that can remember things for you. Well, yes. But it does depend what sort of things you're doing. I'm terrifyingly geeky, according to most of my friends (though not, of course, to a _real_ geek), but I'd _hate_ to, eg, edit .wav files via a cli. But _full-time_ GUI use, of course not. Stick with the best of both worlds. -- 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] Re: About the choice of '!'
On Fri, Jul 25, 2003 at 07:15:34PM +0200, I. Oppenheim wrote: So the bottom line is: it would be nice if both ! and * could be used to notate a staffbreak. The people who do not use !...! won't be bothered by it, and the people who use decorations will have an easier time. We're into the territory of defining new stuff here. As I said before, I suggest it may be preferrable to invent *decoration* instead. There is a good historical basis for precisely using * as a staff break operator, alongside the ! operator. Namely, in abc2mtex it was already in use to force right-justified line breaks. I know that's what abc.txt says. a * at the end of each line of abc notation will force a right-justified line-break. But actually, it's the end of each line that's the linebreak - the * forces the justification. Try it :- X:1 T:Test K:C cdef gabc'- |*c'bag fedc |] $ abc2mtex test.abc error in input file test.abc: line no. 4 - syntax error - note cannot follow justification -- 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] asterisks (and obelisks :-)
On Fri, Jul 25, 2003 at 08:34:03PM +0200, Arent Storm wrote: I have quite a few danish tunes fron at least 1999 disabling abc-'linebreaks' this way and end with a double ** Wahey ! They go back further than that. 1994, I think :) Nothing goes away, even when you update it ... T:Tellings hopsa http://www.leeds.ac.uk/music/Info/RRTuneBk/gettune/090a.html T:Klaphopsa http://www.leeds.ac.uk/music/Info/RRTuneBk/gettune/0920.html have versions that are workable with more modern programs. I see John's answered the question, which is lucky, because I was busy grepping the source ... I'd completely forgotten what it meant. Cor, it's ages since I played any hopsas. -- 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] Help - getting ABC files on BarFly
On Thu, Jul 24, 2003 at 12:29:34PM +0200, I. Oppenheim wrote: On Thu, 24 Jul 2003, Phil Taylor wrote: The classic MacOS does not use file extensions to identify files, instead there are two four-character fields associated with files, called the creator and file type signatures. The old version of BarFly can only open files of type TEXT. ResEdit can only fix one file at a time, but there are several free or shareware programs which can operate on multiple files Hmm, apparently UNIX is not the only OS that can be somewhat less than intuitive :-( They all have to be learnt. The only intuitive user interface is the nipple. -- 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] About the choice of '!'
On Thu, Jul 24, 2003 at 07:55:50AM +0200, Jean-Francois Moine wrote: On Tue, 22 Jul 2003 16:27:39 +0100, Richard Robinson [EMAIL PROTECTED] wrote: [snip] AB cd ef | fe dc BA | ! !trill! AB cd ef | fe dc BA |] complains Decoration not terminated and loses the last 2 bars. This seems rather counter-intuitive ? Stopping on blank is done in the abcm2ps version 3.7.0 I'm uploading just now. Ah yes, thanks. -- 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] About the choice of '!'
On Thu, Jul 24, 2003 at 11:51:43AM +0200, Forgeot Eric wrote: Let's see; if I read this correctly, then in the line: ...|!dead!trill!beef|... the !dead! would be the decoration, and the staff break would come in the middle of the bar. Right? Good point, but generally people who are using one system (who belong to the abc2win sect for ex., or in the opposite to the abcm2ps sect) won't use the other one. A couple of other people have given examples like this /.../ But if we include both in the standard, we can assume that people and programs will soon start using both, I thought with the new standard the ! as line break was supposed to be still supported for backward compatibility, and only tolerated, with advice to avoid to use both, or to use with care. just one person's usage Now that ! staffbreak is available in abcm2ps, it's a reasonable assumption that I'll start using it, because it'll do good things to the legibility of my source, and because I can hope that most people will have access to programs that'll deal with it. I'm still wary of the !decorations!, because I'm not sure how portable they are. But, at the moment I have tr, D.C., etc, in guitar chords, as the only alternative, and that's not good either, so I may well start using !decorations!. In which case the 2 different ! constructions will be mixed together in the same line wherever they have to be. -- 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
