Re: [abcusers] speed of mailings & archives

2002-01-31 Thread John Chambers

Toby writes:
| Jack Campin wrote:
| > A better solution would be to edit out the email addresses and replace
| > them by names or handles so the archive ends up looking like a typical
| > web discussion board (e.g. Mudcat).  I don't mind who sees the content
| > of what I've written so long as it doesn't lead to even more spam than
| > I'm getting now.
|
|   I could write a script to do that.. I'll just replace anything after @,
| but before the . with a bunch of x's.

Or maybe just rewrite the @ as " AT " or ":" as others do. This seems
to  be  something  that humans can handle but is typically beyond the
capacity of software that is grovelling through zillions of web pages
and can't afford to use much intelligence.

I've also noticed that my MIT email addresses are in lots  of  usenet
archives, but this doesn't seem to lead to much spam.  I suspect that
spammers have learned that archives  tend  to  be  full  of  outdated
addresses, so they try to avoid them. (So maybe the thing to do is to
change all the dates to 10 years earlier.  ;-)

Actually, I get a lot more Microsoft email viruses than  spam.   I've
tried  to  tell  them  that it doesn't do any good to send viruses to
someone who reads his email on a FreeBSD or linux machine,  but  they
don't listen to me.

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] Alternate single measures

2002-01-31 Thread John Chambers

Phil Taylor writes:
| John Chambers wrote:
|
| >I wonder whether these work with other abc software.
|
| To my surprise, BarFly displays it correctly.  Playing is a mess,
| though.  It plays both alternate bars in succession on the first
| time through, then repeats back to the last double bar instead of
| to the forward repeat sign at the beginning of the part.

Hmmm ...  Somehow, I'm not  surprised.   It  does  seem  likely  that
decoding  such  alternates  (whether  for  endings  or  for  internal
measures) is materially more  difficult  for  a  player  than  for  a
formatter.   The  task  of display merely requires recognizing things
like [2 and drawing the '2' above  the  music  under  the  horizontal
bracket.   The  main  problem  is determining the end of the bracket.
Playing the music requires actually backtracking and  sequencing  the
parts correctly, which is a more complicated task.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] speed of mailings & archives

2002-01-31 Thread Toby Rider

Jack Campin wrote:
> 
> > I've been watching how the speed of the discussion on this list has
> > picked up since I put the new fast mailserver in place.
> 
> I dunno about the speed (given how slow my machines are I could hardly
> tell) but having a real honest-to-god "From" line at last is a *huge*
> relief.
> 
> > I am currently working on putting the entire archive of postings for
> > the list from the past few years online and indexing the postings with
> > Thunderstone search. I know some folks on here are sensitive about
> > having their email addresses visible on the internet. I could avoid that
> > by password protecting the archive(s). If the list members think that is
> > a good solution, or have a better solution, let me know. Thanks!
> 
> A better solution would be to edit out the email addresses and replace
> them by names or handles so the archive ends up looking like a typical
> web discussion board (e.g. Mudcat).  I don't mind who sees the content
> of what I've written so long as it doesn't lead to even more spam than
> I'm getting now.
> 


I could write a script to do that.. I'll just replace anything after @,
but before the . with a bunch of x's. 
The fix for the "From" line was actually something that got fixed
automatically by the new version of Majordomo, which I setup when I
upgraded from Sendmail to Postfix on the new machine. 
Too bad you can't tell it's faster. It has me pretty excited. I
sometimes sit there and tail the maillogs just to marvel at the speed
and efficiency :-)


Toby
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] ties and accidentals

2002-01-31 Thread Jack Campin

>| You can try to get ABC convenient, readable, close to some staff
>| notation or what ever you wan't. But first of all you must keep (or
>| get) it to contain unique (well formed or well defined if you want)
>| information.
>Well, now; I'm not sure I'd agree with that. Granted, I'd like to see
>such  a  computerized  notation, and I suspect that both the lilypond
>and MusicML people are making good progress toward such a goal. But I
>don't  think  that we should push ABC in this direction.  ABC's niche
>that led to its success is that  it's  a  relatively  simple,  basic,
>plain-text notation that is compact and mailable.  It doesn't require
>a sophisticated UI; it can be typed (and read) by mere humans.   None
>of  this  would  be true of any notation that is well formed and well
>defined.

Predicate calculus is simpler than ABC and as "well formed and well
defined" as anybody could want.  It's sloppy, ill-defined notations
that need fancy user interfaces.

