Well, it's case sensitive. ABNF quoted strings, e.g. A: are not
case sensitive. ABC is (mostly) a case senstive language. So if I
want to stick to ABNF, which happens to be a standard, I'll have to
use e.g. %x58.3A and have a comment X: after it.
Please use strings like A: as you did in your
Jack Campin wrote:
You need to separate the two layers of ABC intended to represent
the music itself and ABC intended to represent staff notation for
the music somehow. Changing a note or a chord is in the first
layer; using a y to make the two halves of a bar more visually
separate than the
On Fri, 4 Jul 2003 10:39:36 +0100, Jack Campin [EMAIL PROTECTED]
wrote:
Over the past year or so, this group has become
dominated by discussion of abcm2ps;
[snip]
It won't be if the notation has been designed to be unplayable and
unanalyzable, which is where the !...! stuff is heading.
On Fri, 4 Jul 2003 02:37:43 -0400 (EDT), Jeff Bigler [EMAIL PROTECTED]
wrote:
[snip]
P.S. While we're on the subject of the !...! commands, does anyone know
why the mezzo piano dynamic was left out? I.e., !mp! is not in the
1.7.6 draft standard, and abcm2ps doesn't implement it. (I had
On Thu, 3 Jul 2003 17:07:05 +0200 (W. Europe Daylight Time), I.
Oppenheim [EMAIL PROTECTED] wrote:
On Thu, 3 Jul 2003, Manuel Reiter wrote:
By modifying 'subs.c' and 'syms.c' modified from the
current (08-Apr-2003) version of jcabc2ps jcabc2ps
can handle macron (\=), dot (\.), breve (\u) and
henrik wrote:
Well, it's case sensitive. ABNF quoted strings, e.g. A: are not
case sensitive. ABC is (mostly) a case senstive language. So if I
want to stick to ABNF, which happens to be a standard, I'll have to
use e.g. %x58.3A and have a comment X: after it.
Please use strings like A: as you did
Hello all,
I've just uploaded version 1.2.5 of the abcpp preprocessor. I have added
the option of converting old-style chords (that is, '+' delimited) to
'normal' chords (bracket delimited). I found an old ABC file with such
chords and couldn't typeset it.
As soon as I get some sample ABC files
On Mon, 7 Jul 2003, Jean-Francois Moine wrote:
Putting an accent on the next character is not a good idea. The
PostScript manual says that the accents (range \220 - \237) exist for
historical reason, and they are not defined in the Latin-x encodings
Hm, I didn't see that in the manual, could
On Mon, 7 Jul 2003, Bert Van Vreckem wrote:
I. Oppenheim wrote:
If the ABC community as a whole could provide a
standard complying parser, not every developer that
wishes to use ABC would have to reinvent the wheel
again and again. The current situation is in nobody's
interest.
We're
On Sun, 6 Jul 2003, Bernard Hill wrote:
Tom Keays [EMAIL PROTECTED] writes
But * is already part of the standard as a right-justified linebreak and
I've seen plenty of tunes that use it.
OK, I agree.
In that case:
1/ Let's define !break! and !nobreak! as symbols
which can both be used
I. Oppenheim wrote:
On Mon, 7 Jul 2003, Bert Van Vreckem wrote:
We're already there: using Henrik's BNF spec, a developer can generate a
parser with tools like lex and yacc.
Unfortunately, it is not trivial at all to convert a
BNF definition into a working parser.
snip
When you use Lex and Yacc,
When printing music I would expect the music to look like
===
with only the last line maybe not being right-justified.
Me too !
Does non-right justify mean the score could be
Jean-Francois Moine writes:
| On Fri, 4 Jul 2003 10:39:36 +0100, Jack Campin [EMAIL PROTECTED]
| wrote:
| Over the past year or so, this group has become
| dominated by discussion of abcm2ps;
| [snip]
| It won't be if the notation has been designed to be unplayable and
| unanalyzable,
| For the time I'm transcribing tunes, I'm working with rare sources
| that I can't afford to have photocopied; the process required by the
| library for old and delicate material involves intermediate microfilm,
| and usually leads to a fairly bad result anyway, where things like
| articulation
On Mon, 7 Jul 2003, Jack Campin wrote:
Braille devices usually work one line at a time, so
it helps if that line both forms a musically
meaningful unit and is also not cluttered up with
noise symbols like !break!.
Come on, how much noise does a * make?
Groeten,
Irwin Oppenheim
[EMAIL
There is one serious problem with changing the BNF spec to literal strings
being case sensitive - places where we don't want case sensitiveness
become horribly complicated! E.g. dor dorian DOR Dor Dorian etc should all
be allowed, but the BNF for case insensitive of that would be
(d/D) (o/O) (r/R)
Richard Robinson writes:
| I was thinking about this over the weekend ...
Always a mistake. ;-)
| I needes an abc parser last autumn, for my tunes-comparison project,
| and really didn't want to write my own. So I used James Allwright's -
| he uses it with different backends, to generate ps,
henrik wrote:
There is one serious problem with changing the BNF spec to literal strings
being case sensitive - places where we don't want case sensitiveness
become horribly complicated! E.g. dor dorian DOR Dor Dorian etc should all
be allowed, but the BNF for case insensitive of that would
henrik wrote:
Well, it's case sensitive. ABNF quoted strings, e.g. A: are not
case sensitive. ABC is (mostly) a case senstive language. So if I
want to stick to ABNF, which happens to be a standard, I'll have to
use e.g. %x58.3A and have a comment X: after it.
Please use strings like A: as you did
I. Oppenheim wrote:
On Mon, 7 Jul 2003, Bert Van Vreckem wrote:
I. Oppenheim wrote:
If the ABC community as a whole could provide a standard
complying parser, not every developer that wishes to use ABC
would have to reinvent the wheel again and again. The current
situation is in nobody's
Joerg Anders wrote:
Hi!
As far as I can see abcm2ps always connects all measure lines
over all staves.
|
---||--|||--|||--|-
---||--|||--|||--|-
henrik wrote:
There is one serious problem with changing the BNF spec to literal strings
being case sensitive - places where we don't want case sensitiveness
become horribly complicated! E.g. dor dorian DOR Dor Dorian etc should all
be allowed, but the BNF for case insensitive of that would be
Date: Mon, 7 Jul 2003 13:24:24 +0100
From: Jack Campin [EMAIL PROTECTED]
Using + where abm2ps and abcmidi currently use ! would handle
legacy tunes better. There are very few tunes out there using
the obsolete chord notation, and very few chords that could
cause ambiguity (has anybody
T.M. Sommers wrote:
henrik wrote:
There is one serious problem with changing the BNF spec to literal
strings
being case sensitive - places where we don't want case sensitiveness
become horribly complicated! E.g. dor dorian DOR Dor Dorian etc
should all
be allowed, but the BNF for case
From: Jeff Bigler [EMAIL PROTECTED]
In the discussion to date on the list, I haven't seen any strong
objection to +...+ . I'm sure we're never going to reach
consensus on
this issue, but I think going with +...+ will result in the least
amount
of objection and breaking the least number of
=?iso-8859-1?q?Forgeot=20Eric?= writes:
| ps : well, let's discuss now about the chords with different note
| length [A2c4] etc. :) I expect a nice debate
Funny thing; just this morning I got a personal message
about this. But the writer was complaining about the the
opposite problem: the
Bruce, I think you misunderstood what I meant. I was talking about
how to write it in BNF, not how to do it programmatically, which is
obvious to any programmer, e.g. 0==strnicmp(key, dor, 3)
Bruce Olson wrote:
There need not be any problem here. Allow both upper and lower case
characters and
On Thursday, Jul 3, 2003, at 13:52 US/Eastern, Buddha Buck wrote:
On Thursday, Jul 3, 2003, at 06:43 US/Eastern, Bernard Hill wrote:
In message [EMAIL PROTECTED]
chemnitz.de, Joerg Anders [EMAIL PROTECTED] writes
A short remark about this. Somtimes open source is equated with
cost free. But even
On Mon, 7 Jul 2003, Donald White wrote:
One solution might be to allow the definition of
additional voices on the fly - or within a block of
music. That way, when you only have a small portion
of a piece that requires independent voices on one
staff you don't have to pad the entire piece
On Mon, 7 Jul 2003, T.M. Sommers wrote:
These are not problems with lex and yacc specifically; any program
parsing abc will have to face them. They are ambiguities, or potential
ambiguities, in the language itself.
In the first case above, there should be no problem: the composer field
is
On Mon, 7 Jul 2003, henrik wrote:
(d/D) (o/O) (r/R) [(i/I) [(a/A) [n/N]]]
which is quite unreadable.
Personally I do not have anything against the notation
above.
So I'll let it keep the %x44 type notation for characters.
I can read the alphabet, but I cannot make sense
of hexadecimal
on 7/7/03 2:03 PM, John Chambers wrote:
This is one of the reasons that I turned jcabc2ps into a normal unix
filter that reads stdin if there are no input files. That way I can
stick any sort of preprocessor on the beginning, and not worry about
cleaning up intermediate files.
Does abcm2ps
I.Oppenheim wrote:
or perhaps better, do not allow a-g and A-G as body fields.
Alas, they are in the standard.
Of the capital letters only E: is allowed in the tune proper, and
I think that's only meaningful in abc2mtex. The lower case letters
have not been assigned.
Phil Taylor
To
Donald White wrote:
One solution might be to allow the definition of additional voices on the
fly - or within a block of music. That way, when you only have a small
portion of a piece that requires independent voices on one staff you don't
have to pad the entire piece with invisible rests.
I'm
Donald White writes:
| I keep flipping back and forth between which is easier - using
| different note lengths within a chord, or multiple voices. Where
| multiple voices on a single staff move in parallel, it is easiest
| to use chords and then just deal with independent movement
Tom Keays writes:
| on 7/7/03 2:03 PM, John Chambers wrote:
| This is one of the reasons that I turned jcabc2ps into a normal unix
| filter that reads stdin if there are no input files. That way I can
| stick any sort of preprocessor on the beginning, and not worry about
| cleaning up
Phil Taylor writes:
| John Chambers wrote:
|[GBd]3 means [G3B3d3]
|[GB][Ac] means [G3/2B3/2][A/2c/2]
|[B-G2]3Bcd means [B3-G6]Bcd
| and so on.
|
| I wonder if anyone has implemented it already.
|
| I would have thought that most programs would handle [GB][Ac].
| BarFly does.
And
If I'm not mistaken, you can also embed L:, M:, and K: in the tune proper,
and I've seen N: and
I: as well.
wil
Phil Taylor wrote:
I.Oppenheim wrote:
or perhaps better, do not allow a-g and A-G as body fields.
Alas, they are in the standard.
Of
John, in your tune finder, are all the tunes present in all the
formats?
When I'm looking for a tune, I'll click on one of the ABC's at random.
Sometimes I get the tune, and sometimes I get a notice that the file
is empty.
Dottie B
To subscribe/unsubscribe, point your browser to:
On Mon, Jul 07, 2003 at 12:16:42AM +0200, I. Oppenheim wrote:
On Sun, 6 Jul 2003, Jeff Szuhay wrote:
I'm thinking along the lines of an ABCParse module
which feeds a stream to both ABCPlay module and
ABCView modules.
You're thinking about creating a libabc project? that
would be very
Hi!
As far as I can see abcm2ps always connects all measure lines
over all staves.
|
---||--|||--|||--|-
---||--|||--|||--|-
---|---o---||---o---||---o---|-
41 matches
Mail list logo
