Re: [abcusers] Variant rhythmic notation

[Ulf Bro]

> I'd like to propose a variant (to be signaled by a flag, say V:-, in the
> header) where whitespace within a measure becomes the delimiter for
> beats.
>
> %Example 1

Well, your system can't do anything that abc can't do already. All your 
proposal does is to bring in a more difficult readability and significant 
problems with parsing to midi or other code. I can't see there are any 
advantages in it. Since all of us use abc since years and are perfectly 
accustomed to read it - whenever I write down a piece of music from MP3 or 
minidisc I listen to a line, write it down, play it once more and compare 
what I hear to what I have written (without converting the written to sheet 
music), I'd say that making any such changes would force me to learn a new 
system although the old one works perfectly well.

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

[abcusers] Variant rhythmic notation

[Michael Ellis]

I'm new to the list, so please accept my apologies if the suggestion
below has been covered in the past and discarded for eminently sensible
reasons.

BACKGROUND
I'm interested in abc as a human-readable notation for people, like
myself, who have what I sometime think of as the musical cousin of
dyslexia. What I mean by this is that despite many years of singing and
playing and knowing all the rules of notation, I'm still extremely
inefficient at processing certain aspects written notation. 

I find it helps a great deal to write out the names of the notes and
have for years, not knowing about the existence of abc, used a system of
my own development that is in many aspects remarkably similar to abc,
though not nearly so well-developed.  

I've only just stumbled across abc and have been avidly reading the spec
and examples. It's an elegant system and the accumulated corpus of works
available in abc is a testament to its practicality. 

I do believe, however, that the rhythmic conventions could be simplified
in a way that improves readability without sacrificing compactness or
representational power.

I'm speaking of the need to group notes according to beats. Well-written
sheet music always does this and it is a significant aid to trained
musicians.  In abc, such grouping is optional.

PROPOSAL
I'd like to propose a variant (to be signaled by a flag, say V:-, in the
header) where whitespace within a measure becomes the delimiter for
beats.  

%Example 1
M:2/4
V:-
| ab abcd |

GROUPING, CONTINUATION and SUBDIVISION
The above measure represents a group of 2 eighth-notes, ab, followed a
group of 4 sixteenth notes.

In this scheme, the dash or minus-sign would represent a continuation of
the preceding pitch. Note that in this context it is not a tie, although
its presence at the start of a beat group unambiguously indicates the
requirement for a tied representation in rendering sheet music.

%Example 2
M:4/4
V:-
| ab a--b abc -efg |

The above measure has 4 beats: 
The first, ab, is 2 eighths as in the prior example. 
The second, a--b is a dotted-eighth and a sixteenth.
The third, abc, is triplet-sixteenths with the final c
tied to the first (normal) sixteenth of the fourth beat, which concludes
with 3 normal sixteenths.

This simple representation of a fairly complex rhythm is achieved by
adopting the rule that each beat is subdivided equally into as many
parts as there are letters and dashes. 


SPANNING
For the ordinary cases of notes spanning multiple beats, use dashes.

%Example 3
M:4/4
V:-
| b - ab - | - c - - |

Above we have a half-note b followed by an eighth a and an eighth b tied
to 2 quarters across the bar line followed by a dotted half c (or 3 tied
quarters if you prefer to think of it that way).

For tuplets spanning multiple beats, use a preceding numeral to indicate
the number of beats spanned.

%Example 4
M:4/4
V:-
| 2abcde f g |

Above, the first two beats are subdivided into five notes, abcde.


DASH COMPRESSION
As a final convenience, allow trailing numerals to compress
representations that would otherwise require many dashes, e.g.  a7b
instead of  a--b to represent a double-dotted figure.

 
SUMMARY
I believe the variant proposed herein covers all rhythms expressible in
conventional notation.  Most important, it represents the rhythms as
subdivisions of uniform beats in the same manner as conventional
notation. I think this greatly improves the ease with which one can play
directly from the abc script.

As an extra benefit it is, in many instances, more compact than abc's
present conventions. 


Comments?


Cheers,
Mike Ellis







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

Re: [abcusers] this tune intentionally left blank

[John Chambers]