As far as I can see (from examples Laura has sent me) lilypond is
nowhere near in the same league of precision as ABC - it's a random
grab-bag of typesetting hacks.

===  ===


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] speed of mailings & archives

2002-01-31 Thread Jack Campin

> I've been watching how the speed of the discussion on this list has
> picked up since I put the new fast mailserver in place.

I dunno about the speed (given how slow my machines are I could hardly
tell) but having a real honest-to-god "From" line at last is a *huge*
relief.


> I am currently working on putting the entire archive of postings for
> the list from the past few years online and indexing the postings with
> Thunderstone search. I know some folks on here are sensitive about
> having their email addresses visible on the internet. I could avoid that
> by password protecting the archive(s). If the list members think that is
> a good solution, or have a better solution, let me know. Thanks!

A better solution would be to edit out the email addresses and replace
them by names or handles so the archive ends up looking like a typical
web discussion board (e.g. Mudcat).  I don't mind who sees the content
of what I've written so long as it doesn't lead to even more spam than
I'm getting now.

===  ===


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] Alternate single measures

2002-01-31 Thread Phil Taylor

John Chambers wrote:

>I wonder whether these work with other abc software.
>

To my surprise, BarFly displays it correctly.  Playing is a mess,
though.  It plays both alternate bars in succession on the first
time through, then repeats back to the last double bar instead of
to the forward repeat sign at the beginning of the part.

Phil Taylor


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] ties and accidentals

2002-01-31 Thread John Chambers

wil writes:
| John, you need to loosen your Goedel...

Heh.  Actually, if you  think  about  it,  Goedel's  Theorem  doesn't
actually  apply  to music notation, staff or abc.  The reason is that
his theorem was only proved for  languages  of  at  least  a  certain
"minimal" expressive power, and the minimum was the ability to count.
He proved that a language that can count is either incomplete  (i.e.,
some  syntactically-valid statements have no meaning) or inconsistent
(some valid statements have two meanings).

It's strange but true that music notations don't  actually  need  (or
have)  the  ability  to  count.   So  they are below Goedel's minimum
expressive power, and could well be both complete and consistent.

I wonder if lilypond or MusicML can count?

Humans can (usually) count, so Goedel's Theorem applies to  them.   I
saw  a  cute  example  of  this  a  few years ago, in the form called
Whitely's Paradox.  In our case, we present the statement:
  Wil Macaulay cannot consistently assert this statement.
We ask Wil whether this sentence is true, and no  matter  whether  he
answers "Yes" or "No", we observe that he is contradicting himself.

We might also ask whether musicians are  below  Goedel's  minimum  in
expressive  power,  since  they routinely use a written language that
lacks the ability to count, and don't seem to notice a limitation. So
it's possible that Whitely's Paradox may not apply to musicians.

| By the way, Skink handles the alternate bar stuff you posted, but I
| have no idea what it "should" look like.   What would you have
| expected?

The two alternate bars in question should look pretty much  like  two
alternate  endings,  but  they  aren't  endings and so lack the usual
colons that indicate going back to the start.

For an example of what it might look like, try:
  http://jc.tzo.net:1742/~jc/cgi/abc/TuneList/~jc/music/abc/src/jcabc2ps/abc/
(This is on my home machine, where I've been experimenting with  some
other useful extensions.)

Scroll down to the SweetMaidOfGlendaruel entry and ask for PS or  EPS
or some other graphical form of the tune.  You see this sort of thing
a lot in bagpipe music. I was duly impressed the first time I noticed
that abc2ps handled it without complaint. Of course, it also supports
the K:Hp and K:HP gimmicks for the two common forms of Highland  Pipe
notation,  so  it's  not  that much of a surprise that other bagpipey
things are supported.

The idea here is that repeats  and  alternative  bars  are  different
concepts   that  need  not  be  confused.   It's  true  that  to  use
alternatives, you do need to repeat, else alternatives are pointless.
But  in  some  music,  a  repeated  phrase  may  vary not only in the
endings, but in other measures as well.  It's  a  curiosity  of  much
Western  music  that  variations in repeats happen mostly at the very
ends of the phrases. This isn't true of some kinds of music. One kind
is  traditional  Scottish  bagpipe  music (which could well be called
"non-Western" ;-). The people who play this music do use the ordinary
notation for alternative bars in places other than the ends of parts.

