John Chambers wrote:
(about the !foo! construct)
>Hmm ... I'd forgotten who didn't like it, of course. The general
>feature does seem to be inherently useful, so I'd suppose that the
>objection is to the particular syntax. The other one I've seen is the
>one that uses double quotes and positioning stuff, as "^segno" or
>"_da Capo". This strikes me as a usable alternative, though it still
>does have the problem of confusion with accompaniment chords. People
>might want to position them too. I suppose you could say that chord
>symbols can't be positioned this way, and any text with ^ or _ after
>the " is assumed to be musical annotations.
The placing of guitar chords (above or below the staff) is up to the
application. You are unlikely to want to change that setting in mid-
tune. Text annotations do need to be placed differently within the same
tune, so ^_< and > are needed. Text annotations are just text, they're
not intended to be interpreted or substituted in the way that user-defined
symbols and macros are.
>| >But the !foo! notation itself seems simple. And a header line that
>| >says something like m:q=!foo! seems like it would be trivial to
>| >implement. ...
>|
>| Sure. Just leave out the bangs - they are utterly unnecessary.
>
>How so? That would imply that such macros can only be used for this
>purpose. I couldn't use them to abbreviate other common strings. I'd
>think a simple "substitute this for that" would be more useful, in
>which case you'd want the bangs included. Sorta like in C you can do
>things like:
> #define begin {
> #define end }
Fine - but C doesn't force you to write
#define begin !{!
and then go through your code writing exclamation points around every
brace. That's what is being proposed for abc. The existing abc
definition gives us the letters H..Z, and they are already in use by
most programs. Any well-written program will ignore one of these
symbols that it doesn't understand. You can use them singly or in
combinations if you really need more than 19 special symbols in one
tune, and you can define their meanings elsewhere. This has got
nothing to do with macros - we're not substituting one bit of text
for another; instead we are choosing which bit of code will be invoked
when the parser encounters that symbol.
So if I write the definition:
U: J = fermata
then an application which knows how to draw a fermata will draw one
over a note which is preceded by the letter J, and an application which
knows how to play a fermata will stretch the duration of the note a bit.
An application which does not recognise the definition should do nothing,
and no real harm will be done.
By comparison, writing the word !fermata! in the music makes the line
eight characters longer than it need be, and makes the abc harder to
read because it breaks up the flow. This is already the case with
guitar chords - they make the abc much harder to read because they
add lots of extraneous symbols to the line of music. I want to limit
what goes into a line of abc to the important stuff; notes, times,
bar lines etc which is what you want to read, and compress the other
less-important stuff into single characters which have less impact
on the readability. In addition, using !fermata! totally breaks
programs which don't understand that convention, and the existence
of large numbers of files which already contain exclamation marks
(for a totally different purpose) means that it's difficult to
implement in a way which will also deal reasonably with abc2win
files. It's not backward-compatible in either sense - old files
break new programs and new files break old programs. The worst
of all worlds in fact.
>| Basic substitution macros are very useful, they don't stop you from going
>| on to deal with macros which know to transpose (which are even more
>| useful).
>
>I've always found that transposing is easiest with a separate program
>that just does transposing. Builtin transposers in the fancy music
>packages are mostly good for laughs when they produce totally berserk
>notation. Thus, I've seen music transposed from F to G, in which all
>the ^F notes were written as _G, and there were no Fs in the result.
>The problem with this as a builtin is that when it's broken like
>this, you can't fix it. If your transposer is a separate program, you
>can write your own, or grab something like abc2abc, and it's fixed.
I'm not talking about transposition of a whole tune here, I'm talking
about transposing macros which define the meaning of a musical symbol
in a pitch-independant way, so that the macro does the right thing
whatever pitch of note the symbol is attached to.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