Jack Campin comments:
| X:0
| T:Dalnahassaig
| Z:Jack Campin  version 1.0 September 2001
| C:Pipe Major George S. McLennan
| S:Gordon Highlanders Pipe Music Collection volume I
| B:NLS Mus.D.s.19
| R:Strathspey
| M:C
| K:Hp
| % No tune body - index entry
|
| which, under John's proposal, would get an entry "TZCSBRMK*" in the
| Tune Finder.
|
| If John's software can identify bodiless tunes without any special
| signalling, maybe no ABC notation is needed for it; but it still
| seems to me that it would be a good idea to signal which tunes are
| *meant* to be that way, to distinguish bibliographies or works in
| progress from the results of communication/conversion foulups. A
| single barline, as Phil suggests, is something that couldn't easily
| comprise a complete tune body by accident, so it could be used for
| such a convention if everybody agreed on it.

I'd agree, except that I don't think the single bar line idea is  the
best. The reason is that it's already useful for a different purpose.
I've used this to get abc2ps to output a blank staff or three.  Thus,
I could write the above tune as:

X:0
T:Dalnahassaig
Z:Jack Campin  version 1.0 September 2001
C:Pipe Major George S. McLennan
S:Gordon Highlanders Pipe Music Collection volume I
B:NLS Mus.D.s.19
R:Strathspey
M:C
K:Hp
|
|
|
|

This would give me a  printout  that  has  four  blank  staves.   The
original  abc2ps  has  a  minor  bug that makes the last one slightly
short, but that doesn't matter for my purpose.   The  purpose  is  to
produce  a  sheet of paper that I can write on.  I also use this same
trick occasionally to add blank staves to a tune.  Sometimes  I  make
every other staff blank, sometimes I put them all at the bottom.

I'd suggest that the above "% No tune body - index entry" line  is  a
better  model for this sort of info.  But I'd make it "%% No tune", a
fixed string that software could look for. The rest of the line would
be treated as comment, of course, so you could include an explanation
as in this example.

I  have  one  tune  that  has  no  notes,  but  has an N: header line
explaining that the copyright holder told me I didn't have permission
to  put  it  online.   If  we agree on the "%% No Tune" idea, I could
easily add the line:

%% No tune - copyright holder denied permission.

I'd be tempted to have the Tune Finder recognize this and  append  it
(in  parens) to the title.  It'd be easy enough to do.  But I'd still
predict that only a few conscientious users (like Jack ;-) would ever
use it.


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

RE: [abcusers] this tune intentionally left blank

[Richard Walker]

There are keys like X:, T:, C:, N:, K:, etc. for everything
except the body of the tune.  Is there a left over symbol
that could precede the body of a tune?  ... or with the huge
collection of abc tunes that already exists, is it simply
best to write a program to do the check?

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

Re: [abcusers] this tune intentionally left blank

[Jack Campin]

 The  problem  is how best to say this.
 There  is a list of headers that could contain a code for "no
 notes". This field already uses a double quote to indicate that
 accompaniment chords are present. I wonder if there's a good
 single char that could stand for "notes", or maybe for "no
 notes"?  Perhaps  '*'  (asterisk) could be used for this, as it
 doesn't seem to have any other use, and it is conventionally
 used to indicate an explanatory  footnote.
>>> That sounds pretty good.
>> Maybe I'll try implementing it.
> I don't think that would be a good idea.  IMHO any characters that 
> might still be available should be reserved to signal new, more 
> productive contexts.  The "no notes" context can be easily be 
> indicated by a pseudocomment as long as a standard one be agreed 
> upon.  E.g.
>   %% End of tune

You're misunderstanding where this notation is meant to appear.
The asterisk was something for the Tune Finder to display - it
already presents a list of the header fields used in the tune,
thos would go in the same place.  In my GS MacLennan file on
the web there is this "tune":

X:0
T:Dalnahassaig
Z:Jack Campin  version 1.0 September 2001
C:Pipe Major George S. McLennan
S:Gordon Highlanders Pipe Music Collection volume I
B:NLS Mus.D.s.19
R:Strathspey
M:C
K:Hp
% No tune body - index entry

which, under John's proposal, would get an entry "TZCSBRMK*" in the
Tune Finder.

If John's software can identify bodiless tunes without any special
signalling, maybe no ABC notation is needed for it; but it still
seems to me that it would be a good idea to signal which tunes are
*meant* to be that way, to distinguish bibliographies or works in
progress from the results of communication/conversion foulups. A
single barline, as Phil suggests, is something that couldn't easily
comprise a complete tune body by accident, so it could be used for
such a convention if everybody agreed on it.

A crypto checksum (something I have been arguing in favour of for
years) would also serve the same function - you'd know exactly how
much tune there was at the moment when the checksum was generated
(which in general would be the time when the tune was made public).

-
Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760
 * food intolerance data & recipes,
