I guess this is a good place to jump in. I'm a reasonably good abc user, but bow to Phil, Ulf, John and lot of others any time. However I do have a fairly large background in attempts to write music notation in text characters. I wrote a PhD dissertation a looooong time ago that spent a chapter on the methods then in use. So, I do have some thoughts about Mike's proposal. I've tried to excerpt the comments below and add mine. I hope they are useful.
On Tuesday, June 8, 2004, at 05:18 PM, Michael Ellis wrote:
Hi Ulf, Phil, and Stephen,
But first I'd like to emphasize that my intent is not to criticize or replace the existing abc notation. I admire it greatly and wish I had known of it earlier. Rather, I wanted to offer a possible extension that might be of value to some.
I think this is a crucial point. To "mess with" the foundations of abc would be impossible now. Anything added has to be added not replacing. I would reject Mike's whole idea were he not proposing a variant.
To them, it wasas thoughIwas joi ningwords a crossspaces. Very disconcerting.
I had a violinist who could play from Ford Columbia Music Notation which was much worse than either abc or Mike's proposal. So, one can learn anything. From my perspective the crucial issues are: how easy is it to read and how quickly can I write it? I think Mike's proposal makes rhythms much clearer to the user and in some (many?) cases is easier to quickly write down than standard abc. I might be inclined to use it as a musical shorthand if I didn't usually just transcribe to music.
Well, your system can't do anything that abc can't do already.
You're right. That's why I'm proposing it as an optional variant.
As I said this is the only way I would accept the idea.
All your
proposal does is to bring in a more difficult readability and significant
problems with parsing to midi or other code.
I think it improves human readability and I agree that machine parsing
(tokenizing, actually) would be more complex in that the tokenizer would
need to gather all the pitches and dashes between whitespaces before
determining the unit of subdivision for each beat.
I agree with all of this. As a programmer for the past 25 or so years I can see the parsing difficulties and also as a human (the last time I checked) I can see the ease of reading.
I can't see there are any
advantages in it. Since all of us use abc since years and are perfectly
accustomed to read it
I think the benefits would be greatest for new users. I certainly would not propose to force anyone to learn a new system!
Agreed. Also probably quicker for quick transcriptions of pieces. I actually transcribe direct to music notation though....
-------
On Tue, 2004-06-08 at 04:57, Stephen Kellett wrote:
Main problem: You've used an existing symbol '-' to represent 2 different things (in one place you call this "minus" and in another "dash") and that is in addition to the already existing use of this character in present ABC notation.
I'm not wedded to '-', another character, '*' for example, would do as
well. Perhaps it could be an argument to the variant flag, e.g. 'V:*' I
used '-' in my proposal because it seems the most natural character for
the job and it's the easiest to write when transcribing with pencil &
paper.
<snip>
If the concept is acceptable one can work out the symbology later. I don't think the issue of multiple uses of symbols is an issue for a program, since the V:- at the beginning would clearly indicate when one had to consider a second use of the dash.
On Tue, 2004-06-08 at 05:02, Phil Taylor wrote:
%Example 2 M:4/4 V:- | ab a--b abc -efg |
M:4/4 L:1/8 K:C | ab a>b (3abc- efg |
(that bar doesn't add up, by the way)
I think the equivalent abc notation (with L:1/8) would be
| ab a>b (3abc- c/2e/2f/2g/2 |
which does add up.
L:1/16 would be a bit cleaner
| a2b2 a2>b (3abc- cefg | % did I get that right?
but I think | ab a--b abc -efg | is crystal clear by comparison.
Me too.
On Tue, 2004-06-08 at 09:04, Jack Campin wrote:
That's similar to what Curwen sol-fa does, except that sol-fa uses proportional spacing to provide a visual backup for its implicit coding of note length.
I did a master's paper on Curwen. The pitch notation is neat. the rhythm notation is opaque at best, and gives no indication of beaming etc. (or at least very little).
(I'm sure somebody somewhere has invented an ASCII representation for solfa - not much point in a human using it directly, as solfa uses kerning and non-ASCII characters to useful effect, but such a thing might make a better target for a translator).
Writing a translator from standard abc to my proposal is not too difficult, especially in a high-level language like Python, Tcl, or PHP. Going the other way might not be too hard, either.
I'm not familiar with Curwen sol-fa. It sounds interesting. I gather from your description that it relies on computer typography. I suppose I'm more interested at the moment in simple alphanumeric notations, but I'd like to look into Curwen later.
Curwen's big problems are with the rhythm notation and with the fact that one has to decide that the music modulates and write "modulations" to keep the solfa clean. It is based on the idea the "do" is the home note of the major key of the given key signature. So, life gets interesting when the key center changes. Even simple traditional tunes with different sections in different keys would be problematical. That said someone once did a score for the Beethoven 9th in Tonic-solfa, so it can be done!
Now one thing Mike's method apparently "forgets:" Standard abc can allow beamed and unbeamed notes. Mike's approach, when turned into music notation, has no clues about beaming. One would have to either assume that non spaced notes were to be beamed appropriately or not beam anything.
This last issue implies my real point. We ask two things of alphameric music notations: That they represent the pitches and rhythms efficiently and that they allow for conversion into printed music notation. The strength of the current abc is that is does this latter well without ambiguity. To do the latter well always seems to require some loss of efficiency in simple pitch and rhythm notation and abc does lose some efficiency. Mike's suggestion neatly simplifies pitch and rhythm issues, but at the cost of some ambiguity in translation to music notation. Now how important is the loss of flexibility in notating beamed and unbeamed notes? It all depends on what you are transcribing. For a large subset of simple tunes Mike's solution seems jut fine to me. In the larger world of music and in the directions extensions of abc are heading I wonder. If a translator from Mikes variant to standard abc is easy to write and implement in the current crop of abc software I can support it. Otherwise I wonder.
I hope this long diatribe is useful to someone.... I promise to get back to short comments in the future!
Chuck Boody
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