We've had a few brief discussions of this in the past.  I did  notice
some time back that abc2ps in fact had no problem with this.  It uses
the |:  and :| symbols to indicate repeats, and uses  [1  and  |1  to
indicate  something  to  be  played  the  first  time only, etc.  The
implementations of these are in fact  not  related,  and  they  don't
interact. So you can use the notation for alternate measures anywhere
you like.  The only question is how it  determines  the  end  of  the
alternates.  For [1 this is easy; it ends at [2.  For [2, it uses the
kludge of counting measures, and it only works if the alternates have
the  same number of measures.  (This could be fixed quite easily, but
that's a different topic.) It draws the final vertical line above the
staff  if it sees a double bar, and that's why I used a double bar in
my first example.

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] ties and accidentals

2002-01-31 Thread Laura Conrad

> "John" == John Chambers <[EMAIL PROTECTED]> writes:

John> That really wasn't what spurred by the  "^f-|f"  top9ic;  it  was  in
John> response  to  the  suggestion  that  we  absolutely  need  abc  to be
John> precisely defined in all cases or else it's useless. 

OK, I don't agree with that either.  But I do think defining the
ABC-note to pitch correspondence as precisely as possible makes ABC
more useful, not less so.

John> It's easy to see why people might like precision and
John> unambiguity, but that isn't likely with something as simple
John> and compact as abc.  And the claim that we even need these
John> things is disproved by the huge success of "standard" (;-)
John> staff notation.

No, I don't think so.  Staff notation is a way to communicate with
humans.  ABC is sometimes a way to communicate with humans, but also a
way to communicate with computers, which requires much more precision
and less ambiguity.

-- 
Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ )
(617) 661-8097  fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] ties and accidentals

2002-01-31 Thread Wil Macaulay

John, you need to loosen your Goedel...
By the way, Skink handles the alternate bar stuff you posted, but I
have no idea what it "should" look like.   What would you have
expected?

wil

John Chambers wrote:

> Laura writes:
> | > "John" == John Chambers <[EMAIL PROTECTED]> writes:
> |
> | John> ABC's niche that led to its success is that it's a
> | John> relatively simple, basic, plain-text notation that is
> | John> compact and mailable.  It doesn't require a sophisticated
> | John> UI; it can be typed (and read) by mere humans.
> |
> | I fail to see that ABC would be less compact or mailable if we were to
> | define the meaning in terms of pitch of "^f-|f".
>
> Heh, heh. Should I feed the troll? ;-)
>
> That really wasn't what spurred by the  "^f-|f"  top9ic;  it  was  in
> response  to  the  suggestion  that  we  absolutely  need  abc  to be
> precisely defined in all cases or else it's useless. It's easy to see
> why  people  might  like  precision  and  unambiguity, but that isn't
> likely with something as simple and compact as abc.   And  the  claim
> that  we  even  need these things is disproved by the huge success of
> "standard" (;-) staff notation.
>
> (Also, from my background as a math student I might also observe that
> Kurt  Goedel  proved that we can't even reach total precision without
> ambiguity.  But that's another topic altogether.)
>
> 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



Re: [abcusers] ties and accidentals

2002-01-31 Thread John Chambers

Laura writes:
| > "John" == John Chambers <[EMAIL PROTECTED]> writes:
|
| John> ABC's niche that led to its success is that it's a
| John> relatively simple, basic, plain-text notation that is
| John> compact and mailable.  It doesn't require a sophisticated
| John> UI; it can be typed (and read) by mere humans.
|
| I fail to see that ABC would be less compact or mailable if we were to
| define the meaning in terms of pitch of "^f-|f".

Heh, heh. Should I feed the troll? ;-)

That really wasn't what spurred by the  "^f-|f"  top9ic;  it  was  in
response  to  the  suggestion  that  we  absolutely  need  abc  to be
precisely defined in all cases or else it's useless. It's easy to see
why  people  might  like  precision  and  unambiguity, but that isn't
likely with something as simple and compact as abc.   And  the  claim
that  we  even  need these things is disproved by the huge success of
"standard" (;-) staff notation.

(Also, from my background as a math student I might also observe that
Kurt  Goedel  proved that we can't even reach total precision without
ambiguity.  But that's another topic altogether.)

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



[abcusers] Alternate single measures

2002-01-31 Thread John Chambers

Back to an older subject:  I have a few tunes in which I've
used  the  "ending"  notation  for single measures within a
section of music. This is common in bagpipe notation, but I
haven't seen it used elsewhere.  Such measures are properly
called "alternates", not "endings", of course.

For example, I have a copy of the Sweet Maid of Glendaruel,
in  which the repeat of the 2nd part differs from the first
only in bar five, which I've written as:

  ... |[1 "A"fe a>f ||[2 "A"fe "D"fd || ...

This works like a charm with abc2ps.  I've also tested this:

  ... |1 "A"fe a>f |2 "A"fe "D"fd | ...

This works with abc2ps, though the second vertical  closure
line is missing. This is unesthetic, but really not much of
a problem.

I wonder whether these work with other abc software.

For the benefit of those who'd like to test it,  here's  my
version  of  the  tune, with the lines shortened to prevent
line-wrap problems:


X: 1
T: The Sweet Maid of Glendaruel
O: Scotland
R: march
Z: John Chambers <[EMAIL PROTECTED]>
N: Scots Guard p.153
N: BSFC XI-1
M: 2/4
L: 1/8
K: AMix
|: e | "A"A>B cd | e>c Ad|cA  ec | "E7"cB Be \
 | "A"A>B cd | e>c AB/c/ | "G"d>B GB |  "A"BA A :|
|: g | "A"fe a>f | ec  Ag|fe  ac | "E7"cB Bg \
|[1 "A"fe a>f ||[2 "A"fe "D"fd || "A"ec AB/c/ | "G"d>B GB | "A"BA A :|


(Curiously, the Scots Guards book  uses  this  notation  in
other  tunes, but writes out the two parts of this one.  Go
figure ...  ;-)

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] ties and accidentals

2002-01-31 Thread Laura Conrad

> "John" == John Chambers <[EMAIL PROTECTED]> writes:

John> Anyhow, I think ABC should be kept simple.  And any problem  that  it
John> shares  with  staff  notation  is a pseudo-problem that can be easily
John> ignored by most of its users.  

This would be true if ABC were used only to generate staff notation.
However, since it's also used to generate MIDI, lilypond, and at least
potentially other applications which need a precise mapping between
ABC notes and pitches, I think it's appropriate for the standard to
prescribe such a mapping.  I don't want my toaster playing "Give my
regards to Broadway" with incorrect accidentals on the tied notes.

-- 
Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ )
(617) 661-8097  fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] ties and accidentals

2002-01-31 Thread Laura Conrad

> "John" == John Chambers <[EMAIL PROTECTED]> writes:

John> ABC's niche that led to its success is that it's a
John> relatively simple, basic, plain-text notation that is
John> compact and mailable.  It doesn't require a sophisticated
John> UI; it can be typed (and read) by mere humans. 

I fail to see that ABC would be less compact or mailable if we were to
define the meaning in terms of pitch of "^f-|f".

-- 
Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ )
(617) 661-8097  fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



[abcusers] speed of mailings & archives

2002-01-31 Thread Toby Rider

I've been watching how the speed of the discussion on this list has
picked up since I put the new fast mailserver in place. It's making me
smile :-)
I am currently working on putting the entire archive of postings for
the list from the past few years online and indexing the postings with
Thunderstone search. I know some folks on here are sensitive about
having their email addresses visible on the internet. I could avoid that
by password protecting the archive(s). If the list members think that is
a good solution, or have a better solution, let me know. Thanks!


Toby Rider
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: Re: Re: [abcusers] ties and accidentals

2002-01-31 Thread jr_davis

> Just as with standard music notation, if one is reading the ABC, if
> you don't specify the sharpness, naturalness or flatness of the second
> F in your example, is that F in the second bar supposed to be an
> F-natural or F-sharp?

In standard notation, there is no ambiguity.  The second F is assumed to
be sharp, as a rule.  I can't imagine anyone but a complete novice playing
it otherwise.
==
Well, I know a lot of complete novices at music notation who use ABC. And that was my 
point.  But I agree that the standard I have always known is that the tied F# in the 
second measure is an F#, not an F-natural.  But knowing novices, I also know that I 
hear questions about it.  But that just gives one the opportunity to educate the 
novice.  ;-)
=