Mac logic fonts, Scots traditional music files, and my CD-ROM "Embro, Embro".
--> off-list mail to "j-c" rather than "abc" at this site, please <--


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

Re: [abcusers] this tune intentionally left blank

[John Chambers]

Phil Taylor writes:
| On 7 Jun 2004, at 08:46, Paulo Eleut=E9rio Tib=FArcio wrote:
| > Em Qua 02 Jun 2004 12:47, John Chambers escreveu:
| >> Jack Campin writes:
| > [snip]
| >> | > The  problem  is how best to say this.
| >> | > There  is a list of headers that could contain a code for "no
| >> | > notes". This field already uses a double quote to indicate that
| >> | > accompaniment chords are present. I wonder if there's a good
| >> | > single char that could stand for "notes", or maybe for "no
| >> | > notes"?  Perhaps  '*'  (asterisk) could be used for this, as it
| >> | > doesn't seem to have any other use, and it is conventionally
| >> | > used to indicate an explanatory  footnote.
| >> |
| >> | That sounds pretty good.
| >>
| >> Maybe I'll try implementing it.
| >>
| > I don't think that would be a good idea.  IMHO any characters that
| > might still be available should be reserved to signal new, more
| > productive contexts.  ...

This was a total misunderstanding of what I  was  talking  about.   I
wasn't suggesting any new ABC syntax.  The question was how to get my
Tune Finder to indicate to a user that  an  ABC  "tune"  contains  no
notes.  The problem there is that the Tune Finder's output is getting
to be rather wide, making for problems using it on  a  small  screen.
Adding a wordy comment would make this problem worse.

| Why not just use a "tune" which consists of a single barline?  That is
| actually a minimal legal tune.  BarFly will display an empty staff, with
| title, composer clef and metre.  (Otherwise you get an error message
| which says "No tune".)  Not sure what other parsers will do.

One  problem  I  can  see  is  getting  people  to  follow  any  such
suggestion.  The canonical example is the fact that we can't even get
people to include an "X:" line at the start of tunes, although  ABC's
syntax  has  required it from the early days.  Getting people to type
some code to indicate that there aren't any  notes  would  be  rather
hopeless, I'd guess.  Most people would consider it as silly as those
"This page intentionally left blank" notices.  ("But  it's  obviously
not blank." ;-)

I do often include a few lines containing just a bar line  for  tunes
that  I  don't  have  the notes for.  With abc2ps, this gets me a few
staff lines when I try printing it, which is convenient  for  writing
in notes. But this is just my own occasional practice. I'd think what
we'd want software to do is flag noteless tunes with a  warning,  but
process them anyway. Tune info without notes can be useful, as we can
see by the popularity of Andrew Kuntz's Fiddler's Companion site. And
having this info in the form of ABC headers can be useful, especially
if you're the sort that likes to write little  scripts  that  combine
files in interesting ways.

I also have a few "tunes" that contain "W:" lines but no notes.  With
abc2ps,  this  gets  you  the  usual  sort of output that has titles,
notes, history, etc, plus the lyrics.  In fact, I have a little  perl
script  that  strips  out  the  notes from a tune, leaving behind the
headers and lyrics.  I don't use it much, but when I want that  done,
it's nice to have software that does it right.

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

Re: [abcusers] this tune intentionally left blank

[Phil Taylor]

On 7 Jun 2004, at 08:53, Paulo Eleutério Tibúrcio wrote:
Em Qua 02 Jun 2004 14:26, Phil Taylor escreveu:
Interesting.  If you look at the html source for the first tune in
that file it looks like this:
X:1
[snip]
It's a long way from abc.  I suspect it's actually microsoftml, and
probably written in
MS Word.
Surely is, with all that redundance in the 'mso' style tags.  You see,
this garbage is intended to solve MS Office's problems of
interoperability, not to produce anything convenient or suitable for
the Web. (In fact, if you check the source code for the page, you can
see a META element saying it was generated by "Microsoft Word 10".)
The right way to HTMLize it would be something like


X:1
T:A. A. Cameron's
M:4/4
L:1/8
R:Strathspey
K:A Mix
|:eA3 A4 B3Gd3B|eA3 A4 d3g (3f2e2d2|eA3 A4 B3Gd3B|
% And so on ...


I tried this with four different browsers, and it worked fine in all
of them.
(Of course, you'd have to substitute & < and > for any & <
and > characters respectively in the source.  Defining presentation
of the ABC segment would be simply a matter of defining a style for
a CODE element which is a child of a PRE element with classes 'music'
and 'abcnotation' set.  It would also be straightforward to parse.)
Probably better to eliminate the < and > characters entirely (they're
only shortcuts after all).
Maybe the standard should state (or at least recommend) how ABC source
code should be embedded in HTML/XML.
Using  has been suggested before.  I don't think John
likes it because the tune finder bot will still have to parse .html
files as well as .abc.  And, of course there's the problem of getting
people to use it.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] this tune intentionally left blank

[Phil Taylor]

On 7 Jun 2004, at 08:46, Paulo Eleutério Tibúrcio wrote:
Em Qua 02 Jun 2004 12:47, John Chambers escreveu:
Jack Campin writes:
[snip]
| > The  problem  is how best to say this.
| > There  is a list of headers that could contain a code for "no
| > notes". This field already uses a double quote to indicate that
| > accompaniment chords are present. I wonder if there's a good
| > single char that could stand for "notes", or maybe for "no
| > notes"?  Perhaps  '*'  (asterisk) could be used for this, as it
| > doesn't seem to have any other use, and it is conventionally
| > used to indicate an explanatory  footnote.
|
| That sounds pretty good.
Maybe I'll try implementing it.
I don't think that would be a good idea.  IMHO any characters that
might still be available should be reserved to signal new, more
productive contexts.  The "no notes" context can be easily be
indicated by a pseudocomment as long as a standard one be agreed
upon.  E.g.
%% End of tune
or
%% No notes
or
%% End of X:
Of course, this would be just a redundant way of telling parsers that
the transcriber _hasn't_ made the mistake of signaling the end of
tune prematurely.
Why not just use a "tune" which consists of a single barline?  That is
actually a minimal legal tune.  BarFly will display an empty staff, with
title, composer clef and metre.  (Otherwise you get an error message
which says "No tune".)  Not sure what other parsers will do.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] this tune intentionally left blank

