Is that correct, or could there be an attempt to make eighth-tone notation (which is quasi-standard in places such as IRCAM, Paris) standard in abc with predefined symbols?
Regards,
Georg Hajdu
On Wednesday, June 25, 2003, at 06:01 AM, Jeff Bigler wrote:
Date: Tue, 24 Jun 2003 21:06:28 +0100
From: Bernard Hill <[EMAIL PROTECTED]>
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
writes
Bernard Hill wrote-
Surely by the standard
(www.gre.ac.uk/~c.walshaw/abc/abc-draft.txt) H *is* predefined
as fermata.
But that's not the standard. That's the draft of the elusive next
standard.
I was advised by Chris Walshaw himself that that is the current standard
and has replaced the one on the standard web site.
From: [EMAIL PROTECTED]
Date: Tue, 24 Jun 2003 22:08:59 EDT
Cool. Thanks. First I'd heard. No mention of it on Chris's web
site (still refers to it as draft and 1.6 as current).
Does everyone know about this? My subscription to the list was
broken for a couple of months earlier this spring, so I might
have missed it.
I've been on the list continuously during that time, and I certainly
didn't know that there was any official proclamation (whatever that
means) of the 1.7.6 standard becoming current. Certainly
http://www.gre.ac.uk/~c.walshaw/abc/#standard currently refers to 1.6 as
the standard and the 1.7.6 document as a draft.
However, several developers have been coding to the 1.7.6 draft for
quite some time. (In fact, discussion on this list suggests to me that
a majority of developers appear to have either implemented many of the
elements in the 1.7.6 draft standard, or at least have been careful to
avoid violating it wherever possible.) Given that, it would seem
reasonable to me to treat the 1.7.6 document as if it were the current
de facto standard.
I. Oppenheim wrote:
On Tue, 24 Jun 2003, Georg Hajdu wrote:
The parsing of xml files seems more difficult,
XML is very easy to parse: you can make use of several
free off-the-shelf parsers that either create a
complete document tree (DOM standard) or generate
parser events (SAX standard).
Even if you write your own parser, as I did, it's easier than
parsing abc.
Just have a look at http://xml.apache.org/ for one of
the available solutions.
In abc the capital letters H..Z are reserved for
user-defined purposes. Software which supported
microtonal accidentals could make use of these.
That is not a good idea. Several of these letters
(THLMPSO?) have already a predefined meaning. It would
be better to leave these letters free.
Not true - the abc standard specifically makes these characters
available for use. The "predefined meanings" are just a convenience
for the most commonly-used symbols and are not completely consistent
between programs. Any sensible program should allow the user to
define them to mean anything the program is capable of interpreting.
Now, what about some other ascii 128-255 characters?
Are they supported by abc?
That is also not a good idea. Chars 128-255 are not
defined by ASCII and have a different meaning depending
on the code page that you use on your computer.
Using these chars would change ABC from a text format
into a binary format.
I would agree with that. The problem is that many users
just use them to mean whatever they mean on their own system,
so they get used to represent charcters with diacritical
marks, instead of using the TeX backslash escape sequences
which are cross-platform.
I think the best solution would be to use the !...!
symbol notation to add extra symbols to the abc
language. Something like !sharp1!, !sharp2!, !sharp3!
etc. If the user so desires, he could bind these
symbols to some of the free letters, via the U:
mechanism.
If you've been reading this list for any length of time,
you probably know what I think of the !...! notation. If
it's used without binding the meanings to single letters it
makes the abc totally unreadable, and sensible programs
don't need the exclamation marks in symbol definitions.
***************************************************
Phone:
+49-40-23517610 (h)
+49-40-42-848-2005 (w)
+49-172-787-4214 (m)
+49-40-42-848-2030 (f)
e-mail: [EMAIL PROTECTED]
e-mail: [EMAIL PROTECTED]
http://www.georghajdu.de/index.html
http://www.quintet.net/
****************************************************