In abc, there is even less ambiguity, because ties and slurs have distinct
syntaxes.  ^F-|=F is utter nonsense (according to the draft standard), and
should be written as (^F|=F) instead.  And if ^F-|=F is nonsense, then it
is equally nonsensical for abc software to interpret ^F-|F that way.

If we are going to start requiring that abc notation make the second sharp
in this example explicit, then we should require that *every* accidental
be made explicit, for the sake of consistency.  But this seems silly to
me.  abc was clearly designed to mimic standard notation to a large
extent, so it already follows many of the same rules (such as accidentals
lasting to the next barline).  To follow some rules and ignore others will
only lead to confusion.

Another problem is that if we required this example always to be written
as ^F-|^F, typesetting software would by default have to omit the second
sharp in order to conform to conventional notation.  But you run into a
problem if you want to force the second sharp to be displayed. ^F-|^F
won't do it.
=
Agreed.

Rick

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] ties and midi

2002-01-31 Thread James Allwright

On Thu 31 Jan 2002 at 03:31PM +, John Chambers wrote:
> in the passage that discusses the scope of accidentals.   The  common
> modern rule is:
> 
>An accidental persists to the next bar line or to the end  of  the
>note (including ties).  

I tried looking up the definition in a music textbook last night. It
just said to the end of the bar, no mention of notes extending beyond
bar ends. However, it could be that I need to invest in a better
music textbook :-) . Of course, the thorny issue here is that you
can't be sure you have a tied note until you work out what it's pitch
is.

