On Sat, 2003-07-05 at 10:37, Phil Taylor wrote:
> 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.
Use of ! in the abcm2ps/abc2midi meaning, or in the abc2win meaning? I
was thinking that we could actually standardize it to have the abc2win
meaning, so that lots of formerly non-standard files would suddenly
become standard ABC. :) It's also a useful feature. Who knows, we
could even add a !! for "don't break here." But I'm getting ahead of
myself. :)
> >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.
True. In my particular case, I'm not as concerned about readability as
whether all the appropriate marks get output on the score and all the
dynamics get put into the MIDI. Also, I'm not so sure I like the idea
of U: redefinition within a tune, although I don't necessarily think it
should be prohibited). If the symbol definitions (or "bindings," I
suppose) are constantly changing, it will be very difficult to determine
what a particular mark means simply by looking at it in the ABC. If it
is spelled out, there will be no problem whatsoever.
> >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.
Yeah, that was I: I proposed a "Y:" directive here on August 29, 1998,
and then revised it on May 7, 1999 to include the separate-line version.
:) However, for better or worse, the idea never caught on, and many
well-established programs like abc2midi decided to put the dynamics
inline instead. I'm not sure which I like better, although I do know
that I already have a whole bunch of tunes that have !...! in them, and
it would be a pain to have to re-transcribe them. :) However, I'm
certainly willing to do it if the community decides that they would
prefer the separate dynamics line.
In practice, I have found that I usually don't include that many
dynamics on one line, so most Y: lines (at least in my music) would
probably end up looking something like this:
Y: | | * p | | * <( |
which is kinda silly.
> >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.
That's great!
> >
> >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.
I agree.
> However, the use of numbers and brackets is cryptic.
I'm afraid I disagree here. :) The numbers are simply the voice
identifiers. If you wish to use non-numeric voice identifiers (e.g.
PianoRH), then that would make it even more readable. The brackets (I
feel) are not cryptic, because their symbols (apart from "()") are
visual representations of exactly what will appear on the score. If you
specify "{", you will get a brace to the left of the staves; if you
specify "[", you will get a bracket. This seems logical.
> 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.
To be honest, the %%staves directive is much easier for me to read. :)
I can easily tell what goes where. But I may well just be in the
minority here, and I'll bow to whatever the consensus is. One beef is
that I don't know if "merge" means that the voice should merge with the
previous voice or the next voice.
> 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).
Yup, quite right. All this seems like information that pertains to that
particular voice. But the staff grouping marks seem like "metastaff"
information -- or information about staff groups (as Lilypond would call
them), so I feel that they shouldn't go on the actual voices themselves.
> BarFly currently reads the %%staves directive if present, but directives
> placed in V: fields in the header will override it.
Fair enough. Thanks for supporting it!
- Eric
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