[Paulo Eleutério Tibúrcio]

Em Qua 02 Jun 2004 12:47, John Chambers escreveu:
> Jack Campin writes:
[snip]
> | > The  problem  is how best to say this.
> | > There  is a list of headers that could contain a code for "no
> | > notes". This field already uses a double quote to indicate that
> | > accompaniment chords are present. I wonder if there's a good
> | > single char that could stand for "notes", or maybe for "no
> | > notes"?  Perhaps  '*'  (asterisk) could be used for this, as it
> | > doesn't seem to have any other use, and it is conventionally
> | > used to indicate an explanatory  footnote.
> |
> | That sounds pretty good.
>
> Maybe I'll try implementing it.
>
I don't think that would be a good idea.  IMHO any characters that 
might still be available should be reserved to signal new, more 
productive contexts.  The "no notes" context can be easily be 
indicated by a pseudocomment as long as a standard one be agreed 
upon.  E.g.

%% End of tune

or

%% No notes

or

%% End of X:

Of course, this would be just a redundant way of telling parsers that 
the transcriber _hasn't_ made the mistake of signaling the end of 
tune prematurely.

--
Paulo Tibúrcio

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

Re: [abcusers] this tune intentionally left blank

[Paulo Eleutério Tibúrcio]

Em Qua 02 Jun 2004 14:26, Phil Taylor escreveu:
> Interesting.  If you look at the html source for the first tune in
> that file it looks like this:
>
>  lang=EN-GB style='mso-ansi-language:EN-GB'>X class=GramE>:1
>
[snip]
>
> It's a long way from abc.  I suspect it's actually microsoftml, and
> probably written in
> MS Word.

Surely is, with all that redundance in the 'mso' style tags.  You see, 
this garbage is intended to solve MS Office's problems of 
interoperability, not to produce anything convenient or suitable for 
the Web. (In fact, if you check the source code for the page, you can 
see a META element saying it was generated by "Microsoft Word 10".)

The right way to HTMLize it would be something like



X:1
T:A. A. Cameron's
M:4/4
L:1/8
R:Strathspey
K:A Mix
|:eA3 A4 B3Gd3B|eA3 A4 d3g (3f2e2d2|eA3 A4 B3Gd3B|
% And so on ...



(Of course, you'd have to substitute & < and > for any & < 
and > characters respectively in the source.  Defining presentation 
of the ABC segment would be simply a matter of defining a style for
a CODE element which is a child of a PRE element with classes 'music' 
and 'abcnotation' set.  It would also be straightforward to parse.)

Maybe the standard should state (or at least recommend) how ABC source 
code should be embedded in HTML/XML.

--
Paulo Tibúrcio
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html