I certainly think this is a potential pitfall worth documenting.

James Allwright

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: Re: [abcusers] ties and accidentals

2002-01-31 Thread jhoerr

On Thu, 31 Jan 2002 [EMAIL PROTECTED] wrote:

> Just as with standard music notation, if one is reading the ABC, if
> you don't specify the sharpness, naturalness or flatness of the second
> F in your example, is that F in the second bar supposed to be an
> F-natural or F-sharp?

In standard notation, there is no ambiguity.  The second F is assumed to
be sharp, as a rule.  I can't imagine anyone but a complete novice playing
it otherwise.

I am aware of only two situations where it is recommended in standard
notation to draw the second sharp.  The first is when the tie continues
from the end of one line to the beginning of the next.  The other is when
the second F sharp occurs simultaneously with an F natural in another
octave.  In both cases, the additional sharp is merely for clarification.  
Its absence would not indicate a natural (though it would be poor
notation).  As has been mentioned before, if you want to slur an F sharp
to an F natural, whether you cross a barline or not, the natural should be
made explicit.

In abc, there is even less ambiguity, because ties and slurs have distinct
syntaxes.  ^F-|=F is utter nonsense (according to the draft standard), and
should be written as (^F|=F) instead.  And if ^F-|=F is nonsense, then it
is equally nonsensical for abc software to interpret ^F-|F that way.

If we are going to start requiring that abc notation make the second sharp
in this example explicit, then we should require that *every* accidental
be made explicit, for the sake of consistency.  But this seems silly to
me.  abc was clearly designed to mimic standard notation to a large
extent, so it already follows many of the same rules (such as accidentals
lasting to the next barline).  To follow some rules and ignore others will
only lead to confusion.

Another problem is that if we required this example always to be written
as ^F-|^F, typesetting software would by default have to omit the second
sharp in order to conform to conventional notation.  But you run into a
problem if you want to force the second sharp to be displayed. ^F-|^F
won't do it.

John


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] ties and accidentals

2002-01-31 Thread John Chambers

Toni writes:
| ...
| > How an ABC tune is translated to staff notation, or Tabulatur, or MIDI, or whatever
| > however, will always be subject to difficulties, as there are
| > so many variants of staff notation.
|
| Yes! That's it!
| You can try to get ABC convenient, readable, close to some staff
| notation or what ever you wan't. But first of all you must keep (or get)
| it to contain unique (well formed or well defined if you want)
| information.

Well, now; I'm not sure I'd agree with that. Granted, I'd like to see
such  a  computerized  notation, and I suspect that both the lilypond
and MusicML people are making good progress toward such a goal. But I
don't  think  that we should push ABC in this direction.  ABC's niche
that led to its success is that  it's  a  relatively  simple,  basic,
plain-text notation that is compact and mailable.  It doesn't require
a sophisticated UI; it can be typed (and read) by mere humans.   None
of  this  would  be true of any notation that is well formed and well
defined.

Furthermore, such precision isn't necessary.  The proof  of  this  is
staff  notation.  It has survived for centuries, and has been adapted
to many different musical styles, despite  its  serious  deficiencies
and  ambiguities.  You could argue that its success is partly because
of these "problems".

Thus, people have spent a lot of time agonizing over the  limitations
of  the  7-note  octave  and  the 12-note chromatic scale.  But staff
notation is routinely used in many musical styles that have all sorts
of  other  scales.   Thus,  in the Middle East, it's common to simply
state the scale at the top. None of the scales actually use more than
7 notes in an octave, except in the same sense as the classical minor
scale that has an ascending and a descending form.  So 7 notes and  3
accidentals  are  sufficient  for the knowledgeable practitioners who
know how to adjust the intonation for the stated scale. Precise marks
to describe the intonation are not necessary, and just clutter up the
page and make it less readable.

