Eric Galluzzo wrote:
>All programs, to my knowledge, that implement the !...! construct
>(abcm2ps, jcabc2ps, and abc2midi?) are under active development, to my
>knowledge. Therefore, all of them could easily be altered to accept "*"
>as the character rather than "!" (perhaps accepting the "!" as a legacy
>construct). We would have a rather more difficult time changing
>abc2win, since it is not open-source; and the myriad tunes that are
>already on the web could not be changed.
>
>For the record, I have used !...! a great deal, but I would certainly be
>willing to change all my ABC to use the *...* notation instead. I
>imagine that if we could reach a consensus on this issue, most other
>people who use this notation would be willing to do so as well. People
>just want something that works; they do not terribly care what it is.
>Furthermore, if this were done, I could feel free to introduce "!" into
>my scores with the abc2win meaning, which could be useful at times.
I'd be perfectly happy with that, especially if the use of ! was deprecated.
>
>Regarding U:
>------------
>
>Someone else has stated both of these points before me, but I do take
>the view that the !...! construct is essential, for the following
>reasons:
>
>1. It is very possible to use more than 19 symbols (H..Z) in one file.
>For example, I could very easily use !pppp! through !ffff!, !sfz!, !<(!,
>!<)!, !>(!, !>)!, !fermata!, !tenuto!, !wedge!, !trill!, and !0! through
>!4! in a single piece. That's 24 already.
If the U: field is permitted within the tune you could recycle symbols,
thus lifting the 19 maximum limit. Of course, if you need that many
extra symbols in a single tune your abc is never going to be readable
anyway.
>2. Some of the symbols are much more easily understood as their expanded
>form than as a single-letter redefined symbol. For example, if I see
>!pp! in a tune, I know that it means pianissimo. If I see S, I have no
>idea. Again, if I see !1! I know it's a fingering. If I see Q, I have
>no idea.
Music with lots of dynamic markings is never going to yield readable
abc if the markings are inserted inline, whether as single letters or
as explicit names. Another suggestion which has come up here previously
is to put such markings in a separate line of text with its own field
symbol, to be aligned with the music using the same mechanism that's
used for aligned words.
>So: how about that we agree that "U:T = trill" type notation is
>acceptable, and put into the standard? We could simply state that it is
>a symbol binding, or redefinition, or whatever we want to call it. It
>would apply to player programs as well as tadpole-generating programs.
>The BarFly definition of U:, so I gather, is somewhat broader; but this
>is at least a least common denominator that covers most common uses of
>U:. I think that this notation should satisfy Phil, Jack, etc., since
>it is compatible with BarFly; and it should satisfy John, Irwin, etc.,
>since it is close "in spirit" to U:T = !trill!.
I'm happy with that.
>
>Regarding %%staves
>------------------
>
>I personally find %%staves very useful, and (despite comments to the
>contrary) very intuitive. How about adding some official variant of
>this to the standard? It seems much more concise, and more intuitive,
>than the
>
>V:1 bracket=2
>
>type notation that abc2ps had originally introduced. We are running out
>of letters for headers, though; how about lowercase "s"? Thus:
>
>X:1
>T:My Choir + Organ Piece
>M:4/4
>L:1/4
>s:[1 2 3 4] {(5 6) (7 8) 9}
>K:C
I've always thought of the %% construct as being for new and experimental
stuff, which is always going to break other programs, so if the staves
command becomes standard I would prefer that it got it's own field identifier.
However, the use of numbers and brackets is cryptic.
Compare your tune the way BarFly does it:
X:1
T:My Choir + Organ Piece
M:4/4
L:1/4
V:1 bracketon
V:2
V:3
V:4 bracketoff
V:5 bracketon
V:6 merge
V:7
V:8 merge
V:9 bracketoff
K:C
This will give you 9 voices on seven staves, with the top 4 and bottom 3
bracketed together. "merge" means draw this voice to the same stave as
the previous one. The empty V: fields are not required.
In practice, there's lots of other stuff which goes into V: fields in the
header too, such as clef, middle and transpose directives, longbaron/off
(controls the drawing of long vertical barlines in the same way that
bracketon/off controls brackets), up/down for stem directions, program,
channel, mute, tune and pan (for stereo).
BarFly currently reads the %%staves directive if present, but directives
placed in V: fields in the header will override it.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
