Bryan writes:
| John Chambers says -
| >And now Bruce is part of the cabal that's inflicting its
| >own ideas about ABC on the poor, oppressed user community.
|
| Maybe that's what he was trying to distance himself from.
Yeah, probably. But it didn't work; we've spotted him for the developer
that he is. ;-)
| Well he has co-opted the J: command. I hope nobody had any plans for that.
| On the other hand, he has introduced a sharps and flats key signature so
| presumably "We who like it the way it is" will be down on him like a ton of
| bricks.
Hmmm ... I noticed that, and was a bit disappointed that it repeated
the "N sharps or flats" approach that only works with classical key
signatures. So it can't handle non-classical key signatures, such as
the ones you need for Balkan and Middle-Eastern music. It wasn't
obvious to me what advantage his J: scheme has, since it doesn't seem
to allow for any key signatures not covered by the K:<tonic><mode>
scheme. I wonder if anyone else (other than Bruce and I) has
implemented another scheme for key signatures? There are problems with
the current standard's K: definition.
As you may recall, the approach that I used for my Klez/Balkan tunes
is the rather trivial extension of K: to allow:
K:<tonic><mode><accidentals>
where all the fields are optional, and the <accidentals>, if present,
are simply appended to the list of accidentals for the <tonic><mode>.
I haven't seen much comment on this, aside from a few "Who the hell
needs it" and "Hey, I could use that" followups. The main reaction
seems to have been a large collective shrug. Maybe I should write it
up again and see if I can get it into the new standard.
| >Maybe we should tell Bruce about the secret handshake ...
|
| When I launched abccheck, Phil Taylor told me that since I was now a
| developer I was entitled to vote. Can I have the handshake as well?
I'll tell you when I learn it. And what's this about votes? Have we
had votes?
| Wil Macaulay says -
| >If you are using abc as an output format, you are well advised
| >to use a lowest-common-denominator form.
A good idea in general. "Be conservative in what you produce and
liberal in what you accept" and all that. Of course, one possible
effect of this sort of rule is that you avoid using things like
"^foo" and !bar!, and continue to abuse the chord notation, since
that's part of the lowest common denominator.
| >Should we stop the production of $50 guitars because they don't sound as
| good?
|
| YES!!
I'll second that.
| on principle. In the meantime, I'd like to use Voices; which of the
| incompatible versions of the V: command should I use?
Well, one thing that we seem to agree on is that V:<number> should be
usable on a separate line within the music. This in fact covers a
great many of the actual uses, where you don't really need to label
the parts.
I'd hope that implementers write code that at least accepts and
ignores anything else on a V: line that it doesn't recognize. If this
is done, then people can continue to discuss the various desirable V:
options, while people can at least write multi-voice music that is
portable.
Also, for the notation
V:2 | CDEF GABc |
We could establish the rule that this in fact isn't standard, and
should be written
[V:2] | CDEF GABc |
This works as well, and allows for the inclusion of (non-standard)
options within the brackets, which most software could just ignore.
| I'd like to be able to
| process chords; how can I reliably recognise whether something between double
| quotes is a chord or not? (Absence of ^_<> or @ isn't enough.)
I've written code that uses the approach: Chords start with an
upper-case [A-G], possibly followed by [#b], possibly followed by 'm'
or 'aug' or 'dim', possibly followed by a number. If the quoted
string doesn't look like this, it's not a chord. This description may
not be complete, of course, but it seems to cover the chords that
I've actually seen. "Segno" fails the first test; "Fine" and "Coda"
fail the third, and so on.
| How can I
| use the !symbol! notation when it clashes with abc2win's use of ! ?
I wonder if there's a reasonable path we could follow to bring
abc2win into the fold in a graceful fashion?
| All I'm asking for is a more cooperative approach, for developers to take a
| bit more notice of what other developers are doing and to take a bit more
| interest in what the non-programming user wants. Are you really arguing
| against that?
Nope; but there is the ongoing problem of differences of opinion on
the right way to do some things. The general rule that software
should be accepting and ignore things that don't make sense will go a
long way toward making life easier for us all. We will have new
things in ABC, with or without group approval. We just need to be
reasonable about how it's done.
In any case, I've never seen a J: line. Or an E: line. So I'm not at
all bothered by the idea of someone hijacking them for their own
purposes. If I can understand what they're doing, so much the better.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
