I am just about catching up with this review process and
think I should add my tenpennorth as an advocate of
abc2mtex.
The ABC 2.0 draft was based on ABC 1.7.6, but the last
version of ABC2mtex produced was 1.6.1 which is pretty
well backwards compatible with all previous versions.
1.7.6 did
I am concerned about the lack of backwards compatibility of the proposed standard with
abc2mtex.
Since this was the original program for ABC, I think these issues deserve some
consideration.
1. I have already mentioned the E: field in a previous e-mail. This needs
reinstating
2.
How are we going to reach decisions on a new standard?
How come the proposal by Guido was suddenly expanded?
Shall I now post my version on a website and call it revision IV?
Are we going to vote?
If so who votes?.
The density of mail on the list is no guide to the opinion of list
members.
John Chambers [EMAIL PROTECTED] said on 24 Aug 2003
The real problem we're facing is: A lot of people really want the
final backslash to mean continue with the next line of the same
type. But this discription is sufficiently ambiguous that we end up
with different implementers
After much consideration and a little discussion, I have devised some
modifications to the ABC standard, which I think could make the
structure considerably more elegant without doing to much damage to
existing applications. As they are rather complex I have described
them on a web page:
categories to produce
application-specific groups. Any thoughts.
Barry Say
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
in the melody line, but I have
seen both. It seems more flexible to allow this rather than forbid. I
think the question is why should it be forbidden?
Barry Say
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
not introduce
gratuitous percussion notation.
Barry Say
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
of square brackets around
voice field specifiers at the start of lines in the tune body. I
cannot see the necessity for this construct.
Barry Say
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
have the label defined in the
tuneheader or none.
I do not like the unnecessary proliferation of inline fields of
ABC2.0. I fear it will lead to more syntax errors.
Barry Say
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
and meter changes than having to
match inline fields in all voices.
Barry Say
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
On 17 Oct 2003, Phil Taylor wrote:
Barry Say wrote:
You need to place a metre change in all of the voices (if that's what
you want) since you can have voices in different metres. (It's not
common, but it does happen, and not only in avant-garde music - Bach
did it occasionally.)
I
12 matches
Mail list logo