Similarly, the persistence of accidentals has different rules in some
different  kinds  of  music.  This is a problem for people looking at
music in an unfamiliar  style.   But  it's  not  a  problem  for  the
"insiders" who know the style.  They know their rules, and don't need
to mess up the page with unnecessary junk.

The result is often incompatible rules in different styles.  One case
that I've seen a lot: I play traditional Scandinavian music, in which
it's common to divide the beat more or less at random into  2,  3,  4
and  5  notes.   Very  often,  the  usual tuplet notation is omitted,
because it just clutters up the music.  To do  it  accurately,  you'd
need  a tuplet thingie on half the beats, and this is just messy.  So
it's often omitted.

OTOH, in Balkan music (which I also play), this doesn't work at  all.
The music inherently uses beats of different lengths.  It's common to
have a 3-note beat followed by a 2-note beat, and the  first  is  50%
longer  than  the second.  If that first 3-note beat should be in the
same time as the  second  2-note  beat,  you  need  to  indicate  the
triplet.  So you see tuplet notation in this style.

Thus, when a Swedish musician sees something like | CDE FG AB |,  the
normal  interpretation  would  be  that the CDE is a triplet.  When a
Bulgarian musician sees this, the normal interpretation is that  this
is  a  7-count  measure whose first beat is 50% longer than the other
two.  Both of these involve sloppy, imprecise notation, and both  are
done  to  keep the notation simple.  Neither is at all confusing to a
musician who knows the style.

Anyhow, I think ABC should be kept simple.  And any problem  that  it
shares  with  staff  notation  is a pseudo-problem that can be easily
ignored by most of its users.  High precision should be left  to  the
more  sophisticated  notations  that  others are developing.  (And we
should be encouraging them to include ABC as an input/output  format,
despite its loss of information.)

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: Re: Re: [abcusers] ties and accidentals

2002-01-31 Thread Buddha Buck

At 10:37 AM 01-31-2002 -0500, [EMAIL PROTECTED] you wrote:





>=
>Excuuse me!

I'm sorry, I didn't mean to come off sounding like an ass, but I can see 
how I might have.

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: Re: Re: [abcusers] ties and accidentals

2002-01-31 Thread jr_davis


[EMAIL PROTECTED] wrote:
> At 08:30 AM 01-31-2002 -0500, [EMAIL PROTECTED] you wrote:>Hi,
>
>I have been following this discussion with interest.  Maybe that shows my 
>level of boredom, but.   ;-)
>
> > If you use ABC just as a way to save staff notation, and
> > expect translations of ABC into staff notation to look in a specific
> > way - why do you use ABC at all?
>
>Well, let's see - why do I use ABC to save staf notation?  It's simple -

 From the format of your message, I expected your reply to describe why you 
"expect translations of ABC into staff notation to look in a specific 
way".  But you don't.  You give lots of reasons to use ABC that have 
nothing to do with now the staff notation looks.

Only one of them deals with staff notation:

=
Excuuse me!
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] ties and midi

2002-01-31 Thread John Chambers

Laurie wrote:
| Atte wrote that Dr. Matt wrote 'To write a slur from F# to F you MUST always
| write a natural sign on the
| F.'
|
| Sound advice because that at least is unambiguous.
|
| The trouble is that with all questions like this, the more you probe the
| more you discover that there is no such thing as "standard" music notation.
| I would be very surprised if the advice above has always been adhered to
| down through the ages by all musicians.  If it has not been then it opens
| the question "what did the guy who wrote this mean by it?"

Yup.  And the very fact that we're discussing the topic is proof that
the issue is still with us.  It's obvious that some people here think
that ^F-|F really should mean that the second F is natural.  So you'd
expect  that  those people would write their music this way, and when
you read it, you wouldn't have any clue.  As has  been  pointed  out,
this  may be uncommon in some kinds of music, but is fairly normal in
some others.

Thoughtful writers can always put an accidental on the second F,  but
this doesn't help you when you're reading someone else's notation.

For music formatters such as abc2ps and clones, this is a  non-issue.
They  can  just  display exactly the same ambiguity as is in the abc.
But music players do need to make a guess.  A human can  often  guess
correctly,  from knowing the style, but it's not reasonable to expect
this of software.

