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
voice notation, this seems a far more
sensible way to notate global key 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
ice, that voice would either 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
o allow the omission 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
I agree with the correspondent who would rather not introduce
gratuitous percussion notation.
Barry Say
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
rather than rests 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
ernative to the directive/postscript-
comment %%, but has anyone used it in notation? I know there have
been some suggestions to sub-divide these huge categories to produce
application-specific groups. Any thoughts.
Barry Say
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
??
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
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:
www.n
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 implemen
On 31 Jul 2003 at 12:50, I. Oppenheim wrote:
>
> The sections are now all numbered.
> http://www.joods.nl/~chazzanut/abc/abc2-draft.html
>
Thank you for adopting my numbering suggestion.
Section 6.1 Deprecated fields
"An E: field was once used by abc2mtex to explicitly control note spacing:
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. If
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. Thi
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
14 matches
Mail list logo