On Fri, 9 Nov 2001, Jack Campin wrote:
This is what I thought I'd do:
1) study other notation languages carefully to see their approach and
priorities;
2) if a feature is implemented by other notation languages (M-Tx, MUP,
Lilypond, CMN, etc) and is desirable, then steal that feature
On Fri, 9 Nov 2001, Richard Robinson wrote:
Another approach is to ignore all existing implementations and create an
altogether new syntax.
No, please no ! ! ! ! !
Well ... maybe this might be worth someone's while ? Being an altogether
new syntax, it wouldn't be ABC; but we could
Hello Anselm,
Anselm Lingnau wrote:
Q:Allegro Pretty quick
Thus, a notation program could display something along the lines of
Allegro (Pretty quick)
the problem is that the tempo information may be a compilation of
information for
A) playback and display (that is the acctual standard)
On Sat 10 Nov 2001 at 06:39PM +0100, Frank Nordberg wrote:
Jack Campin wrote:
The solution is to put everything inside a single pair of quotes with
spaces between the individual chord symbols, such as:
CCDEF|CE2 Dm7 G7D2|C F CC4|]
How is a player program supposed to know
On Fri 09 Nov 2001 at 11:18AM -0600, Taral wrote:
On Fri, Nov 09, 2001 at 09:47:25AM +, James Allwright wrote:
Well, no-one has requested this, but I thought I'd post it all
the same. This is my little bit of PostScript to insert sharp
and flat symbols in a text string. It works,
Hello Guido,
Guido Gonzato wrote:
Let me tell you the dark side of my ABC point of view: ABC is _very_ nice,
but is _way_ too limited. It was designed with too little goals in mind. As
a real-world musician, I want to tweak current ABC so that it can do my
choral scores reasonably well. As a
Anselm Lingnau said -
Nothing should go in the
standard unless it has been proved that it is actually implementable
with reasonable effort. This may mean that sooner or later one might hit
a dead end with some feature or other, but it will be much harder to get
the standard fixed if the feature
I think that I am now in favour of syntax that allows this:
Any lines containing % are meta-comments meaning that they are just me
talking to you about the example and would not be part of the example -
though I guess they'd be legal as comments anyway
Q:1/4=120 Allegro % Outside any header.
Guido Gonzato said -
As a computer guy, I already have a new
syntax ready that just waits to be put down on paper...
I let you guess the reasons why I didn't put it down on paper. But if you're
interested, wave your hand at me.
Might be a good idea Guido. It would take the pressure of a simple
Anselm Lingnau wrote:
[EMAIL PROTECTED] (Phil Taylor) writes:
One thing I might suggest though. If we do get a new draft standard
out of this, please developers DON'T WRITE A LINE OF CODE UNTIL
A VOTE HAS BEEN TAKEN AND THE STANDARD BECOMES OFFICIAL. Writing
code sets the
Guido Gonzato wrote:
As a computer guy, I already have a new
syntax ready that just waits to be put down on paper...
Does anybody have any idea how many ascii based music notation formats
there are?
I mean if we're talking about a brand new standard, we ought to have a
look at the full
Simon Wascher [EMAIL PROTECTED] writes:
I looked into my files, and found that the abc files I
transcribed are a pile of about 3 MB (plain ASCII). Assuming that other
peoples who are listed as large collections at the abc homepage also
have big collections besides what is in the net right
On Mon 12 Nov 2001 at 12:58PM +0100, Frank Nordberg wrote:
I know I sometimes expect too much from the programmers. Like so many
non-programmers I tend to view them as some kind of magicians always
ready to pull a handful of miracles out of their sleeve.
If you tell me you can't do it this
Hello,
Anselm Lingnau wrote:
This is purely a presentation issue and does not pertain to the actual
ABC standard, which should describe the contents of ABC files.
It is simply not true that the abc standard does not contain
presentation issues. Even the question which clef to use is purely
Dear abc users and devellopers,
meanwhile all originally planned tablature features are
realised in abctab2ps and I plan to do other music extensions,
mostly in the realm of early music.
Before I introduce some other incompatible set of abc extensions,
I would like to ask the other devellopers
On Mon 12 Nov 2001 at 04:18PM +0100, Christoph Dalitz wrote:
Before I introduce some other incompatible set of abc extensions,
I would like to ask the other devellopers whether and how
they already have addressed some of the following issues.
1) figured bass
Both abctab2p2 and abcm2ps
In these examples it is easy to extract the tempo - but only because the
non-tempo part has been restricted to a single word followed by a space. I
can scan for a space in lots of simple ways (I gave two in an earlier mail).
What can not be done so easily is to extract a tempo string from
Actually the latest round of V: discussion that I
remember reading contained an example which was acceptable to BarFly together
with a conjecture that Muse probably wouldn't like it, but in fact it was quite
acceptable to Muse. I believe that in fact there is a large common
subset. (In this
That would be acceptable.
Actually I proposed that instead of having to write it twice it would be
done the other way.
If the text of the displayed tempo is a single minus sign then it has the
special meaning display nothing
Q:1/4=80 %display 1/4=80 and use it for the player program too
Christoph Dalitz [EMAIL PROTECTED] wrote:
2) rhythm of grace notes
abc supports grace notes, which are printed by abc2ps as eigth notes in
reduced size. A single grace note is printed as an eigth note with an
oblique stroke (ie. a short appogiatura in 19th century context).
While doing
James Allwright wrote:
1) figured bass
Both abctab2p2 and abcm2ps support line breaks (\n) and accidentals
(\# \b \=) in guitar chords; I have adopted the syntax of abcm2ps
in order to be compatible.
I am not sure what a line break character would mean in the context
of a guitar
Hello,
Laurie Griffiths wrote:
That would be acceptable.
Actually I proposed that instead of having to write it twice it would be
done the other way.
If the text of the displayed tempo is a single minus sign then it has the
special meaning display nothing
Q:1/4=80 %display 1/4=80 and
Another reason why BarFly's syntax for multiple voices can be useful.
This may not be as readable as honest-to-god real tablature but it's
still quite a bit easier than the original manuscript (which used
letters for the frets rather than note names and a separate rhythm
line). It was for the
Simon Wascher [EMAIL PROTECTED] writes:
It is not trivial to
tell where music ends and side information beginns. And as a transcriber
of historical sources it is often very important to cover some side
information within the exchangeable file, not just in the printed output
(for file
Hello,
nearer to an optimum than before :o)
( I know I should wait a moment and do it at once)
here, Separator ideas (the -) and order ideas are integrated.
Syntax for Q field after a definition by Laurie Grifiths (with Lauries
use of the minus!)
(follows after the standard Q:field
Laurie Griffiths wrote:
Jack, Frank (and other users) even if this isn't ideal, is it acceptable?
That's easy:
Acceptable:
Anything that lets me write abc to display any imaginable tempo
indication and play it back at a sensible speed.
Ideal:
Anything that lets me just write the tempo
Am I correct in my reading of the documentation of ABC (I use the
http://www.gre.ac.uk/~c.walshaw/abc/ site) that a clef indication is a
commonly available extension to the K keyword, but is not part of the real
1.6 standard?
I was just wondering if there was any way to indicate that the
Simon Wascher [EMAIL PROTECTED] writes:
Example
X:1
Q:n/n=n N/N=N andante
will playback n/n=n and display N/N=N andante
so if a numeral tempo indicator is on the very beginning of such a
string it must be written a second time for the display.
If no tempo indicator should be
Tablature
1. Muse supports ABC to fretted instrument tab generation by giving string
information after the duration, using a semicolon to delimit it. e.g. E2;4
Play E for 2 time units on string number 4. On the whole it's only
necessary to give this information for a few notes, the rest can be
Anselm Lingnau [EMAIL PROTECTED] wrote:
How about
L:1/8 grace=1/32
K:HP
{g}A{d}A{e}A {gef}e2 f | {g}ec{G}c {gef}e2
Seems reasonable. Or maybe just
L:1/8 {1/32}
? (In the case that `grace' is not specified we could fall back to,
e.g., a standardized default of `grace=1/8'.
Laurie Griffiths [EMAIL PROTECTED] writes:
No!! I am very much against this. Although it may be convenient for
writers of ABC it's horrid for readers. It makles it even harder to extract
a tune and the probability would be very high that we should find orphan
bits of ABC floating round
Anselm Lingnau wrote:
Simon Wascher [EMAIL PROTECTED] writes:
Example
X:1
Q:n/n=n N/N=N andante
I think this is much too complicated. I'm still waiting for you (or
anybody) to explain why an ABC tune should contain one prescribed
explicit metronome speed for display and another,
Hello,
Laurie Griffiths wrote:
Simon slipped in the words external macro file.
No!! I am very much against this. Although it may be convenient for
writers of ABC it's horrid for readers. It makles it even harder to extract
a tune and the probability would be very high that we should
Simon Wascher [EMAIL PROTECTED] writes:
Lets say you are right, its completely impossible that someone needs
that.
I'm not claiming that it is impossible for anybody to need this. But if
this is a sensible proposal then surely there must be an example of an
application that requires it?
Anselm == Anselm Lingnau [EMAIL PROTECTED] writes:
Anselm I'm still waiting for you (or anybody) to explain why an
Anselm ABC tune should contain one prescribed explicit metronome
Anselm speed for display and another, different, prescribed
Anselm explicit metronome speed for
35 matches
Mail list logo
