[abcusers] Laurie Griffiths : sad news
I have some sad news that I expect many members of this list would like to know. Laurie Griffiths was a regular contributor to the list and sooner or later I expect you would be wondering Where is Laurie? Laurie Griffiths was killed a few days ago in a road accident. I believe he was walking near his house in Southampton at the time, but I don't know the details. As well as writing Muse and playing fiddle in Spike Island Band, Laurie was active in the folk dance scene in Southampton, which was how I got hear of this. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The F F (and F F2) problems
On Sat 25 May 2002 at 09:39AM -0400, Laura Conrad wrote: Actually, abc2midi formerly assumed R:Hornpipe whenever you used F F. And then assumed a different split of time, which was appropriate for the way someone somewhere plays hornpipes. And when the inconsistency between abc2midi and the standard was pointed out, the author of abc2midi decided that consistency was more important than correctness, so he provided a workaround, rather than a fix. The inconsistency is deliberate. The point is that when you play a hornpipe or anything else with dotted rhythm (or swing, or whatever you want to call it), keeping a 3:1 ratio is rather harder than keeping a 2:1 ratio and doesn't really add much musically apart from a certain pedantic pleasure in knowing that you are playing exactly what your notation says. This is why abc2midi makes the assumption that ab is meant to be played as a 2:1 ratio. I think this is in accordance with the original spirit of '' even if this is not spelt out in the standard. The effect of R:Hornpipe in abc2midi is to introduce '' between 1/8 notes so that a piece written as a reel will come out sounding like a hornpipe. Because there is this aethetically displeasing discrepancy between notation and performance, I have taken the view that '' is a function to be used only in a very specific setting and trying to generalize it for other uses is courting trouble. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Linux abc HOWTO
On Thu 09 May 2002 at 01:05PM +, John Chambers wrote: Last January, James Allwright wrote: | I have written a first draft of a Linux abc HOWTO and am seeking | people to review it and write bits for it. This is | a document about how to solve Linux problems that you might have | when using abc, not about abc notation itself. I'm particularly | keen to have sections on printing under Linux and more on setting up | sound cards. If you are willing to review and maybe add bits to | it, let me know and I will e-mail you a copy. With a bit of luck, | the document will be ready to put on the web in a few weeks | time. So how's it going? Is it on the Web yet? Yes it is, but its not a full-blown HOWTO, just a web page with some hopefully useful stuff on it. I don't have the URL to hand, but there is a link to it from the abcMIDI home on sourceforge : http://abc.sourceforge.net/abMIDI/ James To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Which field for melodic codes?
On Sun 14 Apr 2002 at 10:19PM +0100, Phil Taylor wrote: I'm asking this on behalf of a friend who is considering starting a large transcription project, entering music into abc. He wants to use Gore or Breathnach's melodic codes to simplify searching. The question is, what field to use? My personal opinion is that such an important entry needs a field to itself. Is it time perhaps to re-cycle the I: field, used long ago to set tempo by playabc, but long superceded by the Q: field? Or should a new lower-case field be considered? The abc2midi parser makes use of the I: field, allowing it to contain things like octave=2 . If you want to fit in with this scheme, you could choose a new named field and write something like melodic= . Otherwise, a %% field would be good option. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Complex Chords in ABC
On Sun 03 Mar 2002 at 10:26AM -0300, Luis Pablo Gasparotto wrote: I think the problem isn't the ABC-to-MIDI parsing because programs like abcMIDI allows you to define chords using %%MIDI chordname in the tune head. So if you like to use an m7(b5) chord like Cm7(b5) you will need to add: %%MIDI chordname m7(b5) 0 3 6 10 I think the problem is in the ABC-to-ABC stuff when transposing chords. I transpose Cm7(b5) six steps up (ninth for alto saxophone) this chord becomes in Am7(gb5). It parses b like a note and not like a flat. You cannot use brackets () within a chord name because these are used to indicate an alternative chord. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The X: field
On Wed 06 Mar 2002 at 12:14PM +, Erik Ronström wrote: I have been wondering about this all since I first come across abc, but I haven't figured it out yet and I have never thought of asking until now. Anyway: Is there a good reason why the X: field is required? * It is not nessecary to separate the tunes since an empty line is used for that purpose. If you have arbitrary text in with the abc, the X: field is useful to mark the start of the tune. Also, some programs allow you to select a set of tunes using the X: field. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
On Wed 06 Feb 2002 at 12:20PM -0500, [EMAIL PROTECTED] wrote: On Wed, 6 Feb 2002, James Allwright wrote: It would also be nice to find a written standard to support the interpreation, since the only definition I can find says nothing about ties and so implies that the accidental is necessary. I just took a look at the draft standard, and it doesn't appear to say anything about accidentals remaining in effect until the end of the bar, either. Maybe I'm not looking in the right place. I'm talking about a standard for interpreting staff notation, not abc. As far as I am aware, no such standard exists, so the best you can do is look in textbooks on music and see what the authors of those have to say. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
On Wed 06 Feb 2002 at 12:26PM +0100, Atte Andre Jensen wrote: James Allwright, will you please reconsider changing the behavior of abc2midi so that it interprets ^F-|F as ^F-|^F and not ^F|=F, since it's widely agreed here on the list that that would be the prober way of understanding this??? In view of this popularly of this interpretation, I'm willing to accept a patch to implement this behaviour. It would also be nice to find a written standard to support the interpreation, since the only definition I can find says nothing about ties and so implies that the accidental is necessary. Please observe that abc2midi is open source so that you can fix things yourself if need be. I am unlikely to get round to trying to change this myself for a while, though I have now documented it. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc2abc crashes
On Sun 03 Feb 2002 at 09:04AM +0100, Atte Andre Jensen wrote: Hi, maybe it's not a big achievement, but I just made abc2abc (1.13) crash, by hitting it with this: X:1 T:Crash abc2abc with -t 2 M:4/4 L:1/4 C:Atte André Jensen K:D A#/Bz2 z2 | I don't see anything wrong in the example (do any of you?), so I think we have ourselves a bug... -- Atte Well done. There are almost certainly a few bugs still lurking in abc2abc and my other programs. Finding a bug also entitles you to submit a patch before anyone else and have your name immortalized in the history.txt file. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc2abc crashes
Atte, I tried your bit of abc on the latest version of abc2abc (1.14) and it didn't crash. Maybe you can send me a full bug report off-line and also tell me what OS you are running on. Thanks, James Allwright On Sun 03 Feb 2002 at 09:04AM +0100, Atte Andre Jensen wrote: Hi, maybe it's not a big achievement, but I just made abc2abc (1.13) crash, by hitting it with this: X:1 T:Crash abc2abc with -t 2 M:4/4 L:1/4 C:Atte André Jensen K:D A#/Bz2 z2 | I don't see anything wrong in the example (do any of you?), so I think we have ourselves a bug... -- Atte To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and midi
On Thu 31 Jan 2002 at 03:31PM +, John Chambers wrote: in the passage that discusses the scope of accidentals. The common modern rule is: An accidental persists to the next bar line or to the end of the note (including ties). I tried looking up the definition in a music textbook last night. It just said to the end of the bar, no mention of notes extending beyond bar ends. However, it could be that I need to invest in a better music textbook :-) . Of course, the thorny issue here is that you can't be sure you have a tied note until you work out what it's pitch is. I certainly think this is a potential pitfall worth documenting. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Jack Campin's Y
On Sat 12 Jan 2002 at 02:05AM +, Jack Campin wrote: is redundant. If you were merging the voices on to a single staff line, and you used ordinary rests, they'd print rests all over the melody. Non-printing rests are the way to go, and you wouldn't need to write as many of them if you had a multiple-bar non-printing-rest construct. This problem could be solved by introducing a rule that says multiple bar rests are not shown in merged lines. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: Initial repeats
On Tue 08 Jan 2002 at 09:14AM -0500, Laura Conrad wrote: James == James Allwright [EMAIL PROTECTED] writes: James Someone incorrectly writes: : James is adamant that abc2midi won't play a repeat unless there's : a balanced begin/end. James Damn! Take a day off work and someone decides to put nonsense words James in your mouth! Just for the record, abc2midi does have code in there James to guess the start of repeats when the start of repeat is missing. It was me. If there's code in there, it doesn't work consistently. Attached is a score with four parts, two of which (like most printed music) don't have begin repeats at the beginning of the piece, and the MIDI file which results from running the score through abc2midi. This is not a reasonable test. Why would you be inconsistent in multi-voice music like this ? My recollection is that the guessing is turned off for very complicated cases on the grounds that if the user is capable of using these advanced features, they can get the repeats right and automagic correction is more likely to be a nuisance than a help. If you try a single voice with an end-repeat, you will find that the start-repeat is inserted by abc2midi. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] square bracket notation
On Sun 06 Jan 2002 at 12:33PM -0500, [EMAIL PROTECTED] wrote: I downloaded a few files off the internet to test my parser. I think I understand everything that I see in the abc notation except for one thing: there are some lines that seem to start with a square bracket ([) but there is no closing bracket and it doesn't seem to be part of a chord. What's this supposed to do, and which tool supports it? This is first and second ending of a repeat and it is described in the abc 1.6 standard: |1 - first variant ending, all one symbol | [1 - first variant ending as two symbols. Perhaps the linebreak is causing your parser to have problems ? James Allwright B|Add fdd|add fdd|BAB gfg|ece gfe|! [1 Add fdd|add fdd|fdB AGF|GEF GF:|! [2 afa bgb|afa gfe|fdB AGF|GEF GF|]! From the standard: First and second repeats First and second repeats can be generated with the symbols [1 and [2, e.g. faf gfe|[1 dfe dBA:|[2 d2e dcB|]. When adjacent to bar lines, these can be shortened to |1 and :|2, but with regard to spaces | [1 is legal, | 1 is not. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Linux abc HOWTO
I have written a first draft of a Linux abc HOWTO and am seeking people to review it and write bits for it. This is a document about how to solve Linux problems that you might have when using abc, not about abc notation itself. I'm particularly keen to have sections on printing under Linux and more on setting up sound cards. If you are willing to review and maybe add bits to it, let me know and I will e-mail you a copy. With a bit of luck, the document will be ready to put on the web in a few weeks time. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Linux abc HOWTO
I am toying with the idea of writing a Linux abc HOWTO. This would cover: * what abc software is available for Linux and where to get it. * What you need to do to play MIDI files. * What you need to do to display music on-screen. * How to go about printing music. What it wouldn't cover would be how to write abc - there are already plenty of references for this. Hopefully for most of the more technical bits I can just refer to one of the existing HOWTO documents. The idea is that this will stop the Linux abc user from getting stuck on a problem such as setting up their sound card (something which took me quite a while). Before I get started on this, has anyone already written a document along these lines ? James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Initial repeats
On Tue 18 Dec 2001 at 01:00PM +, Erik Ronström wrote: Consider standard music notation: My theory is that once upon a time, the repeat sign consisted of two dots (:), and always coincided with a bar line. An interesting theory, but I don't buy it because your symbol is symmetrical and so you can't tell the difference between a start repeat and a end repeat. Suppose your music has the form A |: B :| C |: D :| E you are now in big trouble if you can't tell the difference between a start repeat and an end repeat. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: Initial repeats
Someone incorrectly writes: : James is adamant that abc2midi won't play a repeat unless there's : a balanced begin/end. Damn! Take a day off work and someone decides to put nonsense words in your mouth! Just for the record, abc2midi does have code in there to guess the start of repeats when the start of repeat is missing. My point is that missing out a start repeat is bad notation; an anacrusis at the start of a piece generates ambiguity and I think you will be hard pressed to find a music textbook that legitimizes the process of missing off start repeats. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multiple Endings
On Thu 13 Dec 2001 at 11:57AM +, Phil Taylor wrote: When John first suggested multiple alternate endings and repeats of 2 times I thought it was a good idea and started to implement it in BarFly. Getting it to display was easy, but getting it to play correctly turned out to be a nightmare, to the extent that after working on it for several days I gave up and pulled all the new code out. There were all sorts of problems. Of course that does not mean that it can't be done, just that it ain't as easy as it looks at first sight. abc2midi should handle alternate endings - it took some thinking about, but I'm reasonably confident that it does actually work. A few things to consider when discussing repeat syntax: * It has to coexist happily with other methods of specifying repeats, such as the P: field in the header, and not rule out the use of conventional musical indirection (e.g. using the Segno). (A lot of people would like to use that.) The P: field is currently the way to generate more than 2 times through a section. So far I haven't attempted to implement segno/coda based repeats. * If we can have multiple alternate endings, why not multiple alternate segments within a repeat, not necessarily at the end? This is common in pipe music, and we have seen requests for it on this list. The problem is how you notate the end of a segment - this is not imediately obvious to me. * It is very common to see repeats written as: abc |[1 abc :|[2 cba :| which is wrong (the last repeat should be written as || or |]), and is explicitly forbidden by the 1.6 standard. At the moment, because it's so common BarFly lets it go without comment, but what should be done here? Should it be treated as an instruction to repeat the section four times with endings 1,2,1,2, or should it generate an error? I would say an error / warning. * We need a clear set of rules as to where repeats should start from. At present, when it encounters a repeat BarFly searches backwards for one of the following symbols: |:, ||, |], [|, a P: field, or the start of the tune. This seems to give the least problems, but it does mean that you can't use a double bar or thin/thick bar within a repeat. I think it is reasonable to require |: at the start of a repeat section and issue a warning if it has been missed out. By require, I mean that a player program might ignore the end repeat if there is no start repeat and just play once through. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multiple Endings
On Thu 13 Dec 2001 at 03:30PM +, John Chambers wrote: How about a reminder of the best place to get the current version? http://abc.sourceforge.net/abcMIDI/ James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multiple Endings
On Thu 13 Dec 2001 at 03:24PM +, John Chambers wrote: | * We also need a (preferably illustrated) description of how the various | repeats are to be displayed in conventional notation. If we have a | 4x repeat - |:::...:::|, should that be displayed with four dots | arranged vertically next to the bar line? I have seen that symbol used | in music where the context suggests that a normal single repeat is what | is intended (e.g. in the Original Sacred Harp). As a concrete suggestion for the multiple repeat syntax, how about: !4x!|: ...:| The idea being that 4x is attached to the immediately following start repeat by a printer program and detected as the repeat count by a player program. If the printer program wants to use lots of dots or other clever stuff to indicate a strange repeat, then it can, but that doesn't show up in the abc. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is philosophy
On Mon 10 Dec 2001 at 01:05PM +0100, Simon Wascher wrote: Hello, I think the main topic here is about abc format philosophy. Laurie Griffiths: Why have these alternatives? They add nothing to the expressiveness of the language. To me a syntax should allow to write everything that does not harm its integrity. It is not the target to tell how a text must be written, but how it must not be written. Any expression a person wants to use should be legal as long as it does not collide with the integrity of the syntax. In short, why Occam's Razor instead of Occam's entire workshop of shaving instruments ? I think the answer is that you want people to actually write programs that will do things with abc. The more encrusted with options and strange cases a language becomes, the harder it is write a parser for it and the more likely that the parser will have bugs in at the end of it all. Also, the harder it becomes to add further encrustations at a later stage. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
On Fri 07 Dec 2001 at 01:38PM +0100, Simon Wascher wrote: I could *not* live with such a solution. It *must* be possible to use words for describing tempo whithout having to define them in numbers. A man's life hangs in the balance here, depending on the finer points of abc syntax. Clearly this is important stuff. :-) James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Sharps 'n flats
On Fri 07 Dec 2001 at 11:57AM +, Erik Ronström wrote: What the accidentals =, ^, _ mean? Are they absolute (e g _e means e flat) or are they in relation to the key (e g =e means e flat in Bb major)? Accidentals are absolute, which is how they are in standard stave notation. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
On Thu 29 Nov 2001 at 10:40AM -, Laurie Griffiths wrote: Not so. This is back to the question of does the notation tell the program what to print or does it describe the music. The answer is that it describes the music and software can figure out how to express that in any other medium (for instance sound waves, MIDI codes or tadpoles on 5 bar gates). I *suggest* that a good thing to print for this case would be note shape denoting old beat = note shape denoting new beat If you want to do this sort of thing, my suggestion (based on personal taste rather than historical precedent) would be to use an arrow rather than an equals sign in the printed output. Using an equals sign to indicate a change only really makes sense if you are a programmer (but not a Pascal programmer). I can't recall actually having seen this notation used. Morris tunes frequently have slows, where a passage is played at half speed and this is normally notated by using notes of double the length. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Progress towards a new abc standard
For those who have wondered what got discussed by the abc standards
committee, here is a summary of our discussion. The section numbers
referred to can be found at
http://abc.sourceforge.net/standard-propose/
James Allwright
This is a summary of the new features proposed in the new abc standard :
Section Feature Description
--- --- ---
2.1.0.3F:File name
2.1.0.3U:Macro definition
3.13.0.1
3.13.0.2
2.1.0.3w:lyrics aligned with tune
2.1.0.6K:global accidentals
2.1.0.6K:clef specifier with clef= and without
3.9.0.2
3.2.0.4//Multiple / to specify note length
3.9.0.4[]In-line fields
3.11.0.2 A{g}AGrace notes within broken rhythm
3.12.0.2 THLMPSpre-defined musical symbols
3.12.0.4 ! ! musical terms and symbols list
3.15.0.2 Accompaniment chord format
3.15.0.3/ Meaning of / within an accompaniment chord
3.15.0.4() Alternate chords
3.16.0.1 _@ Text Annotation
3.18.0.1 Q:Beat unit
Sections where the committee all agree:
3.2.0.4//
3.9.0.4[]
3.11.0.2 A{g}A
3.15.0.4()
3.16.0.1 _@
Sections needing minor modification:
2.1.0.3F:
2.1.0.3w:
2.1.0.9Note lengths
Sections needing much work:
2.1.0.3U:
3.13.0.1
3.13.0.2
2.1.0.6K: (GAs)
2.1.0.6K: (clefs)
3.9.0.2
3.12.0.2 THLMPS
3.12.0.4 ! !
3.15.0.2
3.18.0.1 Q:
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Arbitrary-text syntax versus arbitrary-text semantics
Reading this post gave me a sense of deja vu. On Fri 23 Nov 2001 at 07:53PM -0500, Buddha Buck wrote: One of the arguments I keep hearing against a free-text tempo header is that there are already many ways of placing arbitrary text into a tune -- usually using the guitar chord notation, or variants on the accent notation. I don't think that's a valid argument. The problem I see is that there are several ways to place free text into a tune, but they are not equivalent, and none are meant for placing free text into a tune. Chord notation is not free text. It is a chord. There may be no restriction to the syntax of a chord to be presented, but semantically, it's a chord. Placing tempo information into a chord isn't a correct semantic match. Quite true. The _ notation was proposed because people kept using the chord notation for things that weren't chords. James Allwright recently answered a question of mine (based on a proposal for a q: field) as follows: Would this make it impossible to transcribe music which is supposed to be played Placidly in the main, except for a passage which is supposed to be played Excitedly? Use _Excitedly in the middle of the tune and then go back with _Placidly. My major objection to that is that _Excitedly and _Placidly are not tempo indicators. They may print out in tadpoles as tempo indicators, but they will not be read by human readers of the ABC notation, nor by playback programs, as tempo indicators. Should we expect a live musician, playing from ABC notation, to treat _Excitedly as a tempo indicator? It doesn't look like one. Semantically, it isn't one. Semantically, it's something else. In practical terms, I think we are talking about having different fonts for different things in a printing program. I also think we have to assume that a player can use context i.e. infer a meaning from a word, which is presumably how they did things in the old days of handwritten manuscripts. yaps supports ! ! for musical instructions which seems to be the closest thing to a text tempo field and, yes, you can give it its own font. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Arbitrary-text syntax versus arbitrary-text semantics
On Tue 27 Nov 2001 at 06:33AM -0500, Laura Conrad wrote: James == James Allwright [EMAIL PROTECTED] writes: James yaps supports ! ! for musical instructions which seems to be the closest James thing to a text tempo field and, yes, you can give it its own font. Can you change the font within a tune? I know abc2ps doesn't allow this for some font definitions (gchordfont being the one I've tried). Hey, did I pay you to ask that question :-) ? Strangely enough, yaps sets up fonts in a different way to abc2ps, which should let you change fonts mid-tune. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
On Thu 22 Nov 2001 at 04:52PM +, Jack Campin wrote: No it isn't. A typical dance tune book will use reel time or waltz tempo the same way all through. In the Kurdish song book I quoted, the same Italian tempo terms are used over and over again and are NEVER defined at the beginning of a tune. There wouldn't be any point in tempo terms unless they had an understood meaning in a context wider than an individual tune. Today, everybody who has a metronome uses the commonest 8 or so Italian terms in the same way to about 1% precision because they're engraved on the scale, and I would guess the world contains a few million more metronome users than ABC users. As someone who doesn't own a metronome, this is new information to me. If everyone who has a metronome posts these numbers, then maybe we will find that they all agree and we will have the basis for a useful standard. Likewise, perhaps you could post a list of military march tempos. Where pre-existing standards exist, then providing support for them in abc does seem like a good idea. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] how to change L:
Try abc2abc. This has options for doubling up and halving the L: value used. I usually stick with one L: value for a tune though; swapping about would make it too confusing to read in my opinion. James Allwright On Wed 21 Nov 2001 at 11:06PM +0100, Simon Wascher wrote: Hello, from time to time I come across abc text where I want to change the L: value, to say it more precise the value of one letter in the text, for the whole tune, after it is written. often it is that I want to change a tune from: `a/b/c/d/ ag b2' to `abcd a2g2 b4' Is there a tool that can perform such a change ? there is some idea in my mind of an ideal tool which counts the noteheads i.e. the number of characters needed at differen L:values, so it is possible to optimize/minimize the number of characters needed by telling which is the best L: value for a short text (in the short example above, its 14 vs. 12 characters - last but not least this means compressing the tune size about 1/7, often it will be much more). Simon Wascher To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
On Thu 22 Nov 2001 at 12:22AM +, Jack Campin wrote: That says exactly nothing about the semantics. Unless your q: field provides me with a way of DEFINING those strings in a musically intuitive way so that a numerical playback speed can be statically deduced from the musical text (e.g. by a playback program), there is no point in what you're suggesting. There are already about 10 different ways to put uninterpreted text into a tune header, we *do not* need another one. The problem I have with the definition idea is that definitions are only useful if you re-use the definition. If a term is defined at the beginning of a tune, used once and then lost there is no point in having it. This seems to be how written tempos are normally used. It seems we haven't even agreed what the problem is. I think it will be difficult to agree on a solution. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
In an attempt to wrap up this thread, would the following proposal for a new field meet everyone's requirements ? Field Name: q:playing style Header: Yes Tune Body: No Description: Contains a written non-numerical description of the tune's tempo or mood. Examples: q:Allegro q:Lento James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
On Fri 16 Nov 2001 at 04:20PM -0800, John Walsh wrote: I haven't been following closely enough to be sure, but I have the impression that the idea of basing the tempo on the L: field has been pretty well discarded, except possibly as a legacy from abc 1.6 in the (deprecated) Q:120 syntax. True? I hope so, since it's an unstable indicator: there can be times when the user makes an in-line change of the L: field to accomodate, say, a couple of bars chock-full of 1/32 notes---makes it easier to write, and to read too, for that matter--- and it's a bit disconcerting to hear the playback speed up by a factor of four for for just those bars. This was resolved ages ago. Q:120 takes the value of unit note length from the header. If there is a new L: field in the body of the tune, the tempo does not change with it because (as you point out) this would result in nonsense. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
On Mon 19 Nov 2001 at 01:34PM -, Laurie Griffiths wrote: Some people (I think it was Frank that started it) say (and I'm putting words into their mouths) Look, the Q: syntax is all very well for controlling the speed of a player program, but what I want to be able to do is to say 'play this at an Allegro speed' (or 'Lento' or some other word whose meaning I know. And what 'Allegro' means is about 120 per minute. I don't mind writing down what Allegro means once, but I shouldn't have to write it every time. I mean Allegro is Allegro. I think we need to know whether Allegro is one of a small set of well-defined tempo descriptors (in which case it would be really nice to have the complete set together with their definitions) or one tempo definition in a large and vague set that spans the complete Italian language and is interpreted at the performer's discretion. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something fairly complicated (Q: field)
On Thu 15 Nov 2001 at 02:33PM -, Laurie Griffiths wrote: The point is that 120 (or Allegro) means 120 of something or other every minute. This is where the problem is. Allegro needs to be defined as 120 3/8 notes per minute or 180 1/4 notes per minute, so that we don't get left wondering what the something is. Assigning 120 to the word Allegro does not capture the way this term is used in the musical world. If you avoid this step, you can avoid worrying about the beat altogether. We don't need to know what the beat is with our existing syntax and we can manage without it in any new syntax as well. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Windows XP issue solution
There is some information on this XP problem at: http://members.home.net/alexfein/Articles/FileSearch.htm James Allwright On Thu 15 Nov 2001 at 08:26PM +, Steve Mansfield wrote: Microsoft have made a change to the way in which the Search facility works in Windows XP compared to previous versions of Windows. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Windows XP issue solution
Oops, I see that Steve Mansfield's site already has that link. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something fairly complicated (Q: field)
On Thu 15 Nov 2001 at 01:07AM -, Laurie Griffiths wrote: Is there any mileage in something like Q:Allegro=120 % definition ... Q:3/8=Allegro % use, meaning that the beat is 3/8 in this case No mileage in my book. The word Allegro describes the whole tempo [Q:3/8=120] not just one number used to define it. Maybe I missed the point of your posting. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something fairly complicated (Q: field)
Having watched this debate for a while, I feel obliged to make a comment. I think what is actually wanted is the ability to write Q:allegro because the word allegro was the tempo indicator in the original score. If a player program recognizes this and picks an appropriate tempo, then all is well. I believe that there are only a finite number of italian words used to indicate musical tempo, so this approach should actually be possible. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] possible abctab2ps extensions
On Mon 12 Nov 2001 at 07:21PM +0100, Christoph Dalitz wrote: James Allwright wrote: I wrote line break because I do not understand the abc guitar chords only as guitar chords, but more general as arbitrary text printed above a note. This includes guitar chords, basso continuo figures and dynamic marks. The problem of abritrary text has come up before and _ is the agreed syntax for arbitrary text - hopefully you support this in a similar way. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
On Tue 13 Nov 2001 at 08:13AM -0500, Laura Conrad wrote: Phil == Phil Taylor [EMAIL PROTECTED] writes: Lilypond, which is the printing program I'm actually using these days, has a MIDI block and a score block, so the two speeds are actually completely independent unless you do something to set up a macro to make them the same. I guess this is a bit like folk music, where the notes that are written down and the ones that actually get played are independent of each other :-) James To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] help
On Sat 10 Nov 2001 at 06:39PM +0100, Frank Nordberg wrote: Jack Campin wrote: The solution is to put everything inside a single pair of quotes with spaces between the individual chord symbols, such as: CCDEF|CE2 Dm7 G7D2|C F CC4|] How is a player program supposed to know how to time those chords? As far as I know, no playback program is able to interpret this at all. Multiple chord symbols on a single note is certainly yet another issue that could be adressed in a future version of the standard. You can do multiple chord symbols already in yaps with e.g. Dm7 G D2 The current standard implies that this is how it should be done. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Special characters in PostScript
On Fri 09 Nov 2001 at 11:18AM -0600, Taral wrote: On Fri, Nov 09, 2001 at 09:47:25AM +, James Allwright wrote: Well, no-one has requested this, but I thought I'd post it all the same. This is my little bit of PostScript to insert sharp and flat symbols in a text string. It works, but the new symbols look out of place. I recommend using a font instead of this... the rendering engine is far better about making things look 'in place'. Also, overriding '#' and 'b' especially seems to be kind of over-the-top... better to create new symbols /sharp and /flat and let the user create appropriate encodings. If necessary, I'll code it up for anyone who wants. Yes please, I'd like to see how this approach works. There are no sharp and flat characters in the standard character sets for PostScript, so you need to get your own glyphs in there somehow. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
On Mon 12 Nov 2001 at 12:58PM +0100, Frank Nordberg wrote: I know I sometimes expect too much from the programmers. Like so many non-programmers I tend to view them as some kind of magicians always ready to pull a handful of miracles out of their sleeve. If you tell me you can't do it this time, I guess I just have to accept that. But at least give it a serious try! Please! :-) What programmers cannot do is re-write applications retrospectively. Adding new syntax that is incompatible with the old syntax causes hassles for everyone who uses abc. That is why it important for new ideas to make use of existing syntax and be added in harmoniously if at all possible. Rather than propose specific syntax, maybe you need to be saying I'd like this new feature, what syntax do we need to support it? . James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] possible abctab2ps extensions
On Mon 12 Nov 2001 at 04:18PM +0100, Christoph Dalitz wrote: Before I introduce some other incompatible set of abc extensions, I would like to ask the other devellopers whether and how they already have addressed some of the following issues. 1) figured bass Both abctab2p2 and abcm2ps support line breaks (\n) and accidentals (\# \b \=) in guitar chords; I have adopted the syntax of abcm2ps in order to be compatible. I am not sure what a line break character would mean in the context of a guitar chord. I allow ; as a shorthand for two guitar chords together e.g. A Db could be written as A;Db These are printed out one above the other by yaps. Is this what you mean ? 4) more clef types There are 3 different clefs (G, C and F) which can appear on different staff lines. Which names are currently used for the various clefs in the different abc-programs? What identifiers are used for the french violin clef (G1) for instance? From memory, yaps supports clef=bass, treble, soprano, mezzosoprano, and alto. These are all names that came out of one of my music textbooks. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE : The day the music died! voting for abc standard
On Thu 01 Nov 2001 at 01:22PM -0500, Laura Conrad wrote: James == James Allwright [EMAIL PROTECTED] writes: James On Thu 01 Nov 2001 at 04:59PM +0100, Forgeot Eric wrote: Sharps, flats and natural signs may be indicated in guitar chords using '\#', '\b' and '\='. James Sharps and flats are already indicated in guitar chords with # and b ! Yes, but they don't typeset right. Maybe, maybe not, depending on what program you use, but this is nothing to do with the standard. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE : The day the music died! voting for abc standard
On Fri 02 Nov 2001 at 06:48AM -0500, Laura Conrad wrote: James == James Allwright [EMAIL PROTECTED] writes: James == James Allwright [EMAIL PROTECTED] writes: James On Thu 01 Nov 2001 at 04:59PM +0100, Forgeot Eric wrote: Sharps, flats and natural signs may be indicated in guitar chords using '\#', '\b' and '\='. James Sharps and flats are already indicated in guitar chords with # and b ! Yes, but they don't typeset right. James Maybe, maybe not, depending on what program you use, but this is nothing James to do with the standard. The lack of a standard way to indicate natural certainly is. Ok, you have a point here, but I've never actually seen natural signs used in chords. The lack of a way to differentiate between lower case b and flat sign is, too, in my opinion. The obvious test to use is that b or # is the second character in the chord after A-G. I did at one point create a version of the PostScript 'show' command that identified b and # and replaced them with the appropriate sharp and flat graphics. Unfortunately the results looked so bad that I decided to stick with b and # for yaps. If anyone wants to play with this, I'm happy to give them my bit of code. What is really needed is good PostScript graphics for the accidentals that fit in with the character set used for chords. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] What is Figured Base ?
On Fri 02 Nov 2001 at 09:32AM -0500, Laura Conrad wrote: James == James Allwright [EMAIL PROTECTED] writes: James Ok, you have a point here, but I've never actually seen natural signs James used in chords. Maybe not, but they're used in figured bass all the time. And the chord syntax is one of the possible ways to notate figured bass in ABC. Can you explain what figured bass is ? This isn't a term that I recognize. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multivoice doc
On Wed 31 Oct 2001 at 04:28PM +, Phil Taylor wrote: James Allwright wrote: It is still possible for someone who cares about an abc standard to help the process along; get hold of every abc program you can, go through them carefully and then document the compatibilities and incompatibilities carefully on the web I started to do something similar to this with respect to the V: field. It proved to be very hard work. It is still incomplete, and almost certainly contains errors, but you can read the results at: http://www.barfly.dial.pipex.com/multivoice.txt This seems to be a very good document, covering not just V:, but a lot of other things as well. Corrections and additions are very welcome. I have a minor correction and (if the abc2ps family supported it) it would then display correctly in those programs. While the middle directive can be used to shift the display pitch by any amount, it should normally only be used to shift the position by a multiple of an octave. Yaps supports a simpler version of this, where the directive octave=-2 would cause the notes to be drawn two octaves lower than their nominal pitch. abcm2ps can decide automatically which clef to use if no clef is explicitly indicated. This explanation of octave= is not quite right. I suggest the re-wording Yaps and abc2midi support a simpler version of this, where the directive octave=-2 causes every note to be treated as having a pitch two octaves below the written pitch. The point being that it is not just drawing of the notes that is affected, but playing them too. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics (was)
On Wed 31 Oct 2001 at 05:17AM -0500, [EMAIL PROTECTED] wrote: There seems to be some confusion here. Has the standards committee decided anything or not? Could we have a clear statement from the committee (rather than individual members) on what it has achieved and its current status? I don't think you'll ever get the standards committee to speak as one person with a unified voice. My opinion is similar to Phil's. I took the approach of identifying all the new features in the new draft standard and seeing which ones were universally approved and which ones were not. This seemed like a good way to make progress, and I got the impression that disagreement was restricted to relatively minor features and obscure options of major features. However, the thread petered out without any definite conclusions; people were either not interested in this approach or distracted by other projects. It is still possible for someone who cares about an abc standard to help the process along; get hold of every abc program you can, go through them carefully and then document the compatibilities and incompatibilities carefully on the web. If you do this carefully and comprehensively enough it be a valuable resource to guide any new abc developer on interpreting the more subtle aspects of abc. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Software libraries
On Fri 26 Oct 2001 at 03:50PM +0100, Jack Campin wrote: One problem with using a common library: turnaround time for bugfixes. Some of the most-used ABC applications out there get updated no more than yearly, others get fixed within days of having a bug reported. If a bug is discovered in a library, this adds a new source of delay; the library maintainer will need to work fast to keep up with the quickest application developers. For some specialized library functions the open-source model might not help all that much as there might only be one developer in the group who understands what the code is supposed to do. I agree that there is not really much point in making your code open-source if no-one else can read it. Good software should be organized so that you can fix parts of it without understanding the whole lot. Once a library bug has been identified, I expect that rapid-updating developers will fix it themselves rather than wait for the official bugfix to filter through. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc libraries
On Tue 23 Oct 2001 at 04:04PM +0100, Phil Taylor wrote: James Allwright wrote: Some time ago I toyed with the idea of creating an intermediate level format (ILF) which would make it easier for developers to create new tools. We would then have separate programs for abc - ILF ILF - PostScript / Display on Screen ILF - MIDI The idea is that the ILF is read and written by computer and designed to be very simple to parse. All this seemed like quite a lot of work, so I never got very far. Yes, I thought about that too. It's an appealing idea, but the problem is that the ILF has to be very comprehensive because it has to represent absolutely anything which is found in music, otherwise future extensions to abc will invalidate it. You end up with something which is just as hard to parse as abc. Yes, you are probably right. However, an ILF which describes printed music only might just work. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Gloggauer Liederbuch
On Wed 24 Oct 2001 at 10:57AM -0400, [EMAIL PROTECTED] wrote: On Wed, 24 Oct 2001, Simon Wascher wrote: Baerenreiter does indeed own the copyright on the actuall layout, the picture of the print, but never does or did own the musical composition itself. IANAL, but they do own the copyright on all of the editorial changes they made, so for all intents and purposes, the music itself is copyrighted. PEYA (please expand your acronym). James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics
On Mon 22 Oct 2001 at 06:05PM -0500, Taral wrote: On Mon, Oct 22, 2001 at 06:14:17PM -0400, Laura Conrad wrote: I think what's being proposed is that: a-a is two tied notes a--a is two notes tied with a dashed tie a-.a is two notes died with a dotted tie a-.a currently means an ordinary a tied to a staccato a. You need to find a different notation to make this unambiguous. (ab) is two slurred notes .(ab.) (or maybe some other syntax) is two notes with a dotted slur. -(ab-) is two notes slurred with a dashed slur. This looks like the a and the b are tied to other notes. I think you need to change the notation to make this unambiguous. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics
On Sat 20 Oct 2001 at 05:41AM -0700, Aaron Newman wrote:
I read in the FAQ that there is no way now to do dynamics in the official
ABC language. How are people handling this?
abc2midi uses !p! !pp! !f! !fff! and so on.
I am working on a (yet another) free ABC music editing and display program,
and for some reason I overlooked this originally.
Also, I would also like the language to be able to handle jazz, so I would
be adding some additional note ornaments ('doits', falls), how is this
recommended?
I suggest you use whichever of H-Z are not already being used elsewhere.
James Allwright
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Suggestions to the ABC Standard
There isn't a formal mechanism for doing this, I suggest you just post your suggestions to abcusers. Be warned that getting new features put into the standard doesn't mean that they will automatically be added to all abc programs; usually the developers have to thrash out the exact details of new syntax, even if they like a new feature enough to want to implement it. James Allwright On Mon 22 Oct 2001 at 04:01AM -0200, Paulo Eleuterio Tiburcio wrote: Hi, all. What are the rules for posting suggestions to the standard, if any? Is there a FAQ on that? Thanks in advance. Paulo Eleutério Tibúrcio To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] abc2midi filenames
Announcing the arrival of a new feature: I have just added an option to abc2midi which generates filenames from tune titles. By default these are limited to 8 characters for the benefit of simple filesystems, but there is another option which lets you change this limit. abc2midi can be found at http://abc.sourceforge.net/abcMIDI/ . James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] RPMs for abcMIDI
It seems that the web pages which had Ian Roberts RPM for abcMIDI have disappeared. I suspect that this is because Ian has left Oxford University and they've removed his web pages. So I have 3 general requests: (a) Does anyone know where Ian Roberts has gone ? (b) Does anyone else have a desire to maintain an RPM for abcMIDI ? (c) If no-one wants to maintain an RPM, I'd like to put Ian's one on sourceforge - can someone send me a copy ? (note for the uninitiated; RPMs are Red Hat Linux package files) Thanks, James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Voice limit on abc2midi?
The problem here is that channel 10 in General MIDI is reserved for percussion instruments as someone has pointed out. You may be able to re-program it to be a different instrument with %%MIDI program 10 instrument Alternatively, you can explicitly select channels for voices from voice 10 onwards with V:10 %%MIDI channel 11 V:11 %%MIDI channel 12 and so on. If you have voices using the same instrument, you should also be able to put them on the same channel, which may save up enough channels that you never reach channel 10. If you have a tone generator which is MIDI but not General MIDI, you will probably find you don't have a problem because you don't have the drums on channel 10. It seems a shame that the drums were put on channel 10 and not on the last channel, which would have made things easier. (I haven't tried out all the suggestions here, so the details might not be quite correct). James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] two hand notation examples
On Tue 02 Oct 2001 at 09:49AM -0400, Frank Carmickle wrote: Well let me toss some examples your way and see if anyone can help me. I didn't see the kind of notation I am looking for. X:1 T:foo C:bar L:1/4 M:3/4 K:d V:RH clef=treble V:LH clef=bass [V:RH] za-[ad,] [V:LH] D-[DA]-[DAf] Although this is readable it is not correct. the D in the left hand should be D3 not D-D-D. So something like this maybe? Inventing a way of writing abc so that you see D3 instead of D-D-D would be easy enough. The problem comes when you want to print it out as stave notation - the only way to do it is using ties, so there will be clever software that gets you back to D-[DA]-[DAf]. Is this what you have in mind ? Perhaps we need to know what you mean by not correct and what you are aiming for. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] merging voices
On Mon 01 Oct 2001 at 09:15AM +0200, Markus Lutz wrote: On Sat, 29 Sep 2001 09:54:50 +, Jack Campin wrote: JC On another note... I'm trying to print a 5-voice piece of music using JC yaps. I would like four voices to share two staves -- two on one JC staff, two on another, the fifth on it's own staff. The source I'm JC transcribing this from has that format, with voice indicated by stem JC directon, and it will allow me more room on the page for lyrics and JC notes (also to be embedded in the abc file). There doesn't seem to be JC anything clear in the yaps documentation available to me that would JC describe how to do that. JC JC Is there any way to do what I want using yaps? In any other JC abc-to-sheet-music converter (abc2mtex, etc?) JC You are correct in thinking that yaps does not support this feature. I have to admit that I find this business of putting two voices onto one staff a bit confusing. In general you are going to end up with two notes of different lengths being notated at the same time, which means you don't know when to start playing the next note. Unfortunately not all notes have stems, so the stem direction idea won't quite solve the problem. Perhaps you are meant to pick two voices which don't have this problem, or maybe you use ties to solve it (in which case there is scope for someone to write a voice-merging tool for abc). The fact that voice-merging appears to be a bit of a bodge, and that I have plenty of other projects to work on, has so far kept me from thinking very seriously about trying to support it. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ANNOUNCE: abcpp, an ABC preprocessor/converter
Looks interesting, where do I find it ? James On Mon 01 Oct 2001 at 12:44PM +0200, Guido Gonzato wrote: Hello, I have released abcpp, a preprocessor for ABC files. abcpp is a simple yet powerful preprocessor designed for, but not limited to, ABC music files. I wrote it for two reasons: first, I wanted to overcome incompatibilities between ABC packages; secondly, I wanted to be able to write portable and more readable ABC files. With abcpp you can convert files like this: #include italiano.abp Titolo: Let's try abcpp Autore: Guido Gonzato Metro: 4/4 #ifdef MIDI % let's please abc2midi Tempo: 1/4 = 100 LunghNota: 1/4 #else Tempo: Allegro, 1/4 = 100 #endif Chiave: DO % #define !tieni! !fermata! DO RE MI FA|SOL LA SI !tieni!do| into legal ABC files. abcpp supports several directives and macro definitions - your fantasy's the limit. abcpp is free software released under the GNU GPL. For suggestions, criticism, and bug reports, please feel free to contact me. Enjoy, Guido =8-) -- Guido Gonzato, Ph.D. ggonza at tin dot it - Linux system manager Universita' di Verona, Dipartimento Scientifico e Tecnologico Ca' Vignal II, Strada Le Grazie 15, 37134 Verona (Italy) Tel. +39 045 8027990; Fax Tel. +39 045 8027958 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] German H as an alternative to B
On Wed 29 Aug 2001 at 02:07PM -, Laurenz Wiskott wrote: Dear abcusers, in German notation we use an H instead of a B, so that the C-Scale becomes C D E F G A H c, and a B instead of a Bb, so that the F-Scale becomes F G A B c d e f. (I know it is not logical, but it has developed that way.) I therefore would like to suggest that in abc-format H and h become valid alternatives for B and b, respectively, in indicating the pitch of a note and the accompaniment chords. To avoid confusion, however, a German B, must then be indicated as Hb (or _H) and not as B. This is not really practical since H is already used by some programs to indicate a fermata. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] net-friendly information
On Thu 23 Aug 2001 at 12:43PM +0100, Richard Robinson wrote: On Fri, 17 Aug 2001, Jack Campin wrote: I have been looking round other people's transcriptions on the net over the last few days and I'm getting reminded of a few missing features of ABC that would make web-trawls for music more productive. - universal identifiers, along the lines of the Message-IDs used with email and Usenet postings. These tell you whether you've found another copy of something you've already got, and (if they have some internal structure, as Message-IDs usually do) can help direct you to the human who did the transcription or made it available. I wonder whether the X: line used for this, since I'm not sure what other use there is for it. Does any software currently use the X: line for anything (other than the ease-of-parsing start-of-tune marker) ? I think it was supposed to be a way of giving a unique id to each tune in a file ? Could it not be extended to give each tune a unique id on a system ? (and from there, add in machine info and get net-wide uniqueness ?). As Jack I think the safest way to extend the X: field would be leave a space after the number and then put your extension in e.g. X:5 fastpolkas.abc abc.sourceforge.net With a bit of luck, most software will read the number 5 and then ignore the rest of the line. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accents and other signs
On Mon 23 Jul 2001 at 09:09AM -0700, John Carson wrote: Dear ABCexperts: I have several questions concerned about the improvement of abcm2ps or abc2ps. Is there anyway we can type words under the staff?(i mean not the lyric). It will prove handy to add this function, as simple as the words above the staff, right? I have recently added an option that lets yaps place acompaniment chords below the stave instead of above it. I invented some abc2ps-like syntax for this, since I couldn't find an abc2ps switch. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accents and other signs
On Tue 17 Jul 2001 at 08:17PM +0100, Phil Taylor wrote: You could, for example, use a macro to substitute the letter Q for the text !invertedfermata! in the tune, and a suitable file of macros would allow the program to support the !symbol! format proposed in the draft standard. However, it's extremely clumsy, clutters up the abc with stuff between exclamation marks, breaks lots of tunes written by abc2win and is quite unnecessary, as you can already do this using the annotation format ^inverted fermata if you want. Furthermore, enabling macros for display purposes means that ornaments will be written out in full if they have associated macros, which is not usually what you want. I think there is a misunderstanding here. ^inverted fermata will write the text inverted fermata above a note. This is just a way of getting text printed above a note. If you want to see an inverted fermata symbol, you need something that recognizes invertedfermata as a macro name and calls up the relevant symbol (the proposed behaviour of ! !). Perhaps if you post an explanation of your alternative system, I will see the beauty of it. My objections to having H-Z attached to fixed symbols is two-fold : 1. It only allows us 19 different symbols. 2. A single character is much more cryptic than a name enclosed in ! ! James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accents and other signs
On Wed 18 Jul 2001 at 02:48PM +0100, Phil Taylor wrote: No misunderstanding. I'm suggesting that you could use a macro to recognise the text ^inverted fermata and substitute the letter Q for it before parsing, thus producing the symbol in the music. This would mean that you would no longer be able to write the text inverted fermata above a note. Instead of trying to overload in this way, introducing a new mechanism ! ! makes things much simpler. As implemented in yaps, this mechanism just writes out the text if yaps does not recognize the symbol, but this just a way of recovering from an error condition - it isn't meant to be the way ! ! is normally used. Programs which don't know what an inverted fermata is would simply write the text instead. As I understand it, that is how the !symbol! syntax is supposed to work, but without the necessity of introducing the exclamation mark. I don't really see this as a good solution. We could introduce another special character in so that *invertedfermata generates the symbol instead of text, but this is one extra character compared to ! !. If your objection is specifically to exclamation marks, we could use @ @, but this seems a bit ugly to me. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] software query: abc to MIDI, abc to score
On Wed 11 Jul 2001 at 10:38AM -0400, Laura Conrad wrote: When I found that abc2ps and its relatives (abcm2ps is probably the best-maintained at the moment) weren't suitable for my purposes, I started converting my abc files to lilypond, and publishing them that way. Frank seems to share this view. I'd be interested to know what makes lilypond so much better than the abc2ps clones. Is it some killer feature or just an accumulation of little features that lilypond does or does better ? James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] C Compilers (was linux only ?)
My favourite would be DJGPP: http://www.delorie.com/ which is a port of GCC and comes with lots of useful tools. If you want something that with fit on a single disk, I would suggest trying Pacific C http://www.htsoft.com/products/pacific.html Both of these will run under Windows, but don't have any special support for it. If you want that, you might try MINGW, which is a port of DJGPP: http://www.mingw.org/ Cheers, James Allwright On Mon 09 Jul 2001 at 10:26AM +0100, flos wrote: Right, where do I get a C compiler for Windows 98 SE? Flos To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] linux only ?
On Fri 06 Jul 2001 at 11:36AM +0200, Frank Nordberg wrote: 1. As far as I know both programs are single platform applications: BarFly is Mac only, and from Jean-Francois' site I gather that abcm2ps is Linux only. Unless it has changed radically since I last looked, it is a source code distribution that will compile and run on anything with a C compiler. Maybe it needs someone to compile it with DJGPP and put the executable on the web. I've been playing with Ghostscript under DOS recently. It turns out to be easy to make it generate image files which you can then view with your favourite image viewer. Perhaps we need someone to write a noddy front-end that invokes an abc2ps clone, ghostscript and then an image viewer to bring free abc typesetting to the masses. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accents and other signs
On Mon 02 Jul 2001 at 09:33PM +0100, Phil Taylor wrote: Reformulated is an understatement. That section of the draft standard is total mess. It confuses and conflates the ideas of redefinable symbols and macros, while introducing the totally unnecessary !text! construction. Actually, !text! was introduced by me into yaps and abc2midi. I use it for !coda! and !segno! special symbols in yaps and volume control !ff! !p! and so on in abc2midi. It is really just a way of adding new features (such as typographical characters) in a structured fashion. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] MIDI cat ?
On Mon 18 Jun 2001 at 05:07PM +0100, Phil Taylor wrote: I don't think you can do this by simply concatenating the MIDI files. I agree with this. Concatenating single track MIDI files could perhaps be done without too much analysis, but concatenating multiple track MIDI files would require quite a bit of analysis. It might be possible to write a utility to do the job in a day or so, but I've never felt the urge to write one, and I've never come across a utility to do it. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] De facto standards
On Fri 15 Jun 2001 at 10:15AM +0200, Frank Nordberg wrote: Gianni Cunich wrote: As we both know - as anybody else on this list, for the matter! - ABC2WIN is de facto the standard as far as the abc notation is employed on the web... Maybe all the old hands knows this, but it's news to a novice like me! Not only do I not know this, I also don't believe it. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] New abc2midi command
For all those plagued by the 2:1 ratio, help is at hand ! I have just uploaded a new version of abc2midi with a %%MIDI ratio command which controls how and are played. I blame it all on being allowed to learn hornpipes at an impressionable age in my musical upbringing. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
On Tue 12 Jun 2001 at 09:29PM +0200, Gianni Cunich wrote: Sorry, but I actually got bored about the discussion about the abc2midi behaviour...so bored I actually felt sick! The problem about the way abc2midi handles the broken rythms shortcut is that it actually playes (and save as midi) any beat using the symbol as a triplet, even if in the R: field you state the tune is a schottische (and English schottisches, at least the oldest ones, are usually played dotted, unlike the recent ones of the hornpipes), or a polka, or anything else... In other terms, the basic thuth is that ac2midi is not an abc compliant software, or, to say better, is unreliable...and that's all we can (and should) say about it! I have to disagree strongly here. My understanding of the ab construct is that it is specially for hornpipes and so you can use it for a 2:1 ratio if that is what you want elsewhere. If you want 3:1, then you can write a3/2b/2. The real culprits are the musicians who have been notating hornpipes in 4/4 when they should have been using 6/8 or 6/16. In other words, you are blaming a piece of software because real musicians have sloppy musical conventions! Remember that abc2midi is intended chiefly to produce playable MIDI files, not for back-conversion into notation programs. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] midi2abc (was: Wanted: ABC transcription...)
On Tue 12 Jun 2001 at 06:35AM -0400, Laura Conrad wrote: James == James Allwright [EMAIL PROTECTED] writes: James The cc construct is a problem because it is notated as a James 3:1 ratio but played as a 2:1 ratio. Played by whom? Does the standard document this? Played by abc2midi and played by most players of hornpipes, I believe. If you try changing abc2midi so that it uses a 3:1 ratio, you should find that hornpipes don't sound quite right. Of course, this is all subjective and maybe you play things a bit differently in Boston :-) . As far as I know this is not documented in the standard at all, since it is more musical knowledge than anything to do with abc. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multiple verses in abc2ps and relatives
On Thu 05 Apr 2001 at 11:34PM +, John Chambers wrote: Laura wrote: | Attached is a file of a tune with several verses. | | But then I forgot to attach it: My clone of abc2ps had the same problem, and I found it pretty quickly. If you have the source, there's a 1-byte change that will fix it. In abc2ps.h there are the lines: #define NWLINE 5 /* max number of vocal lines per staff */ ... char *wordp[NWLINE];/* pointers to wpool for vocals */ This is a hard limit of 5 w: lines per staff, and there's no runtine feechur for upping the number. So just change NWLINE to be a larger number and recompile. The right solution would make this dynamically sized, of course. I'll add this to my TODO file ... This is something that yaps does dynamically. I'd managed to hit the fixed limit in abc2ps before I started writing yaps. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Double notes / Breves
I have just added support for printing breves (which I assume the Americans call double notes) to yaps. The original abc2ps did not support this, so yaps didn't either (and presumably all the other abc2ps clones). James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] abc2midi implements /
I have just uploaded a new version of abc2midi which supports the "G/B" type notation to do inverted chords and chords with added bass notes. If you use this notation, please try it out and let me know whether it does what you expect. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes and key signatures (Was: Hi)
On Wed 07 Mar 2001 at 01:30AM +, John Chambers wrote: Wil writes: | But is there a compelling reason why we should not define | "E hejaz" or "E freygish"? (in a similar manner to the definition | proposed for chords) I have a further suggestion for handling arbitrary modes which promotes them to part of the abc, but doesn't require the application to know all possible modes; allow the K: field to have a mode= subfield. This will do the following: 1. Check the number of sharps and flats and give a warning if it does not correspond to the specified mode. 2. Work out the root note and either print root at an appropriate place for a typesetting program or something else appropriate for a player program. e.g. K:C ^b _f mode=hejaz will check to see if you really have specified hejaz mode. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes and key signatures (Was: Hi)
On Wed 07 Mar 2001 at 12:35AM +, Phil Taylor wrote: Wil wrote: But is there a compelling reason why we should not define "E hejaz" or "E freygish"? (in a similar manner to the definition proposed for chords) I assume we are talking about the K: field here, and I think there is a fairly compelling case against. Adding new modes ad hoc like this is not application-friendly. Currently, we know that the mode will be only one of 12 possibilities, so we can cover all cases. If an application does not recognize a mode, the rest of the file becomes just about useless. Writing something like K:C ^b _f % hejaz conveys the same information and is fully backwards-compatible. (I'm sure this example is wrong because I have no idea what hejaz is). Obviously there are many people who find mode information helpful and useful, but then again many people can manage perfectly well without it, so it seems a little unreasonable to force a full knowledge of modes onto anyone who wants to read abc. I hope I haven't stirred up too much of the religous ferver that this topic always seems to invite. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Chord notation
On Wed 14 Feb 2001 at 12:52PM -, Laurie Griffiths wrote: Mike Whitaker said "... what Muse does isn't compatible with what abc2midi does..." This is true in principal, but actually what abc2midi does is very flexible and can easily changed by the user or in the source. Has someone got a description of what abc2midi does? Go to http://abc.sourceforge.net/abcMIDI/ and follow the link for abcguide.txt. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modal three chord trick
Mike Whittaker said: Are 'slash chords' (e.g. E/A) part of the standard yet? I note abc2midi seems not to recognise them. Frank Nordberg said: The exact syntax for chord notation isn't really covered in the abc specs at all. As far as I know, abc2midi is the only application that attempts to do anything with the chords (apart from writing them down, of course) at all, and that program has a rather chord repertoire. What are 'slash chords' ? The notation isn't immediately obvious and I don't remember seeing anything about it in the list of chord types that I built into abc2midi. You can define "/A" according to taste to make abc2midi understand it, but you will need to do this for all the different slash chords that you have. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] gracenotes
On Thu 08 Feb 2001 at 12:35PM +0100, Frank Nordberg wrote: (Note: There shouldn't be any grace notes in this tune, of course. I just happened to have it handy for testing...) The results: BarFlydisplays and plays back nicely. abc2midi plays back nicely abc2psignores the grace note yaps comes up with an error message and no output at all yaps seems to be handling the grace note just fine for me. The error message is complaining about A z. Have another look for the output file. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] developers/user
Someone wrote: One question is about spaces. I'd prefer to say that the fields of a K: line may be separated by spaces, for readability. The only problem with this is the abc 1.6 description of "global accidentals", which use the same syntax but with the accidentals separated from the tonic and mode. However, I've been unable to find any abc that uses global accidentals, or any software that implements it. So perhaps we should decree "global accidentals" no longer part of abc's syntax, and permit spaces between the K: fields. I'm a bit confused here. My parser (for yaps and abc2midi) implements global accidentals with spaces between them, but these modify the key signature rather than the every individual note. Is this what is being proposed ? James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] !
On Fri 26 Jan 2001 at 01:15AM +0100, Jack Campin wrote: Me too. This !...! syntax is a disaster waiting to happen because of its incompatibility with abc2win and needs to be stepped on before it spreads. Didn't we say that about abc2win's ! syntax ? Anyhow, it is too late, my parser already recognizes !...! for !p! !pp! !fff! in abc2midi and !coda! and !segno! in yaps. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Useful mistakes
On Fri 26 Jan 2001 at 11:27AM +, Anselm Lingnau wrote: In article [EMAIL PROTECTED], John Chambers [EMAIL PROTECTED] wrote: So what we maybe need in the new standard is a clear statement that P: may be used to apply arbitrary text to major sections of the music. The P: text is to be put at the left edge of the page by formatters (and presumably ignored by most other software, though players might display it as the section is played). I'm with you on this, John (SCD musicians unite!). Please could the P: purists suggest another way of putting tune titles in a medley if they don't want us to use P:. Isn't this what "_Tune name" does ? James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] !
On Thu 25 Jan 2001 at 06:43AM -0500, [EMAIL PROTECTED] wrote: But what about the use of ! as a delimeter in 1.7.6. This needs to be resolved before it is implemented. The potential conflict with abc2win code can be resolved fairly easily in the parser by looking forward to see if an ! is at the end of a line or not. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] V: again
I have a small suggestion regarding the V: field and global parameters. This isn't something I've implemented, just an idea I had. I'd like to know if other people think it is useful or not. The idea is that we introduce another V: directive V:SYNC which marks the point in the abc where all the currently active voices synchronize together and we go back into a global mode. Any K:, L: or Q: field from this point on will apply to all voices (so we have a mechanism for global parameters). The V:SYNC also provides a checkpoint in the abc - if the different voices have different musical time, then we know that something has gone wrong and any good abc program should report an error. The "global mode" will continue until a V: field introduces a new voice, or there is music with no preceding V: field, which is treated as V:1 by default. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V: again
On Tue 23 Jan 2001 at 11:59AM -, Laurie Griffiths wrote: I think I would prefer V: SYNC string Consider: V:1 abc abc abc abc V:SYNC 1 dead dead dead V:SYNC 2 def def def def V:2 face face face V:SYNC 2 def def def def I don't think you've understood the concept here. What you've written would come out monophonic, though sometimes using voice 1 and sometimes using voice 2. The purpose of V:SYNC is to mark the end of a polyphonic section, so I think your example should be V:1 abc abc abc abc V:2 def def def de V:SYNC V:1 dead dead dead V:2 face face face V:SYNC James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] draft for V:
On Thu 04 Jan 2001 at 09:48AM +, Phil Taylor wrote: It was probably something like this which prompted Jean- Francois to suggest that a P: field should reset the voice number to 1. In viewer programs the P: field is simply a label to be written above the first voice, but in player programs it's a flow control device used to determine the order in which parts are played, so resetting the voice number to 1 is a very bad idea here. Actually, it is what abc2midi does. abc2midi has had a V: field for a long time (and I think it was the first program to have it). The abc2midi documentation describes some of the intricacies of the fields interact. For example, a P: field in multi-voice abc provides a good point for checking that all voices have the same playing time. However, perhaps we do need a way of indicating that a field placed in any voice should be applied to all voices at that time point. This requires a slightly different way of writing fields, possibly something like: The problem with this idea is that it then becomes possible to re-set the key in one voice from an instruction in the middle of another voice and it will be very difficult for the human reader to work out what is going on. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] draft for V:
On Thu 04 Jan 2001 at 03:03PM +, Phil Taylor wrote: On Thu 04 Jan 2001 at 09:48AM +, Phil Taylor wrote: It was probably something like this which prompted Jean- Francois to suggest that a P: field should reset the voice number to 1. In viewer programs the P: field is simply a label to be written above the first voice, but in player programs it's a flow control device used to determine the order in which parts are played, so resetting the voice number to 1 is a very bad idea here. Actually, it is what abc2midi does. abc2midi has had a V: field for a long time (and I think it was the first program to have it). The abc2midi documentation describes some of the intricacies of the fields interact. For example, a P: field in multi-voice abc provides a good point for checking that all voices have the same playing time. Ouch! What happens when you have a P: field in the middle of a line of music? Do all voices still have to have a P: field at the same time point? There is only one P: field to mark the end of one part and the start of the next for all voices. If you put it in the middle of a line of music, it makes your notation more difficult to understand, but it behaves in exactly the same way (i.e. globally). However, perhaps we do need a way of indicating that a field placed in any voice should be applied to all voices at that time point. This requires a slightly different way of writing fields, possibly something like: The problem with this idea is that it then becomes possible to re-set the key in one voice from an instruction in the middle of another voice and it will be very difficult for the human reader to work out what is going on. The idea is that such fields exist outside of the individual voices, so you would normally put one on a line by itself, following a block of complete voices and applying to all voices in the following block. Is that the way in which abc2midi interprets the P: field? Yes, P: is always considered global to all voices, while K: L: and M: are local to the current voice if they appear in the body of the tune. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] draft for V:
On Wed 03 Jan 2001 at 02:29PM +, John Chambers wrote: Well, I'd like to point out that, except for typesetting issues, the V: lines aren't needed at all. Actually, they are pretty much essential for generating multiple track MIDI files. On the topic of voice numbers needing to be contiguous (Laura's post); this restriction did exist in early versions of abc2midi, but the current version should allow non-contiguous voice numbers. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accidentals in ()
On Tue 14 Nov 2000 at 11:16PM -0600, John Henckel wrote: Also I recommend the ABC standard should clarify whether repeated accidentals are required or not. For instance, given K:C, is " ^c c | ^c " three c-sharps in a row? Or is the second c a natural? According to abcm2ps, the second c is SHARP (i.e. no natural sign is inserted). However, according to abc2midi, the second c is NATURAL (i.e. it sounds lower than the first note). IMO, the way abc2midi works is correct, and the ABC standard should say that the second c is natural. I think you've got the wrong program. abc2midi sharpens the second C, which is the correct behaviour according to standard musical interpretation. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] V: field
On Mon 13 Nov 2000 at 10:42AM +, Phil Taylor wrote: I think the answer to the first part is "sporadically". It is indeed a great lack of the current draft that the V: field is not discussed. The problem is that this is a very complicated extension, and nobody seems to want to sit down and write a draft proposal for it. There are already several mutually-incompatible variants about, which will have to be resolved. When I first introduced the V: field into abc2midi, the syntax was very simple: V:voice number Since then, people have added extra fields after the voice number, which is where the complication arises. Could we all agree on this first bit ? Simple parsers can then just ignore extra fields. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Tuplets
On Sat 28 Oct 2000 at 11:16AM +0200, Christophe Declercq wrote: I have seen triplets written with slurs but also without and sometimes with something, as you said, like: _3_ | | over the notes If the notes that make up the tuple are not beamed together, you need some way of telling where the tuple starts and where it ends. This is what the above notation is for. If the notes are beamed together, then all you really need is the number. It would probably be fairly easy to give abc2ps an option which selects the above notation for all tuples. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Key signature accidentals
On Sun 15 Oct 2000 at 11:49AM +0100, Phil Taylor wrote: There is some scope for disagreement here. John Chambers wants global accidentals to be octave-specific unlike normal accidentals, so you can have both =C and ^c. That seems useful to me. This may be useful, but it also introduces ambiguity. Does K:^f mean sharpen the f in every octave or sharpen the f in just one octave ? I usually make the assumption that an accidental in the key signature applies to every octave, which rules out notation such as K:^f =F James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multible chord lines
On Thu 12 Oct 2000 at 07:32AM -0700, [EMAIL PROTECTED] wrote: Perhaps it doesn't explicitly belong in the standard, other than as a comment saying that it's a possibility. Something that a lot of GUI software does is understand \n inside quotes as meaning to start a new line. That is, a chord symbol like "G\nEm" should produce a two-line bit of text, with "G" on the first line and "Em" on the second. All we really need is for the software to handle this correctly. To me, "\n" would imply a linefeed character to be included directly in the PostScript - probably not what you want. The syntax recognized by yaps and abc2midi is a semi-colon. e.g. "G;Em" James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Re: abc post-processing scripts
On Sat 07 Oct 2000 at 02:04PM +0200, Frank Nordberg wrote: 2. A script for halving and doubling the note values. abc2abc will do this (as long as you have a fairly recent version). James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] MacMIDI2abc
On Wed 04 Oct 2000 at 12:06AM +0200, Frank Nordberg wrote: which is pretty stupid of course. But then I told the program to take the tempo from the midi file (why isn't *that* the default?) rather than making one up itself and got this: I originally wrote midi2abc to try to deduce the time units so that it will work on MIDI from a live player without the player having to play to a computer-generated beat. Sometimes midi2abc guesses the wrong time unit, but often it will get it right. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