In my experience, the more common interpretation is that  accidentals
usually  do  apply to such tied notes.  So this should be the default
interpretation for abc player programs.  A warning message  might  be
appropriate, of course, and a fancy player might include an option to
"correct" the music to the other interpretation.

It's not really very important that abc itself decree a  solution  to
this.   After  all,  staff  notation has survived centuries with this
problem, and most musicians don't even notice.  I'd  think  that  the
best  way to handle this might be to have a separate "suggestions" or
"commentary" document that mentions the ambiguity  and  suggests  the
common  interpretation as the default.  This is probably best handled
in the passage that discusses the scope of accidentals.   The  common
modern rule is:

   An accidental persists to the next bar line or to the end  of  the
   note (including ties).  But "advisory" accidentals are recommended
   to make the intention clear to readers.  Software that  plays  the
   music should include options to override this default behavior, to
   handle styles of music in which the rule is that accidentals apply
   to only one note.

We might consider standardizing a %% line that tells abc players when
this default rule is to be changed.

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] ties and midi

2002-01-31 Thread James Allwright


An amusing variant on Atte's example is :

^F- | [F^F]

Here it is not easy to decide what was meant.

James Allwright

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: Re: [abcusers] ties and accidentals

2002-01-31 Thread Buddha Buck

At 08:30 AM 01-31-2002 -0500, [EMAIL PROTECTED] you wrote:
>Hi,
>
>I have been following this discussion with interest.  Maybe that shows my 
>level of boredom, but.   ;-)
>
> > If you use ABC just as a way to save staff notation, and
> > expect translations of ABC into staff notation to look in a specific
> > way - why do you use ABC at all?
>
>Well, let's see - why do I use ABC to save staf notation?  It's simple -

 From the format of your message, I expected your reply to describe why you 
"expect translations of ABC into staff notation to look in a specific 
way".  But you don't.  You give lots of reasons to use ABC that have 
nothing to do with now the staff notation looks.

Only one of them deals with staff notation:

>7. I can get perfectly acceptable, useable staff notation using ABC for 
>the tunes (and songs) that I have collected or written out, not to mention 
>that, with abc2ps, there are number more things one can do than simple 
>music notation.

And this does not require that the ABC to staff translation have any 
particular appearance -- or at least, I don't think so, anyway.

To me, what is important about an ABC-to-staff translation is that it 
accurately represents the music so notated.  If I take a piece of sheet 
music and transcribe it into ABC, then run an abc2staff translator, I do 
not expect the two sheets of music to look identical, especially if the 
original sheet music used something currently nonstandard, like figured 
bass.  But I do expect that a competent musician should play the two sheets 
of music identically.

 > The important thing is that there is no doubt about how an ABC tune
> > shall be read or interpreted.
>
>I don't know about that.  It seems there have been a number of comments in 
>this discussion that show the opposite. Just as with standard music 
>notation, if one is reading the ABC, if you don't specify the sharpness, 
>naturalness or flatness of the second F in your example, is that F in the 
>second bar supposed to be an F-natural or F-sharp?

The standard should be unambiguous about such things.  That it is not is a 
place where the standard is failing, and needs be corrected.

>On this issue, I vote for explictness - not that programs should all do it 
>this way, but if I have to assume what is meant because either I or the 
>transcriber am/is not familiar with standard music notation "standards" 
>(or at least the same standard of music notation), I would rather the 
>transcriber be explicit than not.

The key isn't "is the reader familiar with staff music notation standards" 
the key is "is the reader familiar with ABC standards".  If ABC says, in 
one form or another, that given ^F-|FabF|, the intermensural F is sharped 
and played for twice as long as the second, natural, F, then so be it.  If 
it says it is illegal, and to get that effect, one needs to write 
^F-|^Fab=F then so be it.  Or anything else in between.

Right now, the argument is that the standard does NOT so say, and what 
^F-|FabF| means is not clear in ABC.

>So, for what it's worth, that's my two cents' worth  ;-)

Isn't it odd that people value their opinions at two cents, yet the going 
rate for thoughts is just a penny?

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: Re: [abcusers] ties and accidentals

2002-01-31 Thread jr_davis

Hi,

I have been following this discussion with interest.  Maybe that shows my level of 
boredom, but.   ;-) 

To respond to Erik's comments.

> ABC is not a pseudo-staff-notation, nor a pseudo-MIDI-format: it is > a standalone 
>music notation. 

Well, that's true, but not completely.  How one looks at ABC notation depends on one's 
use for it.  See more below


> The problem with ties and accidentals is
> easily solved; snip..

> If you use ABC just as a way to save staff notation, and
> expect translations of ABC into staff notation to look in a specific
> way - why do you use ABC at all?

Well, let's see - why do I use ABC to save staf notation?  It's simple - 

1. ABC software is *much* less expensive than, say, Finale, or several other programs.

2. ABC files are small, simple text files that are easily sent via email.

3. Because ABC files are small, one can have an incredible number (thousands) of tunes 
on a floppy.

4. As a hammered dulcimer player, I have found an incredible number of tunes on the 
internet I can download to learn.

5. And those downloaded tunes can be played using an inexpensive ABC-to-MIDI program 
so I can hear how the tune goes to learn it.

6. ABC files can be read by any ABC software (try *that* with Finale or Noteworthy 
Composer, etc.)

7. I can get perfectly acceptable, useable staff notation using ABC for the tunes (and 
songs) that I have collected or written out, not to mention that, with abc2ps, there 
are number more things one can do than simple music notation.

8. Oh yes - I can read the ABC file directly without putting it into music notation, 
but that is only a side feature for me.

So, those are the reasons I use ABC.


> The important thing is that there is no doubt about how an ABC tune
> shall be read or interpreted. 

I don't know about that.  It seems there have been a number of comments in this 
discussion that show the opposite. Just as with standard music notation, if one is 
reading the ABC, if you don't specify the sharpness, naturalness or flatness of the 
second F in your example, is that F in the second bar supposed to be an F-natural or 
F-sharp?

On this issue, I vote for explictness - not that programs should all do it this way, 
but if I have to assume what is meant because either I or the transcriber am/is not 
familiar with standard music notation "standards" (or at least the same standard of 
music notation), I would rather the transcriber be explicit than not.

So, for what it's worth, that's my two cents' worth  ;-)

Rick
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



RE: [abcusers] ties and accidentals

2002-01-31 Thread Toni Schilling

> ABC is not a pseudo-staff-notation, nor a pseudo-MIDI-format: it is a
> standalone music notation. The problem with ties and accidentals is
> easily solved; it's just to make a decision in either direction. Let's
> say we hereby decide that
...
> The important thing is that there is no doubt about how an ABC tune
> shall be read or interpreted.
...
> How an ABC tune is translated to staff notation,
or Tabulatur, or MIDI, or whatever
> however, will always be subject to difficulties, as there are
> so many variants of staff notation.

Yes! That's it!
You can try to get ABC convenient, readable, close to some staff
notation or what ever you wan't. But first of all you must keep (or get)
it to contain unique (well formed or well defined if you want)
information.
Then all interpretation problems reduce to simple translation.

"Unique" doesn't mean that there's only one way to transcribe something.
Like '123.45' or '+123.45' or '1.2345e2' mean exactly the same in C.
And there's now hidden information (at least for the compiler) in which
trancription is used.

Toni
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] ties and accidentals

2002-01-31 Thread Erik Ronström

I think we are facing serveral different problems here. IMHO we have to
distinguish between abc and staff notation.

ABC is not a pseudo-staff-notation, nor a pseudo-MIDI-format: it is a
standalone music notation. The problem with ties and accidentals is
easily solved; it's just to make a decision in either direction. Let's
say we hereby decide that

| CDE^F- | F
is equal to
| CDE^F- | ^F

This has nothing to do with how we translate this into staff notation.
Since there are obviously so many different standards in staff
notation, the way ABC should be translated to staff notation should be
solved by options in the translation program.

My point is that every ^ char doesn't have to get a corresponding #
sign, in the same way as keys in ABC are replaced with clefs and
accidentals. If you use ABC just as a way to save staff notation, and
expect translations of ABC into staff notation to look in a specific
way - why do you use ABC at all?

The important thing is that there is no doubt about how an ABC tune
shall be read or interpreted. How an ABC tune is translated to staff
notation, however, will always be subject to difficulties, as there are
so many variants of staff notation.

Erik

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html



Re: [abcusers] ties and midi

2002-01-31 Thread Laurie Griffiths

Atte wrote that Dr. Matt wrote 'To write a slur from F# to F you MUST always
write a natural sign on the
F.'

Sound advice because that at least is unambiguous.

The trouble is that with all questions like this, the more you probe the
more you discover that there is no such thing as "standard" music notation.
I would be very surprised if the advice above has always been adhered to
down through the ages by all musicians.  If it has not been then it opens
the question "what did the guy who wrote this mean by it?"

L.



To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html