Re: [abcusers] Re: ABC, AHC, Do-Re-Mi

[Jack Campin]

>> I think we're scaring the newcomers.
> That worries me too.  We could take this discussion somewhere
> else if necessary - it's not really about abc per se.  Any
> newcomers like to comment?  Or alternatively somebody post
> some tunes so this isn't the only thread in town :-)

Lemme try to do both.  How well would the matching algorithms suggested so
far do on identifying the variation-ness of variations?  Like this set?

X:70
T:To Daunton Me
C:James Oswald
S:Caledonian Pocket Companion
Q:Slow % which will probably make most ABC implementations throw a fit,
   % but it's what Oswald wrote and it damn well needs to be allowed
   % for in the standard.
M:4/4
L:1/8
K:Edor
  F>A | B2(E>F)E2(A>G) |   (F>A)(E>F)   D2 
(d>e) |\
   (fe)(dB)   (dF)E2 
 :|
(TF>E)| D2(d>e)d3 e|   (fe/f/) (e/d/)(c/B/) A3
d  |\
B2(e>f)e3 f|({a}g)f ({f}e)d B2 
(d>e) |
f2 ({a}g)f e2 ({g}f)e  |d>edB   ABde   
  |\
   (f>d)(e>B) (d>A)  (B/A/F/A/)|B2  E>F E2 
 :|
 (F>A)| B2 E2  d3 c/B/ |A(B/G/) ({A}G)(F/E/)D2  
d>e  |\
fdef  (DEF)A   |B2  E>F E2 
 :|
(TF>E)| D2(FA) d3 e|f(3(e/d/c/) dB  A3 
(d/c/)|\
BEGB  (e^de)f  |   (g/a/f/g/e/f/)(d/e/) B2 
(d>e) |
   (fe/f/  g)f(ed/e/  f)e  |d(c/B/) dF  A2 
(d>e) |\
f/(e/d/f/) e/(d/B/e/) (d/B/A/d/) (B/A/F/A/)|B2  E>F E2 
 :|
  F>A | BE2 F   G(A/B/)  AG|F/(d/c/B/)  A/(G/F/E/)  D2 
(d>e) |\
f (3(e/d/c/) d   (3(c/B/A/) BDEF   |B2  E>F E2 
 :|
(TF>E)| DF2 A2   d2   f|a(g/f/) e/d/c/B/A3 
(G/F/)|\
EG2 B2   e   Bf|   (g/a/f/)g/  (e/f/d/)e/   B2 
(d>e) |
fa2 (g/f/) (e/f/)   g2   (f/e/)|de/f/  (e/d/)(c/B/) ABde   
  |\
   (f/e/)d (e/d/)B (d/B/)A   (B/A/F/A/)|B2  E>F E2 
 :|
M:6/8
"Jig"
 F|B2E  E2F|(AF)E  D2(d/e/)|(fe)d (DE)F|(BA)F E2:|\
 F|D2d  d2e|(fe)d (BA)F|
 E2e   E2g |(fe)d B2
(d/e/)|f3  Te3 | d2B  (AB)d|(FE)D (EF)A|(BA)F E2:|


Note that this was edited using Barfly, and the formatting as staff
notation depends on BarFly's line-end design bug; you may need to add
extra continuation marks where lines of text don't end with a barline. 


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

Re: [abcusers] Rambling cross the web...

[Jack Campin]

>...I happened upon the Scots-L music list archive.
>   1. As far as I know, the Scots-L mailing list was in many ways one of
>  the precursors to abcusers and went inactive when this maillist
>  appeared.  Is that correct?

No: Scots-L was for discussion of Scottish music generally; the two
operated in parallel with distinct objectives.


>   2. Is the Scots-L back archive *supposed* to be openly available on
>  the web?
>  I mean, that's not how we do it at abcusers, and the two lists
>  have many of the same members (and I think the same moderator).

Not in my book it wasn't.  I objected violently to having any of my
messages reproduced with my email address in the clear; I didn't realize
this had been done, and as far as I'm concerned the only reason they're
there is because I'm too poor to get a court order to stop it.  This is
just plain piracy and totally irresponsible.


>   3. Is there anything in the archive not already available all over
>  the web?

Probably.  When I was on it I certainly posted things that I haven't put
anywhere else.  You're welcome to archive any of them, so long as I get
credited, and my email address & any personal email addresses I mentioned
are either removed or obscured beyond the recognition capacity of any
imaginable automatic address harvester.

I have been getting increasing amounts of spam to the "jc" address of
late, and I presume this is why.  I have never wanted that address made
public.


-
Jack Campin  *   11 Third Street, Newtongrange, Midlothian EH22 4PU, Scotland
tel 0131 6604760  fax 0870 0554975  http://www.purr.demon.co.uk/purrhome.html  food 
intolerance data & recipes, freeware Mac logic fonts, and Scottish music


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

Re: [abcusers] abc2ps variant with extended keysigs and repeats

[Jack Campin]

> I named my version jcabc2ps.  It's at:
>   http://trillian.mit.edu/~jc/music/abc/src/jcabc2ps/
>   http://trillian.mit.edu/~jc/music/abc/src/jcabc2ps.tar.gz
>
>I've tested it on linux (RedHat) and FreeBSD.  I suppose I should  be
>looking  into  getting this compiled on more kinds of machines.

Please, please somebody compile this for a 68K Mac so it'll run in
a reasonable amount of memory.

>   K:Dmaj_e_BD^f^c_e_B -- what's this one called?

"Zengule" in Turkish, "double harmonic" in English, "mayamalavagaula"
in north Indian languages, "ahavoh rabboh" in Hebrew.


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

Re: [abcusers] abc2ps variant with extended keysigs and repeats

[Jack Campin]

>> Please, please somebody compile [jcabc2ps] for a 68K Mac so it'll run
>> in a reasonable amount of memory.
>The 68K compilers are getting a bit old now, and there are zillions
>of options with respect to which runtime libraries to link to.
>It's quite hard to find a combination which works - I haven't yet
>been able to get a 68K version of yaps to work for that reason.
>Do you have MPW?  It's usually easier to get unix programs to
>compile as MPW tools, which you then use from the MPW command line.

I've got MPW but no paper manual for it - bit of a pain as it doesn't
seem to be a wing-it-from-running-across-the-menu-bar sort of system.
Compiling and running stuff in the simple terminal window you got with
Think C (or whatever they're calling it this week) was a lot easier.


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

Re: [abcusers] Re: Scan Tester's No 2

[Jack Campin]

[ oh well, I'm still here after all; also and more surprisingly,
  it looks like I'm back on Scots-L.  Thanks, Toby.  ]

> The fact that [mode notation] conveys info not in the tadpoles is
> true but unimportant. This is more a defect in standard staff notation.

But one that's very often fixed by supplementary text: the title page
of countless classical tonal pieces says if they're major or minor,
much art music composed in the modal system had a title that said which
church mode was in use, and when Middle Eastern musicians use Western-
style staff notation they say how you have to reinterpret the pitches
by giving the name of the makam.


> [...] If there were some simple, elegant way of defining arbitrary
> modes, I'd have argued for that.

What was wrong with the suggestion I made for extending ABC to handle
microtonality?  Build in an assortment of basic units for relative and
absolute pitch - semitones, cents, commas, shrutis, ratios, hertz - and
allow the user to redefine note names in terms of them by an interval
or pitch sequence.  Most users won't need to do this themselves; it only
takes one person to define what double harmonic, Bhairav or Big Ben's
bell pitches are.  They just need to know how to find the definitions.

"Annoy Bryan" time.  Pitch isn't the only place this comes up; in early
music and in the music of India and the Middle East, you also get the
notion of a metric mode.  This goes beyond a time signature in that it
specifies the repeating pattern of time values, stresses and rests that underlies a 
piece.  The idea is implicit in much British and Irish
traditional music, where the duration of upbeats remains constant for
every phrase.  An extreme example is this Appalachian song tune, with
an obsessively anapaestic modal rhythm throughout, which I've indicated
by spacing (double bar = text line end):

X:1
T:The Cruel Ship's Carpenter
S:Sharp & Karpeles, 80 English Folk Songs from the Southern Appalachians
M:C|
L:1/4
K:G Mix
D |G2 G  F|D2F  D|C2D F| G3  ||
G |G2 G  F|D2F  D|C2D F| G3  ||
G |G2_B  c|d2c =B|d2c G|_B2||(B
A)|G2 G  F|D2F  D|C2D F| G3  |]

In many musical idioms this isn't some after-the-fact musicological
exercise: for Indian or Turkish music it tells the percussionist what
to do, the mode specifies which hand strikes at each beat.




-----
Jack Campin  *   11 Third Street, Newtongrange, Midlothian EH22 4PU, Scotland
tel 0131 660 4760  *  fax 0870 055 4975  *  http://www.purr.demon.co.uk/jack/
food intolerance data & recipes, freeware Mac logic fonts, and Scottish music


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

Re: [abcusers] Scan Tester's No 2

[Jack Campin]

>>  Of course nobody says "This is in F sharp, C sharp" rather than
>> saying it's in D.  
> Actually, I have heard people say things like "Let's play it in two
> sharps" occasionally, but I'd agree that this isn't common phrasing
> in any crowd that I hang out with.

I play a lot with diatonic moothie players.  They use hand signals for
this: two fingers up for two sharps, one finger down for F...


-----
Jack Campin  *   11 Third Street, Newtongrange, Midlothian EH22 4PU, Scotland
tel 0131 660 4760  *  fax 0870 055 4975  *  http://www.purr.demon.co.uk/jack/
food intolerance data & recipes, freeware Mac logic fonts, and Scottish music


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

[abcusers] Renaissance music

[Jack Campin]

>> BarFly still insists on having barlines at the end of each line,
>> even in unmeasured music
> Yes, that's a long-standing problem resulting from a decision made
> a long time ago.  Fixing it would mean a major upheaval [...]

Wouldn't it be possible for BarFly to treat * as an alternative to
a barline for the purpose of ending a line, the way abc2mtex did?
That is, don't draw anything at that point, but treat that symbol
as otherwise equivalent to  .

This would also get round some of the problems resulting from the clash
between source legibility and even note density in the generated staff
notation.  I find myself doing this sort of thing all the time:

X:1
T:The Witches
M:C|
L:1/8
K:EMin
F|(EB)BG (FD)DF|(EB)BG (GA)B^c|   dBAG FDDF|EBAF GEE:|\
f| gfeg   Bgeg |
(fd)ad (bd)ad |[1 gfeg Bgeg|fdaf gee:|\
   [2 gfef deBd|AdFA BEE|]

but it would look more natural as:

X:2
T:The Witches
M:C|
L:1/8
K:EMin
F|(EB)BG (FD)DF| (EB)BG (GA)B^c|   dBAG FDDF|EBAF GEE:|\
f| gfeg   Bgeg |*(fd)ad (bd)ad |[1 gfeg Bgeg|fdaf gee:|\
[2 gfef deBd|AdFA BEE|]

With a long tune the first approach can look confusing.

BTW, one thing BarFly doesn't with Gregorian chant could be added quite
easily: drawing the staff in red (or with one of the staff lines in red,
I forget which one got this treatment).  In some manuscripts I've seen
it makes the notation much more readable.  This prompted by needing to
replace the ribbon on my Imagewriter II and thinking that this is one
of the few occasions where I could use its colour capability.

Square-note Petrucci-style notation would be handy, too, though BarFly
has stretchy rubber type slugs built in at a low level, so it couldn't
look quite the same.  You'd need some sort of space symbol that implied
closing a line and right-filling with blank space, as movable-type music
didn't generally try to make the last line the same length as the others.


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

[abcusers] General Monk's March

[Jack Campin]

Does anybody out there have a copy of "General Mon[c]k's March" as it
originally appeared in Playford?  The National Library of Scotland
has mislaid their copy of the relevant book, and both copies I can
find on the web are much later versions of the tune.  I don't imagine
it changed much in 100-200 years but I'd still like the original.


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

Re: [abcusers] General Monk's March

[Jack Campin]

>> Does anybody out there have a copy of "General Mon[c]k's March" as
>> it originally appeared in Playford?
> In 'The Dancing Master', 3rd. ed., Supplement, 1657, is "Lord
> Monks March", reprinted in Jeremy Barlow's 'The Complete Country
> Dance Tunes from Playford's Dancing Master', #151, Faber, 1985

What an extraordinary tune; *nothing* like the later ones I've found.
It's like a hybrid of "Whistle o'er the Lave o't" and "The Cuckoo's
Nest".  Is bar 8 for real, or is there some alternative reading?

[de-ABC2WIN-ified so I could see what was going on...]

X:1
T:The Lord Monk's March
S:Dancing Master, 3rd ed., supplement, 1657, via Barlow's book, 1985
L:1/8
M:C|
K:Dm
 FD3 F4 | cA3   c4 | Ac(dc)   A2  (GF)|(EF)(GF) E2(DC)|\
(FD3)F3d|(cA3)  f4 | e4  (d^c)(de)|^c(G3A4)  :|
 g4  a4 | f3c  (dc)(AF)| G4   d4  | G6(AB)|\
(cd)(cA) c3A|(GE)CE G3E    |(FG)(FD) (cd)(cA) | F(D3D4)  :|


-
Jack Campin  *   11 Third Street, Newtongrange, Midlothian EH22 4PU, Scotland
tel 0131 660 4760  *  fax 0870 055 4975  *  http://www.purr.demon.co.uk/jack/
food intolerance data & recipes, freeware Mac logic fonts, and Scottish music


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

Re: [abcusers] Distributing DLLs

[Jack Campin]

[sensible stuff]
> For this reason my own personal opinion is that SHIPPING DLLs IS TO BE
> AVOIDED.

For what it's worth, you get the same problem in the Mac environment,
with some applications (notably Microsoft ones) installing their own
versions of system extensions, often (particularly with Microsoft ones)
overwriting more up-to-date versions or installing things that aren't
necessary any more and just become a source of conflicts.

I once got a Mac that had had Microsoft Office installed on it.  There
was so much otherwise useless crap cluttering the system to support the
Office applications (which ran like a drain so I never used them) that
I ended up zeroing the drive and starting over so I knew what I was
dealing with.



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

Re: [abcusers] Distributing DLLs

[Jack Campin]

> I agree that installation is an important part of software
> development.  Ideally, this would be an ABC *users* mailing list...

Well, users oughta get to grumble about what developers give them.

My pet hate is excessive automation.  I DO NOT want the process of
installing system-critical software gizmos buried in an unreadable
script.  Apple goes completely over the top with this one, as their
installers use compiled forward-chaining rule networks to decide what
to put where; those are almost impossible to debug even if you can
see the source code (which you can't without a special development
kit), and Apple's tend to fail to either extreme, installing every-
thing available or giving up and installing nothing.  I've never seen
a makefile for a large piece of Unix software that actually worked to
spec without tweaking, either.

Give me the files you want in a folder, with a README saying where
you want them to go and what they do, and I'll put them there myself.
*If* I can assure myself they aren't going to step on something I've
already got.


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

Re: [abcusers] Modes (was O'Neill errors)

[Jack Campin]

> My objection to giving modes a prominent
> place in abc is that I believe abc should be a representation of
> printed music notation and not contain information that cannot be
> expressed in standard printed music notation.

It is expressed in standard notation; my copies of Frescobaldi's
Ricercare in Modo Dorico and Schubert's Symphony no.8 in B minor
express it right on the title page.

"Standard printed music notation" includes whatever explanatory
text the composer or editor thinks is necessary, helpful or fun.


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

Re: [abcusers] Re: abcusers-digest V1 #364

[Jack Campin]

>Incidentally, I would like to see a 'class' code, that would include one or
>more characters, each of which would represent a class of music to which
>the tune belongs.  Then, if there is a large archive of tunes, you can pipe
>it through a filter to extract all those in the archive that belong to the
>class of music of interest to you, whether you know the names of the
>individual tunes in the class or not.

We already have several header fields like this, all of them wildly
ambiguous and interpreted in every possible way by some transcriber
somewhere.  What do you want your new field to do, exactly?  What
*kind* of class? - I can think of class divisions like:

- transcription from live performance vs recording vs print

- raw transcription vs edited version

- final version vs draft

- fiddle vs pipe setting

- transposition for soprano vs alto voice

- grade V vs grade VIII difficulty level

- melody vs four-part harmonization

- copyright vs public domain

- laid out in portrait vs landscape format

- Gaelic vs English lyrics

- requires standard vs DADGAD guitar tuning

- banned or permitted under German anti-Nazi laws

- standard vs extended vs archaic ABC

- original copy or from a mirror site

- clean vs bawdy version

Two letters isn't going to do it, we need something extensible.  Putting
keywords in N: fields is a stopgap you can use meanwhile.


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

Re: [abcusers] Key signature accidentals

[Jack Campin]

>> Does K:^f mean sharpen the f in every octave or sharpen the f in just
>> one octave?  I usually make the assumption that an accidental in the
>> key signature applies to every octave, which rules out notation such
>> as K:^f =F
> My version interprets K:^f and K:^F  differently [...]
> I'd consider this useful, because there is a body of music that uses
> octave-spcific accidentals [...]

It might be less confusing if the default behaviour were for these
accidentals to be reflected in all octaves, with octave-specificity
being implied by usages like

   K:A Mix =G ^g % scale of the "Montgomerie" 18th century smallpipe
 % see Julian Goodacre's website for details

i.e. you have to *say* when something happens differently in different
octaves.

Best of all would be to allow these modes to be defined, on both
a per-tune and per-file basis:

  K:Montgomerie A Mix =G ^g
  ...
  K:E Montgomerie % the original pipe is in fact in E though
  % nobody would notate for it that way

And yes, this *is* a slippery slope sneakily intended to lead to support
for microtonal modes...

===  ===


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

[abcusers] abc2ps and early ornament signs

[Jack Campin]

I need to create some publication-quality staff notation using ornament
signs from the early 18th century.  There are four essential ones:

- a + over the notehead
- an = over the notehead
- a || over the notehead
- lines drawn in between two noteheads (in this context,
  it's not a glissando but an articulation effect).

and an optional one: turns notated by putting a ~ through the note stem.

Ideally, I'd like something that will support this on a small 68K Mac,
creating a PS or EPS file for each tune.  (I have no need whatever
for the book-at-a-time interface that abc4mac uses, and its memory
requirements are impossible).

I can't see myself doing the port as (a) I haven't done any Mac C
programming in the last ten years and (b) abc4mac was built with
CodeWarrior whereas the only compiler I have access to is MPW, and
I don't have any documentation for that, so my chances of figuring
out the platform dependencies before going mad are virtually nil.

Most of what I've got doesn't really work with BarFly either, as
the notes are often high above the staff and the ornament signs
get drawn through the noteheads instead of above them.

Can anybody help?

===  ===


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

[abcusers] Lewes's little local difficulty

[Jack Campin]

> For those living outside the UK, Lewes and several other towns in
> south-east England have had severe flooding over the last few days.

I posted this to uk.music.folk to mark the occasion - Marjorie Clarke
(nearby but not flooded) said she'd pass it on to someone at the Lewes
folk club, dunno if it got there...


Printed in 1667; by "L.W.", probably Lawrence White.
My source: Roxburghe Ballads v.VII p.689.

X:1
T:Aim not too high
T:Fortune My Foe
S:Simpson, The British Broadside Ballad and its Music
M:C|
L:1/4
K:G Dorian
G2 GA|B2 A2   |GdcB|A4:|\
d2 dd|d2 d2   |dfed|c4 |\
c2 fe|d3  c/B/|AGBA|G4|]


A true Relation of the Great Floods, that happened in many parts of
England in December and January last, to the undoing of Many: the
drownding of cattell and driving down of bridges and houses, the
drownding of people, and washing up corn by the roots, which was the
means of Rising the prices of corn in and about the City of London;
with a warning for all people to amend their lives lest a worse thing
befalls us.


The Tune is, Aim not to high.

Oh England, England! 'tis high time to repent,
Thy drunkenness and whordom now lament,
The Lord his judgments dayly on us pore,
Yet dayly into sin we run the more.

Thy swearing and prophaning the Lord's name,
At last it will come Home unto thy shame,
The Lord is Angry now we plainly see,
Which is the cause of all our misery.

On Sabbath days it is usual now to see
Taverns and Ale-houses filled to be,
When as the Churches empty are we know;
Man still delights to work his overthrow.

Thou that dost waste thy means upon thy pride,
On paint and patches with false hair beside,
And can't afford a penny for the Poor,
The Lord has judgments still for thee in store.

Thousands of sheep within the Fenns were lost,
Great Waters over banks a-loft were tost;
Hay-Cocks the waters likewise did suck in:
Both beast and fowl do suffer for man's sin.

Thou covetous man, which makes thy gold thy God,
'Tis time for you to dread God's heavey rod;
Forbare to gripe the widdow and fatherless!
Have mercy to the poor in their distress.

For God, his judgments still on us do pore,
If we repent his mercy lyes in store;
The heavens has wept sufficient for man's sin:
Now to repent 'tis high time to begin.

Those Floods which here has bin in England round,
Great losses many hundreds ha's found;
No cattel in the Marches then could stay,
But straight the waters made of them a prey.

Great mills that work for to keep man alive,
Those waters did against them so much strive,
They were washt down with corn and all together:
It were for man's sin that God did send such weather.

Great bridges, that were built with stone and wood,
Were broken down by this same raging flood;
Houses were overthrown, the more's the pitty,
Unto the loss of many town and city.

Corn by the Roots were washed out of ground,
As by Experience poor people has found:
which rais'd the prices of bread corn I tell ye,
The poor does suffer many hungry belly.

O Lord, look down in mercy on us all,
And give us grace upon thy name to call;
Fullness of bread to wantonness we turn,
And yet for sin we do not seem to mourn.

In many places people they were drown'd,
Infants in cradles on the shore was found;
Those Inundations have thousands annoyed,
Both men and beast by it has been destroy'd.

But now 'tis forgot as I may say,
We take delight to sin both night and day,
For all such heavey Judgments God does send
Our lives we do not strive for to amend.

'Tis not long so, as we may understand,
Since God did lay on us his heavy hand,
Of Pestilence, which made us all to weep,
To see some people drop down dead in street.

The fire also raged very sore;
It turned many thousands out of dore;
Women of child-bed in the feilds did lye,
Me thinks I hear still many dolfull cry.

Cruell and bloody wars has been also,
Thousands has lost their lives against their foe,
And now a gain these waters mounting high,
May cause many with hunger for to dye.

Jerusalem, we read, did suffer much,
Because to serve the Lord many did grutch;
A famine came and made all things so dear,
That Rats and Mice was held as dainty fare.

And more than that, they did for want of meat
Both roast and boyl their children to eat;
Poor little babies they did lye at stake,
And suffer torments for their parents' sake.

So to conclude let us our lives amend,
Then God his blessing speedily will send,
To keep this song in mind do not deny,
And all ways think that one day thou must dye.


[Remember to cite that title *in full*.]



===  ===


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

Re: [abcusers] abc2ps and early ornament signs

[Jack Campin]

>> Ideally, I'd like something that will support this on a small 68K Mac,
>> creating a PS or EPS file for each tune.  (I have no need whatever
>> for the book-at-a-time interface that abc4mac uses, and its memory
>> requirements are impossible).
> Hmm...this may kill the MusicTeX approach, since you'd need to set up
> TeX and that'll take 5-10 MB of disk space. It's by no means a RAM hog
> by modern standards, but does demand its share of memory.

Disk space isn't the problem, I've already got the OzTeX installation
and I have a gigabyte to spare.

What is a problem is that the Mac version of abc2mtex does absolutely
nothing on my system - no crash, it just writes out a couple of lines
of header file and stops.  And I've no idea how to fix it as there's
no useful configuration documentation.  I could probably figure it out
from the source, any idea where it is?


===  ===


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

Re: [abcusers] microtonal modes and pitches

[Jack Campin]

> I'm sure to be flamed for saying this, but I think that ABC is too
> strongly tied to the western 12-tone scale to bother trying to 
> accomodate micro-tonal music. I believe that if we were to try,
> then the resulting "MT-ABC" would be too hard/cumbersome to use.

The proposal I put forward was for a large subclass of microtonal
musics, not everything that might be described that way: modes with
no more than seven notes to to the octave, so that the existing
ABC notenames could be used.  This covers a vast range of idioms
already, from mediaeval Moorish lute music to the gamelan music of
south-east Asia.  Extension to modes with more than seven notes is
mostly the same problem as that posed by the Western melodic minor
scale, which ABC already handles with no trouble.

The scheme I suggested requires the following bits:

- unit conversions between the pitch measurements found in each idiom
  (cents, shrutis, commas, quartertones, numerical ratios and that's
  it).  BarFly already has this internally.

- a construct for naming a new mode and defining the pitches of those
  seven notes within it (easily fits in one 80-column line).  Again,
  BarFly is nearly there with its alternate intonations.

- the ability to use the new mode in the same way as the existing ones.

The body of a tune notated in this scheme would be *indistinguishable*
from one written to present ABC standards, so it can't be that cumbersome.
And no existing ABC would need any change.

Staff-notation programs need a little more:

- a vocabulary of microtonal sharp and flat signs (these are fairly
  standardized in Turkish music; a simpler scheme is used for modern
  Arabic music) and layout rules for their use in key signatures
  (again, a solved problem).


> I think trying to notate microtonal music in the 12-tone system is
> like trying to use metric wrenches on non-metric nuts

Turkish musicians have been using their adaptations of Western staff
notation for 200 years.  Works fine.


> On the other hand, I WOULD like a mechanism for notating some of the
> small pitch variations I hear in Irish fiddle music.

The constructs required for this are exactly what I suggested for the
extension to allow microtonal accidentals or more-than-seven-note modes.
It might be useful to allow alternatives: simple fraction-of-a-semitone
accidentals written something like

  ^/2f

for "f a quartertone sharp", and user-defined accidentals for the more
refined things you get in Turkish music, which you could define in a
header field:

  a:^4^ = + 4 comma

and use like

  ^4^f

Turkish music has six of these, all with standard signs: down or up one,
four or five commas.  But whether there are standard staff-notation signs
for them is a secondary matter; I don't think Indian music has anything
comparable, but ABC can represent what it does just fine regardless, and
playback programs don't have to care.

The point of this scheme is to get something which is (a) achievable,
and (b) general enough to encode a useful amount of real music.  You
can always think of some kind of microtonal idiom it won't cover, but
so what?  There are plenty of diatonic idioms ABC can't cover either.

Success might be best measured by how many *unsatisfied* users it gets
(i.e. people committed to using it but still wanting more).  We'd have
really made it if we got users beating on the developers for non-equally-
tempered shrutis, primary/secondary raga relationships, tetrachordal
construction, the Turkish double-24-note scale... but meanwhile how
about shipping something thay can be unhappy with?

===  ===


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

Re: [abcusers] Modes, democracy and benevolent(?) dictatorship

[Jack Campin]

> I would like to see in BarFly is a "Save as standard abc" menu
> command. A text file would be saved (and displayed) that preserves
> as much of the active file as possible without using any features
> not found in the current standard. V: lines and whatever else
> would either be stripped or "commented out" (%). What would remain
> would be readable by any program that adhered to the standard, and
> would therefore be suitable for posting publicly.

How would this command know, when dealing with a four-part harmonization
of a hymn, whether the tune was in the soprano or tenor line?

I would have no use for this.  When I violate the standard I know why
I'm doing it, and the "standard" version wouldn't express what I want.
I would rather post what I mean and leave it to the user to decide how
to handle it.  It's not like these "violations" are easy - using the
"w:" feature is a hell of a lot of work and someone who's managed to
get a text underlay right is not just going to throw it all away again.

The following is nonstandard in only one respect, the variable-length
gracenotes (I think fermatas are standard now?)  They're an essential
part of the music and if ABC can't represent them, well, as Schoenberg
said when somebody told him his violin concerto was too difficult to
play, "I want the little finger to grow longer.  I can wait."


X:1
T:Salute on the Birth of Rory Mor MacLeod
S:Kilberry Book of Ceol Mor #35
M:C
L:1/8
Q:1/4=80
K:Hp
P:Ground
{ge4d}B>{G}HB   {G}B2   c3 B|{g}f>{e}f {e}Hf2   {g}f4 |\
   {g}e2 {fege}f2   a3 e|{g}f>ea>e  {g}f4 |
   {g}B>f   {g}e>B {GBG}c3 B|{g}f>{e}f {e}Hf2   {g}f4 |\
   {g}e2 {fege}f2   a3 e|{g}f>ea>e  {g}f4||
   {g}fa {eAfA}e2   f3 c|{g}e2   {fege}f2  {ag}a4 |\
  f>e  a>e  f3 c|{g}e<{A}He {A}e2  {g}He4||
   {g}e2 {fege}f2   a3 e|{g}f>ea>e  {g}f4 |\
   {g}fa {eAfA}e2   f3 c|{g}e>f {g}e>f {ag}a4|]

===  ===


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

Re: [abcusers] Egregious example of line wrapping

[Jack Campin]

> many people who use JC's tune finder will just want the gif or midi
> as they wouldn't know what to do with the abc.  For such a user, an
> automatic fixer would be an improvement even if it only worked for
> some of the tunes.
> Perhaps the best of all solutions would be to detect the bad tunes
> and notify their owners so the problem can be fixed at source.

AAARGH!!!  if some piece of software out there was going to niggle me
about every ABC tune I've been responsible for that it couldn't handle
I'd pull the whole damn lot off the Internet.  The result of this
would be like one of those old mail-to-news-gateways that responded
to any Usenet posting by giving you non-delivery messages for sites
you'd never heard of and which you couldn't route a reply to.

The other problem is that most of the duff ABC out there either has
no traceable author or else is in collections so enormous that it
can't be fixed without a great deal of work - in the latter case the
author almost certainly knows what needs to be done.  In some cases
the author simply can't do the requisite debugging because they only
have access to some idiosyncratic ABC implementation.

It would be nice if there were some sort of ABC-archive-maintainers'
forum, but surely most of those who would be interested in such a
thing are on this list already.

===  ===


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

[abcusers] free Finale

[Jack Campin]

What are the implications of this?

Maybe we need an abc2finale translator to take advantage of it?

>Finale NotePad offered as a free download for PC & Mac's
>October 18, 2000, 9:40 am ET
>
>
>Coda Music Technology and Net4Music S.A., in their first major
>collaboration since agreeing to merge, have introduced Finale
>NotePad, a free downloadable version of Coda's music notation
>software (it's also available on CD-ROM for US $19.95)
>.
>The application, available for both Mac and Windows platforms,
>lets musicians, regardless of skill level, engrave simple music
>and do interactive editing of their own sheet music in digital
>format. The release marks a giant first step in the combined
>companies efforts to promote music education and the creative
>process through accessible, high quality music technology, says
>Net4Music CEO Francois Duliege.
>
>"With the introduction of products and services like Finale
>NotePad, we are looking to establish a common worldwide standard
>for basic music notation, and to fuel the creation of written
>music rather than focus on just the finished product,'' Duliege
>says in a press announcement. "NotePad is an excellent
>educational tool for music theory as well as a fun,
>un-intimidating way to begin putting one's musical ideas in a
>tangible form."
>
>Finale NotePad is a basic version of Coda Music Technology's
>Finale notation software. As users gain more experience with this
>level of electronic composition and arranging (and ultimately
>outgrow it), they can trade up and buy one of Coda's more fully
>featured products, Finale PrintMusic!, Finale Allegro, or Finale,
>says Duliege.

===  ===


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

Re: [abcusers] Egregious example of line wrapping

[Jack Campin]

> my Tune Finder is often asked for tunes that have ABC that's not
> compatible with the tools that my site uses.  Barfly extensions
> are a good example of this.  I can't very well adopt Barfly as
> one of my site's tools, because it is a GUI tool, and those don't
> work all that well when called by CGI scripts.

BarFly is AppleScriptable, isn't it?  So, if you've got a Mac on
your network somewhere, you should be able to tell it to:

- open the file
- go into split-screen mode
- do Print Preview
- save as PICT

and then your conversion tools can take it from there.  (The one
problem this won't fix is if the author expected landscape format
or some other offbeat viewer setting, and didn't say so in a %%Bfly
line).  Maybe BarFly might analogously be able to save its playback
as a QuickTime movie someday?

This kind of thing might be a useful route for other platforms;
I presume there's some way to drive (at least recent) Windows
applications from Visual Basic.

===  ===


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

Re: [abcusers] Gonna be off-list for a while

[Jack Campin]

> I have had an ambition to cross an ocean under sail for
> many years.  I am now going to attempt to do it. [...]
> It isn't safe to leave much sooner; you have to wait
> for the hurricane season(*) to end.

Here's something to sing on the way.  It comes from a daily
music broadside periodical produced in Leith around 1840 by
R.W. Hume.  It's obviously not Scottish, though; Hume printed
a lot of English music (and even ventured into Russian once).

X:1
T:One Night Came On a Hurricane
S:R.W. Hume, The Lyre no. 7
N:Sung by T.P. Cooke
Q:Non troppo presto
M:C|
L:1/8
K:G
d|B G G G G G G G|A A d d B2  G||\
G|F A A A A A A A|d d e e f2  d||
d|d g g f e d c B|c c c e dc  B||\
A|G G G A B A G F|G E A G GF ED||
G2 G2 G2 z2|d2 e f g< e d< B|A2 G2 G2|]

One night came on a hurricane, the sea was mountains rolling,
When Barney Buntline turn'd his quid, and said to Billy Bowling,
A strong sou-wester's blowing, Billy, can't you hear it roar now,
Lord help 'em, how I pities all unhappy folks on shore now.
   Bow, wow, wow, fal-lal-de-riddy-tiddy, bow, wow, wow.

Fool-hardy chaps as live in towns, what dangers they are all in!
And now they're quaking in their beds for fear the roof should fall in.
Poor creatures, how they envies us, and wishes, I've a notion,
For our good luck in such a storm, to be upon the ocean.
   Bow, wow, wow...

Then as to them kept out all day on business from their houses,
And late at night are walking home to cheer their babes and spouses,
While you and I upon the deck are comfortably lying,
My eyes! what tiles and chimney pots about their heads are flying!
   Bow, wow, wow...

And often have we seamen heard how men are killed or undone,
By overturns in carriages, and thieves and fires in London;
We've heard what risks all landsmen run, from noblemen to tailors -
So Billy let's thank Providence that you & I are Sailors.
   Bow, wow, wow...


===  ===


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

Re: [abcusers] free Finale

[Jack Campin]

> Is the printed output better than anything the ABC community can
> offer? If not, what's the point?

The point is that there are some users who think Finale is the only
music software in existence and are in such a state of FUD that they
will not be persuaded otherwise.  If you want to get music to them
you have to supply it in their format.


===  ===


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

RE: [abcusers] Update to jaabc2ps

[Jack Campin]

> gets() is only used in one place (in the original abc2ps code, at that). 
> Where it is used is in the interactive function and it is used to get user 
> input to select tunes.  The buffer is 500+ characters, and it's *highly* 
> unlikely that the user is going to enter more characters than that.  If 
> they should, the only thing that will happen is that the program will 
> crash.

1. User enters the search string by copy-and-paste.

2. User has copied more than they think they have.

3. Phut.

This ought to be fixed.

===  ===


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

Re: [abcusers] how to avoiding clipping PS files

[Jack Campin]

> My Tune Finder has had PDF as one of its formats for a short while
> [...] when a user clicks on a PDF link, their computer can't tell
> my CGI script what size page their printer uses.

Why not just default to a size short enough to fit on US Letter and
narrow enough to fit on A4?

One heuristic that might be worth adding is for the HP or Hp key
signatures to imply landscape format.

===  ===


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

[abcusers] accidentals in ()

[Jack Campin]

>> The syntax being discussed is nothing but a way of saying,
>> "this accidental isn't really necessary."
> No, it's a way of saying "If you're a printer program, print this with 
> parentheses around the sharp".  "This accidental isn't necessary" is
> one of the things we use parentheses to indicate, but not the only
> thing.

Then perhaps we should code those various things rather than simply
follow the ambiguity of staff notation.

One use that has been mentioned here is simply a reminder for players
of limited attention span.  A more significant one might be editorial
markings: i.e. "this isn't in the source this came from but I think
you ought to play it this way".  Another is "play it this way if your
instrument can do the accidental" (occasionally found in bagpipe sets
of tunes originally meant for other instruments, in case a non-piper
wants to use the same music).  Semantically these are all different
and ABC ought to represent them differently.

I agree with Laura that ABC-to-staff-notation software ought to allow
for alternate conventions in representing these constructs.


-
Jack Campin  *   11 Third Street, Newtongrange, Midlothian EH22 4PU, Scotland
tel 0131 660 4760  *  fax 0870 055 4975  *  http://www.purr.demon.co.uk/jack/
food intolerance data & recipes, freeware Mac logic fonts, and Scottish music


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

[abcusers] Ted Merrill's suggestions

[Jack Campin]

What Ted is suggesting is more or less what the Cornell Synthesiser
Generator was designed for; give it a lexis and an attribute grammar
and it'll build you a lexer, parser and structure editor.  (I once
supervised a student implementing an analogue of the CSG in a higher-
order persistent programming language; it worked but you had to be
rather patient waiting for the lexer optimizer to do its thing, and
the GUI primitives available for the editor were a bit spartan).

I am not too sure how much I'd like to work with ABC in a structure
editor.  I've only used two of those, loved one (Steven Vickers' Forth
for the Z80-based Jupiter Ace) and hated the other (a Dutch Pascal-
meets-Logo programming language called ABC with a horrendously self-
righteous Dijkstroid built-in methodology that made restructuring
your code a nightmare).

Is the CSG still around?  Anybody else out there used it?

===  ===


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

Re: [abcusers] jaabc2ps update

[Jack Campin]

> The only problem I'm aware of that causes an actual crash is when there
> are an uneven number of bars in the two voices of multi-voice music.

Notated bars or actual ones?

This gave one version of BarFly an interesting time.  Phil fixed it
pretty quick.  Harriet and I arrived at it by accident - she started
playing Dancing Feet and I mistook it for the other tune.  We decided
we liked the effect, a sort of Scots-traditional-meets-Steve-Reich.

X:1
T:Two At Once
M:C|
L:1/8
K:AMix
V:1 % Dancing Feet
a2 ea caAe|a2 ea caBc|a2 ea caAe|[1 faea caBe:|\
 [2 faea caBc||
V:2 % Devil in the Kitchen
e>AA2 e>A (3fed|e>AA2 g2fA   A2  e>A (3fed|[1 B>GB2 g2fGB2 g2fAA2 e>A   A2 |a>AA2 g2f>g|[1 a>A   A2  e>A (3fed|B>G B2  g2f>g:|\
[2 (3agf g>e f/af/ e>c|B>c d>e g2fhttp://www.purr.demon.co.uk/jack/
food intolerance data & recipes, freeware Mac logic fonts, and Scottish music


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

[abcusers] the Dead ABC Scrolls

[Jack Campin]

> What do the Dead Sea Scrolls sound like in abc?? :-)

There seems an obvious musical interpretation of the apocryphal Gospel
of Thomas (from the Nag Hammadi collection):

They said to Him, "Shall we then, as children, enter the Kingdom?"
Jesus said to them,

Original  Modern version
  ==

"When you make the two one,   You put your right arm in,
and when you make the
inside like the outside   your right arm out, 
and the outside like the inside,
  Your right arm in,
and the above like the below, and you shake it all about
and when you make the male and
the female one and the same,  You do the hokey cokey and your turn about
so that the male not be male
nor the female female;That's what it's all about.

[Jesus left a few verses out here]

and when you fashion eyes You put your whole self in,
in the place of an eye,   your whole self out,
and a hand in place of a hand,Your whole self in,
and a foot in place of a foot,and you shake it all about
and a likeness in
place of a likeness;  You do the hokey cokey and your turn about
then will you enter
[the Kingdom]."   That's what it's all about.

===  ===


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

[abcusers] validation & the ABC corpus

[Jack Campin]

> As for following the standard; forget it.  When I tried out my first
> attempt at an abc to Noteworthy converter it collapsed in a heap in
> the face of the rubbish that is out there in the real world.  Rubbish
> that is there because existing software allows it to be.

Existing software, or future software for that matter, is hardly going
to remove pages from the web, is it?

There are a vast number of ABC files out there which fail any imaginable
criterion of correctness, but which are still valuable because they have
the only Internet-accessible copy of some tunes.

We need some way of dealing with this, and validation isn't it.  Tools
for fixing problems *intelligently* might be (i.e. not just taking the
position "this isn't standard so I'm going to discard it").  Developing
them will take time.

One concrete example: Bruce Olson has done some remarkable work putting
broadside ballad tunes on the web (e.g. all the 600-odd tunes from
Simpson's book).  This is anything but "rubbish".  Unfortunately *all*
of it uses the insane defaults of some old version of abc2win, which
means the tempi are funereal, the default note lengths are twice what
they should be for readability, and broken rhythms are nowhere notated
in the economical way.  These are all fixable by fairly simple batch
editing, and a utility that could do it would be very handy.

===  ===


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

[abcusers] developers/users

[Jack Campin]

Laura:
>> The reason the guitar chord notation got co-opted for text annotations
>> is that many, many users needed a text annotation of some kind.
Bryan:
> No.  This is a reason for developing a text annotation system, not a reason 
> for co-opting the guitar chord notation.  Couldn't they have developed 
> something new instead of messing up something that already existed?

Not all users are developers.  With my hardware, the only ABC app I can
run is BarFly, which is not user-extensible.  For one group of projects
I needed something - anything - that would let me put 1700ish ornament
signs into the ABC score and let me print them in staff notation after
a fashion.  So I just used things like "=" and "||" to represent them,
or in some places used Mac-specific 8-bit characters.  This looks
horrible with recorder or flute music because they crash into the
noteheads, but at least I know I've got an accurate transcription of
the manuscripts I was working with.  Someday some piece of ABC software
will be able to print it in a score somebody else but me can read, maybe
after a bit of trivial search/replace.

This particular user doesn't give a damn about conflicts with the guitar
chord syntax because I never need to write guitar chordings (and usually
remove them from other people's ABC before using it myself).

The Internet tune exchange aspect of ABC is also irrelevant to this
stuff since I've never shared the bulk of it in source form with anybody
else and am not likely to any time soon.

Developers are *not* the only people who get a say in what ABC ought
to be, or what it should be used for.

Question prompted by the above: is there any ABC implementation out
there with the ability to automatically place guitar chords or text
annotations clear of notes on leger lines?

Entirely non-ABC-related question: is there a free or bundled-with-an-OS
TrueType Mac symbol font with sharp, flat and natural signs?

===  ===


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

Re: [abcusers] developers/users

[Jack Campin]

>> Developers are *not* the only people who get a say in what ABC ought
>> to be, or what it should be used for.
> O yes they are!  all the Linux  software for abc is FREE, so I think
> nobody has the right to ask the `developers' to do ANYTHING. - without
> paying them that is! 

The point is that since ABC is just text, a user like me can put whatever
the hell they like in it, and whether any computer implementation can
make sense of it is a secondary issue.  Luckily for me, BarFly doesn't
get too badly flummoxed by the notations I need to use.

ABC doesn't even need to be constrained by typeability.  I have hundreds
of pages of ABC written in pencil.  For most of it, I notated the slurs
by drawing them above the text lines in the same way as in staff notation:
much more readable, and easy to convert when I got round to typing it in.
I don't give a damn whether anyone implements a computer analogue of that.

I also have a bunch of cue cards written in two colours of ink giving
the first bar or two of tunes in sets I play.  Needless to say these do
not have regular header fields, they'd be a waste of space.  It's non-
standard and non-computer-processable ABC but it's still ABC (i.e. any
human who knew the notation could read it) and it's useful.


> That way, abc  can still be used to `sketch' the music & express
> the salient points, whilst adding the `bells and whistles' using
> something else that CAN ALREADY do it...
> This could of course, result in loss of detail when abc is re-exported,
> which one would have to accept, since any conceivable abc notation
> will still  probably be insufficient for a lot of the advanced music 
> typograpy..

This is arse-backwards for what I'm doing.  I need to be able to notate
every single musically relevant detail from my sources - mistakes and
all.  Some of this information might be lost in editing/typesetting.
My ABC source is richer in musical information than a typographic file
would be.


> The only other course open to someone determined not to pay
> for software but still wanting special funstions is to do
> what the rest of us do -  get out gcc / emacs / TeX and get started!

I'd like to, but (a) the abc2mtex port for the Mac doesn't work and is
unsupported and (b) nobody's done an MPW port of any PS or TeX converter
that I could use as a starting point (MPW is the only free C compiler
for the Mac).  I know zilch about GUI programming, have no interest in
learning it, and am not about to waste a year of my life reinventing
wheels.  If I can get one of my old Suns working, I'll be in a better
position to do some ABC implementation, as I'll be able to disregard
the GUI stuff.

===  ===


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

Re: [abcusers] developers/users

[Jack Campin]

> Well giving them software that produces "abc" that is inconsistent with
> any other abc isn't exactly doing them favours is it?

BarFly doesn't produce ABC, the user does.  It's a text editor that
*can* create ABC but doesn't impose any structure at all on the
documents it produces.

Thank God.  I'd find any other model useless.

===  ===


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

Re: [abcusers] !

[Jack Campin]

>>> But what about the use of ! as a delimeter in 1.7.6.
>> The potential conflict with abc2win code can be resolved fairly easily
>> in the parser by looking forward to see if an ! is at the end of a line
>> or not.
> Yes, but what does abc2win do with an exclamation mark in the middle
> of a line?

>From what other people are saying it seems like it does the sensible thing.

BarFly needs ! too.  You can presumably use it to detect when a line
has been completed without there being a barline at the end.  Which
would make those of us who want to write open-ended lines very happy.
It would also make me happy because using ! in mid-line helps me
resolve the conflict between writing ABC in a manner optimized for
source readability and having it laid out sensibly on the printed page.

Obviously not many people yet care about having their source readable,
but as ABC matures there are going to be an increasing number of people
for whom it is their first musical notation - like blind users - and
the kind of ABC they're going to want to use is the legibly-laid-out
variety.


> I fail to see the necessity for any more text delimiters in the music.

Me too.  This !...! syntax is a disaster waiting to happen because of its
incompatibility with abc2win and needs to be stepped on before it spreads.


===  ===


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

[abcusers] Global Accidentals

[Jack Campin]

>> If you read the 1.6 spec carefully, what it says is that the
>> things called "global accidentals" are to be drawn before all the
>> notes in the tune.  It says "... for example, K:D =c would write the
>> key signature as two sharps (key of D) but then mark every c as
>> natural " It also states that such accidentals are separated from
>> each other and the key signature by spaces.
> Does anyone have a requirement for global accidentals as described above?
> Would anyone object if they were dropped and you got the ability to add
> accidentals to the key signature instead ? If the answer to both of these 
> is "no", then we should adopt the key signature implementation of global
> accidentals.

I think this should be a preference settable in the application rather
than part of ABC itself.  Example of where you might want this: the
Scots song/strathspey "Tullochgorum" is in the mixolydian mode with
the seventh very strongly emphasized.  If I was typesetting this for
myself, I'd put that information in the key signature.  But almost
every copy of the tune notated in the last 250 years has done it the
other way, so there has got to be a market for that option.

===  ===


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

Re: [abcusers] developers/user

[Jack Campin]

 >Let's start from your last example. In the header, there is:
>   K:D_B_e=C^F^c
>
> Then, when reading the (automatically printed) score, I will find a
> strange key signature (here with a treble clef) which may look like:
>
>  # 
>   b
> ---
> #
> -- b --
> 
> ---
>
> ---
>
> -- = --
>
> ('=' for natural sign)

> May I tell I never saw such a thing in my life, and I hope this will
> never happen :) [...]

> Let's be serious: standard key signatures are needed by *all* musicians.
> When there are strange notes in a tune, these ones shall be indicated by
> explicit accidentals. This is (I think) the result of many centuries, so
> why had ABC not to follow these basic rules?

What John describes is absolutely standard practice in Turkish music and
has been for a very long time.  What I think is the most-used college
textbook on Turkish art music, Ismail Hakki Özkan's "Türk Mûsikîsi
Nazariyati ve Usûlleri", not only mixes sharps and flats in the same key
signature, it also mixes in microtonal sharps and flats as well, and for
most pieces also needs accidentals, which may also be microtonal.

Özkan doesn't use the variant-octave notation John suggests, but it
would be useful sometimes (in the makam Sabâ, he leaves this variation
notationally implicit, which kinda makes sense as it's one of the
trickiest scales in the repertoire and anybody venturing into it would
presumably know what they were doing without being told by any signs).

Here is a familiar Northumbrian tune that would be most cleanly
represented using John's proposal:

X:1
T:Oh I Hae Seen the Roses Blaw
M:6/8
L:1/8
K:G =f ^F  % low F's sharp, high F's natural
D|G2G B>AB|c2A F2D|G>AG B2c|d2g d2c|B2c d2e|f2d B2G|d>ed cBA|G3 G2:|
d|g2d B2G |c2A F2D|g2d  B2c|d2g d2c|B2c d2e|f2d B2G|d>ed cBA|G3 G2:|

One reason why this makes sense here is that this was probably a
(keyless) bagpipe tune originally, and those pitches would have
been fixed for the intended instrument.  On a pipe like that you
can't do any pitch adjustment of individual notes, so accidental
signs are just an irritating excrescence that breaks up the flow
while you're reading.  Putting the tonality in the key signature
tells you what you want to know when you need to know it: can my
pipe play this tune or not?

===  ===


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

[abcusers] variant-octave key signatures

[Jack Campin]

I quoted this tune, and its bagpipe origin, as an example of where
key signatures that allow for different pitches in different octaves
might be handy:

X:1
T:Oh I Hae Seen the Roses Blaw
M:6/8
L:1/8
K:G =f ^F  % low F's sharp, high F's natural
D|G2G B>AB|c2A F2D|G>AG B2c|d2g d2c|B2c d2e|f2d B2G|d>ed cBA|G3 G2:|
d|g2d B2G |c2A F2D|g2d  B2c|d2g d2c|B2c d2e|f2d B2G|d>ed cBA|G3 G2:|

What I entirely forgot to mention is what I *actually* do with that
tune, which makes an even better example.  I play it with a clarsach
(diatonic lever harp) player.  What she needs to know is which levers
to set before playing; harpists can flip levers in mid-tune, but it
gets in the way of doing anything interesting with the left hand.  So,
she sets the lever that sharpens the low F and leaves the upper one
unset.  Variant-octave key signatures are exactly right for notating
what she does.  An accidental before each note tells a harpist FLIP A
LEVER HERE AND PUT IT BACK AS SOON AS POSSIBLE, which (in the absence
of pencilled annotations) lets the player in for unnecessary work.

On her wire harp, this notation is even more useful - there are no
levers, so you have to use a fixed tuning for the whole piece.

Now can somebody suggest a key signature for Carlos Salzedo's trick
of threading a banknote through some of the strings?...


===  ===


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

[abcusers] problems with the R: field

[Jack Campin]

> I think there are already examples where extra information 
> may need to be added in order to make abc unambiguous.  A simple 
> example is making  | Ac Bd | sound a little more like |A>c B>d |
> simply by adding R:hornpipe to the header.

except that hornpipes aren't always played dotted.  You would need
yet *another* level of extra information to say the style you're
using is one where this dotted interpretation is appropriate.

The R: field is long due for deprecation.  There is no standard
list of what rhythms it covers and what to do with them, and nobody
seems interested in making it extensible in any way that would allow
different users to agree on what their extensions mean.  Why not
just let it die so that the name can be reused for something more
important and more definable?

And some of the rhythmic types found in folk music are unimplementable
by any playback software.  A slow strathspey is intrinsically a form
where the player is *expected* to do their own thing with the rhythm.
They are only ever played solo.  What is a MIDI program supposed to do
with this?  Rubato driven by a random number generator?

===  ===


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

Re: [abcusers] gracenotes

[Jack Campin]

> I think the distinction between graces that steal time from the 
> previous note and those which steal from the following is
> musically important.

There is a third category - gracenotes that add time, making the
barlengths uneven.  This happens in piobaireachd (as well as the
other kinds).  It isn't always notated, you are supposed to get
it from your teacher.

===  ===


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

Re: [abcusers] gracenotes

[Jack Campin]

Nickl Karoly worte:
> Hungarian folk songs use grace notes after a main note very often, but
> you will find them also in Bach's concertos.

You can hear these Hungarian gracenotes on any of Marta Sebestyen's
recordings or in print in the transcriptions by Bartok and Kodaly.

Representing Bartok's material in ABC would require substantial extensions
(different lengths of gracenote, glissandi) as well as (the present topic)
implementing already-standard features correctly.

BarFly manages to play and print the following as a recognizable tune,
with one glitch and ignoring the different lengths of gracenote.  This
was presumably transcribed off a field recording - Bartok would have
wanted a midi-to-ABC tool if he was working today.

X:1
T:A virágok vetélkedése
B:Bartók/Kodály, Transylvanian Hungarian Folksongs
N:The 8-bit characters are deliberate.  I think it's just plain
N:offensive to insist that speakers of languages other than English
N:should go through hoops learning TeX character codes so they can
N:use their own alphabet, and the TeX crap needs to be deep-sixed
N:as soon as possible.
Z:Jack Campin 2001 (from a paper copy I made 20 years ago)
M:4/4
%M:(4/4) % what they actually wrote, meaning it isn't strict
L:1/4
Q:1/4=86
%Q:Lento, poco rubato 1/4=84-88 % what they actually wrote
N:"I" is BarFly's inverted-fermata sign, "H" is a fermata
N:The very long lines are to align the beats right in the source
N:Things I couldn't get into the ABC:
N: 1. the B gracenote in bar 1 and G gracenote in bar 4 have crossed flags
N: 2. I *think* the fermata and inverted fermata are meant, but the printed
N:signs don't have dots.
K:G mixolydian
(D/| G) B({B}d2-{(3ded})  |  (d{c/B/}) (c{B/A/}) 
(B2{c/B/A/}.B/) z/ z|
  ({B/c/}d2{c/B})c (B{c/B/}{A/B/})|  (c{B/A/}) (B{G})HA2   
Hz|
 A B  ({A/B/}c2{d/c/B/})  |   ({B}d2{c/B}) ({A/}B/) 
(HG3/{A/B/})z|
  ({A/B/}c{B/A/}) (B{A/G}) (IA2{G})   |({G/A/}B{A/G/}) JAHG2   
 |]

Is there any more Hungarian stuff like this in ABC already?

For examples of gracenotes after the melody note in Scottish music, see
Nathaniel Gow's "Vocal Melodies of Scotland".  Nowhere near as many as
in Hungarian music but a lot of his transcriptions have a few of them.

===  ===


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

Re: [abcusers] Chord notation

[Jack Campin]

> = |
> = X
> = [][/]
> = 
> = 
> = []
> = A|B|C|D|E|F|G
> = #|b
> = m|m7||maj7|dim|aug|!|4|5|6|7|9

This looks reasonable, but it allows no way to write a bare octave (the
commonest kind of chord in bass lines for 18th century Scottish music).
Add 8 as another modifier?

This is a cello or harpsi chord rather than a guitar chord, though.  But
shouldn't the chord mechanism support other chordal instruments too, like
mandolin or 5-string banjo?  (Laurie's suggestion is fine for Stradella-
bass accordion, so that's one extra covered already).  What if anything
would you want to be different for other string things?


One beef.  Why are the accidentals given that way?  ABC has an irritating
non-uniformity here: you write flats and sharps prefixed with ^ and _ if
they occur as accidentals in the melody line of a piece, b and # postfixed
in the key signature and in chords.  Couldn't a uniform notation (^ and _
prefixed everywhere) be supported?


Is this an appropriate moment to suggest throwing in roman-numeral and
figured-bass notations as well?


> I prefer "F#m" to be the canonical way to write the chord of F sharp
> minor because it fits into tadpoles notation more briefly.  Long chord
> names just take up too much room, especially if there are several per bar.

How the chords are printed in tadpoles doesn't have to be determined by
how they're represented in the ABC source, does it?  A sufficiently
intelligent program, seeing this in a piece in A, could have an option
to print "VI" instead, or write the whole chord part out explicitly on
a separate bass stave.  Parsing "F sharp minor" to print "F#m" should
be easy.

===  ===


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

Re: [abcusers] Chord notation

[Jack Campin]

>> 3) allow chord 'dialects'...
> Option 1 obviously means chaos.  Option 3 means chaos too.
> As an implementer I just don't see myself supporting multiple different
> and incompatible dialects.  Writing the code would be OK - just have a
> pile of tables.  Supporting it and answering the questions from completely
> confused customers would be a nightmare.

The tables don't need to be in the application, they can be in the ABC
files.  BarFly already allows for something like that with its macro
mechanism: I can write the macro

   m:Mn = [npr]

in the header to define to get a major chord, so that if I later write MC,
in the tune body it will be expanded to [C,E,G,] .  This isn't yet enough
for a guitar chord mechanism, as a particular macro only applies to notes
of one length, but an analogous syntax ought to work for an extensible
chord mechanism; it only has to give the user access to functionality
that's already there in the ABC application.  A possible syntax might be
to give the relative pitches by specifying one case:

  g:A dim = [A c _e]

in the header, and then "G dim" in the tune body would represent a chord
containing the pitch classes G, B flat and D flat.  (I'm assuming the
program can do implicit transposition; there are other ways to notate
the same information, like that of the BarFly macro system used above -
I don't think there would be much difference in usability).

If the meaning of the chord symbols is right there in the tune file,
using the same notation already used in ABC, the user isn't likely to
get confused.


>>...Parsing "F sharp minor" to print "F#m" should be easy.
> No, it's impossible - because the range of things that
> might mean F#m is unlimited.

You missed the point.  A user should not be constrained by a programmer's
idea of how to print chord names.  This should be a display option.  (My
preference for this particular chord would be a lower-case f followed by
a sharp sign, *not* a hash symbol).

The problem with the present staff display options for chords in ABC is
that are driven by their crappy ASCII approximations.  Using a "b" for
a flat in the staff notation looks amateurish, but the present design
encourages implementers to do exactly that by just printing the user's
ABC notation for the chord verbatim.  A design that decouples input
notation from displayed notation would avoid that mistake.  (The only
occasion I can think of when displaying flats and sharps in ASCII would
have any positive benefit is when generating a chord chart in Braille
for a blind guitarist).

One particularly useful display format for guitar chords would be to
expand them into left-hand piano chords and put them on a different
stave.  This could be a handy starting point for somebody doing a
keyboard arrangement.


===  ===


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

[abcusers] Chord notation

[Jack Campin]

> [someday we may standardize the syntax for defining chords and assigning
> synonyms, but that can wait]

No it can't wait.  The current proposals are tending towards minuscule
tinkering with the existing spec, adding no new functionality.  Frank's
tirade about ABC being mired in the idioms of British Isles folk music
was dead on target; the one genre where a much more expressive chord
system would help is jazz, and there is *no point whatever* in fidgety
little tweaks if they don't *fully* support its harmonic idioms.  The
only remotely plausible way to do it is by allowing user extensibility.
Get this right and a whole new user community can make use of ABC.  In
comparison with something like the V: or w: fields this is trivial, so
why standardize a half-arsed modificaltion?


: To be honest, I wouldn't feel bad if, at this stage in the development
: of abc, there were no notation for chords with missing notes.

Nowadays, the most popular button boxes for Irish music omit the thirds
in the bass chords (and some other designs let you switch them in and
out).  It's crazy not to support one of the central instruments of the
most popular genre ABC is used for.

===  ===


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

Re: [abcusers] The abc committee (Was: Hi)

[Jack Campin]

> I was one of the people who was asked to join the committee, but I
> declined, suggesting they should concentrate on the major abc developers
> instead, and that's more or less how it happened.
> With hindsight I might agree it wasn't the perfect solution. Among other
> things it left Jack Campin and - as far as I know - Robert Bley-Vroman out.

I'm happy with the present setup; the people on the committee have always
listened to my suggestions, and small committees work better than big ones.

I spent a couple of years being something like a diplomatic envoy in
a multi-site, multinational software project once, and if I was going
to do it again I'd prefer to have free flights to interesting places
as part of the deal like I did back then.

=== <http://www.purr.demon.co.uk/jack/> ===


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

Re: [abcusers] Modes and key signatures (Was: Hi)

[Jack Campin]

> See if I've got this right:
>
> K:   RootMode Key signature
> Dlyd D   lydian   F# - C# - G#
> DD   majorF# - C#
> D^e_fD   sillyE# - Fb
> D^f^c=g  D   none F# - C# - G natural
> _b   +-unspecified-+  Bb

This last one seems potentially disastrous, as almost any newcomer
to ABC would assume it meant B flat major (in fact it's the way I'd
*prefer* to write B flat major).

How about a new keyword to warn the user when one of these oddities
is coming?

  K:none _b

for that example where no root is given, or

  K:G none _b % synonymous with G dorian

where we state the root but import no assumptions from modal theory
about what the key signature is.  (I don't think this is generally
a good idea; people should be encouraged to give names to unusual
modes, even if they are fairly arbitrary like the Kurdish examples
I posted here a while back).

"none" would also allow converters from other notation systems to get
the key signature right while providing the reader with the information
that the key/mode specification was incomplete and some human editing
still had to be done.

The other use of a "none" key or mode is when using an automatic
transposer (like BarFly's built-in utility) for atonal music; the
required behaviour is different than when transposing a piece in C.

===  ===


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

Re: [abcusers] Modes and key signatures (Was: Hi)

[Jack Campin]

>> But is there a compelling reason why we should not define "E hejaz" or
>> "E freygish"?  (in a similar manner to the definition proposed for chords)
> We certainly could do that, or better, provide a means for users to define
> their own named modes.  However, there will be some problems with the
> wierder ones.  Some scales extend over more than one octave, so you
> would not only have to supply the tonic but also specify which octave
> it's in.

This one has been covered in recent discussions.  I think John Chambers
and I between us posted enough to pin it down.

> Some scales use different accidentals going up and coming
> down, so you can't just write one key signature.

The way this is handled in Turkish staff notation is the same
way Western music does it with the melodic minor scale: pick one
direction (usually down) as primary and represent the other by
accidentals.  If you needed more information, you'd probably want
a list of the typical cadential phrases of the makam/raga/dastgah
instead of just up/down signatures.  That's too much to add to ABC.

I would suggest NOT freezing in any ABC-wide definitions for non-
Western scales, because the same terms mean different things in
different cultures.  This will be particularly important when ABC
finally has microtones; Turkish and Arabic versions of the same
scales are defined in terms of different basic pitch measurements.

===  ===


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

[abcusers] do these chords have a standard meaning?

[Jack Campin]

>From John Chambers' site:

X:2
T:John D. Burgess
C:Geo.Cockburn
R:jig, pipe march
Z:1997 by John Chambers <[EMAIL PROTECTED]>
N:"Edcath"
M:6/8
L:1/8
K:D
A   |"D"f3  "A7"gfe|"D" d3  "(A)"A3 |"D" d2e "F#m"f2a|"Em" agf "A7"e2A |\
 "D"f3  "A7"gfe|"D" d3  "A7" c2B|"D" Adf "G"  aAg|"A7" fAe "D" d2 :|
A   |"D"f2d "Em"e2B|"G" dcB "(A)"A3 |"D" d2e "F#m"f2a|"Em" agf "A7"e2A |\
 "D"f2d "Em"e2B|"G" dcB "(A)"A3 |"D" Adf "G"  aAg|"A7" fAe "D" d2 ||
A   |"D"f2d "A7"e2B|"G" dcB "(A)"A3 |"D" d2e "F#m"f2a|"Em" agf "A7"e2A |\
 "D"f3  "A7"gfe|"D" d3  "A7" c2B|"D" Adf "G"  aAg|"A7" fAe "D" d2 ||
B   |"D"Adf a2g|fde  f3 |"A7"Ace  g2f|"E7" eBc "A7"dcB |\
 "D"Adf a2g|fde  f2B|"D" Adf "G"  aAg|"A7" fAe "D" d2 :|
A   |"D"aAa "A7"a2g|"D" f3  "(A)"A3 |"D" d2e "F#m"f2a|"Em" agf "A7"e2A |\
 "D"aAa "A7"a2g|"Bm"f3  "Em" d2B|"D" Adf "G"  aAg|"A7" fAe "D" d2 ||
f/g/|"D"aAa "A7"a2g|"D" f3  "(A)"A3 |"D" d2e "F#m"f2a|"EmG"agf "A7"e2A |\
 "D"f3  "A7"gfe|"E7"d3  "A7" c2B|"D" Adf "G"  aAg|"A7" fAe "D" d2 |]

Is "(A)" just the single bass note on an accordion, or what?

Is "EmG" a pair of alternatives?

===  ===


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

[abcusers] parts, voices and ostinatos

[Jack Campin]

For something like this it would be handy if we could write the
ostinato part just once (there is only one bar of it, not 18).
Any ideas for a sane extension of the P: syntax that would do it?

(Eliminate the "program" bits if you don't have BarFly).

X:1
T:Lamma bada
O:mediaeval Andalus
Z:Jack Campin 2001
M:10/8
L:1/16
V:1  program 1 74
V:2 bass program 1 46
K:G Minor ^f
V:1 x2 |x2 x2 x2   x2 x2  x2  x2  x2  x2 x2 |x2  x2 x2  x2  x2 x2  x2  x2  x2 D2 |
V:2 D,2|G,2z2 D,2  G,2z2  D,2 D,2 G,2 z2 D,2|G,2 z2 D,2 G,2 z2 D,2 D,2 G,2 z2 D,2|
%
V:1 G4   (AB) (cBBA)  AG(GF)  G4(AB)|c4 d2  B3A   (AGG)F   G4(AG)|
V:2 G,2z2 D,2  G,2z2  D,2 D,2 G,2 z2 D,2|G,2 z2 D,2 G,2 z2 D,2 D,2 G,2 z2 D,2|
%
V:1 F4G2  (E3D)   ED(EF)  D4(ed)|c4 d2  B3A   (AGG)F   G4 D2 |
V:2 G,2z2 D,2  G,2z2  D,2 D,2 G,2 z2 D,2|G,2 z2 D,2 G,2 z2 D,2 D,2 G,2 z2 D,2|
%
V:1 G4   (AB) (cBBA)  AGGFG4(AB)|c4 d2  B3A   (AGGF)   G4(AG)|
V:2 G,2z2 D,2  G,2z2  D,2 D,2 G,2 z2 D,2|G,2 z2 D,2 G,2 z2 D,2 D,2 G,2 z2 D,2|
%
V:1 F4G2  (E3D)   ED(EF)  D4(ed)|c4 d2  B3A   (AGG)F   G4 D2 |
V:2 G,2z2 D,2  G,2z2  D,2 D,2 G,2 z2 D,2|G,2 z2 D,2 G,2 z2 D,2 D,2 G,2 z2 D,2|
%
V:1 G4   (AB) (cBBA) (AGG)F   G4 D2 |G4 A2  B4(B2A)c   B4 G2 |
V:2 G,2z2 D,2  G,2z2  D,2 D,2 G,2 z2 D,2|G,2 z2 D,2 G,2 z2 D,2 D,2 G,2 z2 D,2|
%
V:1 d4c2  (cBBA) (AGG=F) (G2AB){AG} =F2 |G4 A2  B4(B2A)c   B4 G2 |
V:2 G,2z2 D,2  G,2z2  D,2 D,2 G,2 z2 D,2|G,2 z2 D,2 G,2 z2 D,2 D,2 G,2 z2 D,2|
%
V:1 c4d2   B3A   (AGG)F   G4(AG)|F4 G2 (FEED) (EDE)G   D4(ed)|
V:2 G,2z2 D,2  G,2z2  D,2 D,2 G,2 z2 D,2|G,2 z2 D,2 G,2 z2 D,2 D,2 G,2 z2 D,2|
%
V:1 c4d2  (B3A)  (AGG)F   G4(AB)|c4 d2  B3A   (AGG)F   G4   |]
V:2 G,2z2 D,2  G,2z2  D,2 D,2 G,2 z2 D,2|G,2 z2 D,2 G,2 z2 D,2 D,2 G,2 z2   |]


===  ===


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

Re: [abcusers] Making PDF (Was: ABC standards committee webpage)

[Jack Campin]

>> How on earth do you create those pdf documents?
> [...] GhostScript does not support bookmarks and other fancy PDF
> functions, but it does make good basic PDF documents from postscript
> files. The problem for most Windows and MAcintosh users is to get
> postscript files in the first place

If you have a laser printer driver for a Mac this is just matter of
holding down some key combination when you select "Print".  Can't
remember quite what, but you get a PostScript file instead of a print
job.  This has been standard on Macs since the 1980s.

===  ===


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

Re: [abcusers] Composer/Lyricist Distinction

[Jack Campin]

> Currently, the C: flag indicates the composer field.  ABC shows its 
> instrumental roots in the lack of any way to specify that the words to a 
> song were written by someone other than the composer of the tune.  Now that 
> ABC supports lyrics, this is a situation that's increasingly common for 
> notated songs.
>
> Certainly, you can put both pieces of information in the composer field, 
> but that limits your flexibility in searching and displaying the data.
>
> Of course, all the uppercase letters are in use for field flags, so I don't 
> know what would be best -- maybe lowercase c: ?

"A:" for "author" and ditch the present useless standard label for that field.

===  ===


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

Re: [abcusers] Bagpipe tunes

[Jack Campin]

>Tunes for bagpipes, as tunes for dulcimers, have restricted scales compared
>to the 12 note scale I'm used to.  Is there a easy way (read, use a program
>to do it) to convert tunes created for 12 note scales for use with bagpipes,
>dulcimers, etc.?

Looks to me like you are confusing two different problems.

Some dulcimers are diatonic, i.e. they have a fixed 7-note scale.  So
are some bagpipes (not the union/uillean pipes or the more complicated
kinds of Northumbrian pipe).  Most Western European folk tunes fit
closely enough to a diatonic scale that if you pick the right starting
note you won't have much problem doing them on a diatonic instrument so
they sound basically okay (an exception: the Shetland lament "Da Slockit
Licht", where the high G occurs both sharp and natural, and you can't
cheat).

Bagpipes, except for uillean pipes, have an additional problem: they
have a very limited range.  For a Highland pipe there are just nine
notes (ten by an arcane trick nobody uses any more).  So unless a
tune was intended for it in the first place, chances are there will
be notes hanging off the ends; most tunes are fundamentally vocal and
most people's voices can do a wider range than that.  Pipe music
arrangers sometimes manage to get round this by shifting notes an
octave, a fifth or a third so that the tune stays recognizable; see
the example of "The Ewie wi the Crookit Horn" in the modes tutorial
on my website.  But for a lot of tunes they have the sense not to try.
There is a good reason why pipe bands don't play the British national
anthem, and Scottish national feeling ain't it.

Neither process, forgetting the chromatic notes or folding in the
outliers, is automatable.  Neither is the more basic step of deciding
whether you're on a hiding to nothing.

===  ===


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

Re: [abcusers] Making PDF (Was: ABC standards committee webpage)

[Jack Campin]

> if you have an HP Laserjet 6P, the printer driver can create
> pdf files directly. [...] I haven't looked to see, but you
> should be able to download the driver from Hewlitt Packard's site.

I just tried and it looks like there aren't any Mac or Unix drivers on
their site - Windows and OS/2 only.  Maybe Phil has a third-party one?


===  ===


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

[abcusers] Tune archive updated

[Jack Campin]

>> Some tunes are not [sic]
>> sopyright protected, so I've left them out. Also contributors have 
>> occasionaly asked me not to include certain tunes, 
> I would like to hear the reasons why people do not want to have tunes
> posted.

The point of copyrighting a tune is that you can can only reproduce
it with the copyright-holder's explicit permission.  What their reasons
might be for either allowing or disallowing its free reproduction are
up to them and can only be discovered by actually asking.

That is, there is no point in arguing.  People who don't want their
stuff in the public domain have every right to withhold it without
being dragged into a discussion of the wherefores.  Their rights don't
depend on their reasons.


> And I thought that having them in abc where I could share them would
> be a benefit.   
> And especially if the file has my name on it, unlike "copies" of CDs or  
> cassettes where  most people neglect to add the credits or composer. 

If the tune is fetched by JC's tunefinder in some other format there
is no guarantee it will have your name on it; ABC doesn't presently
*have* any standard way of recording credits (look at the tunes on Paul
Cranford's site for examples of the sort of information that conversion
throws away).  If there were any way to stop it ripping tunes out of
context or converting them on the fly you'd be right, but the likely
fate of any composition of yours you put on the web in ABC right now
is for it to get circulated from hand to hand as "something I found on
the Internet".

BTW, BarFly's macro mechanism has potential as a way of preventing
out-of-context tune extraction.  Define something essential to the
tune as a macro at the start of the file and the result will be
gibberish if anything less than the whole file is retrieved.  Any
chance we can make this part of the standard?

===  ===


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

[abcusers] small fragments?

[Jack Campin]

>The following didn't turn up any ABC at all. Anyone know about
>any of them, maybe a better URL to find the tunes?
>
>  http://famdeboer.www.cistron.nl/bagpipe.html

That one contains a ZIP file of bagpipe music auto-converted from
Bagpipe Music Writer format.  The notes are mostly there, but none
of the tunes is usable without heavy editing.  There is also some
serious copyright violation going on (mostly for tunes that weren't
worth ripping off in the first place), unless the transcriber has
gone to a lot more work getting clearance than he says.

===  ===


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

[abcusers] to post or not to post?

[Jack Campin]

> I was only interested in different people's reason for not wanting
> their music posted so that I could be more informed when the topic
> came up, like it did in the workshop this past weekend.

Here are some I can think of:

1. I'm dead and I'm not listening to that ouija board (this is the
   commonest one).

2. We're "they" and we're not telling you we are (this is the situation
   with Jimmy Shand's compositions - *he* never managed to trace who all
   the copyright holders were, so a complete edition of his work isn't
   going to happen for decades).

3. Publishing this tune is not unconditionally legit but it raises some
   interesting musical points, so I can post it here with limited
   distribution in this discussion context and reasonably expect a court
   to uphold that this is "fair use" (I've done this several times).

4. This is a work in progress or subject to revision so I want to stay
   in control of it and prevent half-baked copies propagating (Laura's
   position, and one that applies to some of my stuff).

5. This belongs in a particular context provided by the file it comes
   from and it would be doing the world a musical disservice to
   distribute it without that contextual information (the story with
   almost all of the material on my website).

6. The point of posting this tune on the web is as an advertising
   freebie to sell my CDs or get bookings for my artists (this is
   why Paul Cranford has ABCs on his site).

7. This tune is just plain wrong but it throws up some neat bugs in
   the ABC spec or in ABC software (again, I've done that).

===  ===


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

[abcusers] Pythagoras

[Jack Campin]

> There have been various interpretations on what the Pythagorian scale is
> Can anyone tell me where to find out what Pythagoras said in a reliable
> translation?

No text by Pythagoras survives.  His ideas on music were documented much
later by Archytas and Aristoxenus.

As the New Grove entry points out, there were many tuning systems in the
Middle Ages and later that were labelled as Pythagorean while being no
such thing.  Pythagoreanism fitted into so many other conceptual schemes
(e.g. astrology) that dropping the label was inadvisable.

The New Grove also points out that it is very unlikely that Pythagoras
really invented anything musically new - practicing Greek lyre players
didn't need a mathematician/philosopher to tell them how to tune up.

===  ===


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

[abcusers] how about 372 key/mode combos, then?

[Jack Campin]

Apropos of Pythagorean and related tunings, I saved this article from
rec.music.early a while ago.  Margo is r.m.e's resident exotic-early-
tunings wonk (she plays this way herself on a pitch-configurable
electronic keyboard).  I *dare* any of you to ask her to expand on this...

>From "M. Schulter" <[EMAIL PROTECTED]> Sun Feb 18 23:00:09 2001
>Status:
>Subject: Re: temperament term???
>From: "M. Schulter" <[EMAIL PROTECTED]>
>Date: 18 Feb 2001 23:00:09 GMT
>Organization: Value Net Internetwork Services
>Newsgroups: rec.music.early
>References:  <[EMAIL PROTECTED]>
>Path: 
>purr!news.demon.co.uk!demon!dispose.news.demon.net!demon!newsfeed.gamma.ru!Gamma.RU!news.maxwell.syr.edu!feed2.news.rcn.net!rcn!news2.best.com!vnetnews.value.net!not-for-mail
>Message-ID: <96pk5p$1bu$[EMAIL PROTECTED]>
>Lines: 130
>Article 9424
>
>
>Jonathan Addleman <[EMAIL PROTECTED]> wrote:
>
>: But it WAS done now and then, if only to accomodate the range of
>: various singers. Vicentino talks about this use of the archicembalo,
>: since you can play in meantone in any key. Frescobaldi at some point
>: mentioned that an organ tuned in equal temperament would be good for
>: this reason as well, though I don't know where that reference is..
>: (I got it 2nd or third hand...)
>
>Hello, there, and I must admit to being a bit confused by parts of this
>thread, which is one reason that I've preferred simply to read rather than
>to post up until now -- but maybe I can comment usefully on certain
>points, at least.
>
>First of all, I haven't really previously heard the terms "base" or
>"focus" in describing a tuning, although I might speak of range, for
>example "a 12-note meantone tuning of Eb-G#," or "a 19-note tuning, likely
>1/4-comma, of Gb-B#," or "a 17-note Pythagorean tuning of Gb-A#, evidently
>of the type described by Prosdocimus de Beldemandis and Ugolino of Orvieto
>in the earlier 15th century."
>
>In this thread, there seems to be a focus on two types of temperament: the
>regular meantone tunings of the late 15th to late 17th centuries, still in
>use in the 18th century, which might feature anything from 12 to 31 notes
>per octave; and the 12-note "well-temperaments" of the late 17th to 19th
>centuries, where the circle of fifths closes -- as it does, either
>precisely or "virtually" for musical purposes, also in a 19-note meantone
>tuning of around 1/3-comma, or in a 31-note meantone of around 1/4-comma.
>
>Indeed Vicentino promoted his _archicembalo_ and _arciorgano_ -- his
>superharpsichord and superorgan (the latter a kind of positive organ which
>could be disassembled, carried on a mule's back, and then reassembled at
>the next performance location -- as permitting free transposition. If we
>speak in "keys" in an Elizabethan sense as referring to the pitch level of
>a modal final, rather than to later major/minor concepts, then it is
>indeed correct that Vicentino's 31-note meantone tuning makes available
>all intervals on all 31 steps of the cycle.
>
>Basically Vicentino's tuning scheme of 1555 seems to combine two features
>which by the late 17th century were recognized to result in _very
>slightly_ different tunings. He describes a division of the whole-tone
>into five "minor dieses" of equal size, which would call for 31-tone equal
>temperament (31-tET), with major thirds very slightly larger than pure; he
>also suggests that major thirds are pure (1/4-comma meantone). In
>practice, the variations in a tuning by ear could be greater than the
>theoretical difference between these two models.
>
>Quite apart from accommodating singers, Vicentino's tuning makes available
>"enharmonic" steps inspired by those of Ancient Greek theory, about
>1/5-tone in size, which this composer and theorist espouses for their
>subtlety and "gentleness." Indeed, these fifthtone steps have a remarkable
>effect, and add an expressive dimension to some more typical 16th-century
>chromatic progressions also.
>
>More conventional theorists also address the matter of transpositions to
>accommodate singers, but within an apparent framework of 12-note meantone,
>where transpositions by fifths or fourths, or by a major second up or down
>(two fifths on the tuning chain), are most typical.
>
>In 1570, Guillaume Costeley describes a 19-note keyboard arranged in
>thirdtones dividing the octave into equal parts -- this, like Vicentino's
>31-note tuning in or around 1/4-comma, is a circular scheme, which would
>permit free transposition.
>
>In 1618, Fabio Colonna describes his 31-note meantone keyboard, with a
>tuning scheme similar to Vicentino's (likely 1/4-comma), but a keyboard
>arranged in five groups of seven notes, with each rank tuned 1/5-tone
>apart (resulting in some replications of notes). To demonstrate the closed
>nature of this system, he provides a composition giving an "Example of
>Circulation" which moves through a circle of cadences on all 31 steps of
>the instrument, each featuring motion of the bass by a fifth down or a
>fourth up.
>

Re: [abcusers] midi2abc (was: Wanted: ABC transcription...)

[Jack Campin]

>On Mon 11 Jun 2001 at 01:47PM +0200, Frank Nordberg wrote:
>> 
>> midi2abc seems actually to do a fair job interpreting midi files, it's
>> the ABC part of the program that seems to be the problem. [...]

>> B/c> instead of:
>> B/c/ d>cB|
 
>> The last one seems to be an midi2abc favourite, popping up all the time.

> My guess is that this is a stylistic change made by whoever created the
> MIDI files. Unless you have a very old version of midi2abc, you should
> be able to retrieve exactly the notes from a computer-generated MIDI
> file that were put in unless the notes get very short.

The problem with that last example is that the note lengths are
actually correct, it's just a screwy way to write it - presumably
midi2abc is simply working forwards through the tune instead of
trying to align notes with beats in the usual way.  No change to
the MIDI file would help.

===  ===


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

Re: [abcusers] midi2abc (was: Wanted: ABC transcription...)

[Jack Campin]

>>> The c>c construct is a problem because it is notated as a
>>> 3:1 ratio but played as a 2:1 ratio.  
>> Played by whom?  Does the standard document this?  
> Played by abc2midi and played by most players of hornpipes,
> I believe. If you try changing abc2midi so that it uses a 3:1 ratio,
> you should find that hornpipes don't sound quite right.
> Of course, this is all subjective and maybe you play things a bit
> differently in Boston :-) . As far as I know this is not documented
> in the standard at all, since it is more musical knowledge
> than anything to do with abc.

There was nothing to say that the example given was a hornpipe (nor
are all hornpipes played that way).

This would be a disastrous misinterpretation for almost all other
uses of the construct.  In a strathspey and in much Baroque music,
you interpret > as something nearer to >> ; but any tweaks like
that *have* to be under user control.



-----
Jack Campin  *   11 Third Street, Newtongrange, Midlothian EH22 4PU, Scotland
tel 0131 660 4760  *  fax 0870 055 4975  *  http://www.purr.demon.co.uk/jack/
food intolerance data & recipes, freeware Mac logic fonts, and Scottish music


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

Re: [abcusers] abc compliant software (was:midi2abc [was:Wanted: ABC transcription...])

[Jack Campin]

> My understanding of the a>b construct is
> that it is specially for hornpipes

Your understanding is wrong.

Hornpipes don't need any such notation.  They are often written in even
length notes with the context telling the user to swing them; in ABC,
the R: field conveys this information (in fact that's about the only
real use for that field).

How would you want us to interpret < , >> , and << ?  None of those
occur in hornpipes but they're variants of the same idea.


> and so you can use it for a 2:1 ratio if that is what you want elsewhere.
> If you want 3:1, then you can write a3/2b/2.

And what would this look like done your way?...

X:1
T:The Earl of Angus and Arran
C:William Marshall
R:strathspey
M:C
L:1/8
K:Eb
B,|EFE>G|AE  DD|EFE>G|AD  E2E>B,|
   EFE>G|AE  DD|EFE>G|AD ~E2E  ||
B |GAGd|eE  DA |GBGBE>g |f>ed>c ~B2BG  |
   AAGG|F>~GA>G FEDB,  |Ec|Bf  e2e  |]

I could play that straight from the source.  With the mess of fractions
you'd want, not only could I not play it, it would take me three or four
times as long to enter it right.

I wouldn't be using ABC at all if the garbage notation you're suggesting
was my only option.


> Remember that abc2midi is intended chiefly to produce playable MIDI
> files

No.  *Correct* playable MIDI files.


===  ===


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

Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted:ABC transcription...])

[Jack Campin]

> I too am disturbed by the historical revisionism shown in some quarters 
> to the contribution of abc2Win to the general adoption of abc. Yeah it 
> doesn't 100% adhere to the 1.6 specification and nothing but the 1.6 
> specification - but I can think of other abc programmes, on or 
> compilable on a variety of OS, you could justifiably level that 
> accusation at 
>
> But at the end of the day if your OS of choice supports the creation of 
> ASCII characters in a file you've got all the tools you need to generate 
> abc. Maybe that (or something like that) needs to be put in the mailing 
> list footer to keep reminding us all ...

There is a bit more to it than that.  For some reason, ABC2WIN
encourages its users to write worse ABC than they would if they
were using pencil and paper, let alone the latest-and-greatest
auto-everything ABC tool running on everything from MVS to BeOS.
(For example, Nigel Gatherer's ABC - done on text editor with
a RiscOS machine for which no ABC software exists - is far, far
better than the average ABC file with an ABC2WIN tagline on the
bottom).

Not having used ABC2WIN, I have no idea what features are responsible
for this, but whatever they are, they need to be analyzed and fixed.
The code itself may be capable of doing the right thing (and the print
quality I've seen from it is pretty good), but its social engineering
sucks.

===  ===


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

Re: [abcusers] Does anybody kow this ballad?

[Jack Campin]

> the title track of Pentangle's Cruel
> Sister is the same (rather grotesque) story as "Harpen", one of the best
> known Norwegian medieval ballads.
> Obviously, neither Pentangle's version nor the "official" Norwegian are
> originals - Pentangle's is clearly late 16th Century, while the ones you
> find in Norwegian collections are even more recent. Also, the ballad
> seems to have some stylistic traits that suggest it's neither British
> nor Norwegian originally.
> Does anybody have any information about the ballad?

Usually known in Scotland as "The Twa Sisters o Binnorie" - it's in
every ballad collection you could shake a stick at.

It's also the story of Mahler's cantata "Das Klagende Lied"; I think
he got it from German folklore.  I would guess it originated among the
Germanic peoples some time in the pre-Christian Dark Ages at the very
latest.

===  ===


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

Re: [abcusers] linux only ?

[Jack Campin]

>(I have been tempted to translate abc[m]2ps to  perl,  just  for  the
>yuks,  and  for  extra  portability.   Then  it  wouldn't  have to be
>compiled.  But I  bet  I'd  get  flamed  because  perl  doesn't  come
>pre-installed on all possible computer systems.  ;-)

Wouldn't the most portable language for it be PostScript itself?

===  ===


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

Re: [abcusers] little V: comment

[Jack Campin]

> What worries me about the use of an inline field for V: is that it is an
> invitation to people to put [V:2] in the middle of a line.  After all,
> that's what inline fields are for.  In this case, however, it makes no
> sense at all to change voices in mid-line.

It does, however, make sense to change *staff* in mid-line - piano
scores do that all the time, where a melody line moves between treble
and bass.  Unfortunately ABC doesn't make voices and staves completely
orthogonal.

While it would be pretty difficult to implement, a "great staff merge
mode" for ABC-to-staff-notation converters like BarFly's doesn't seem
architecturally impossible - represent all of a collection of voices
on the same two treble and bass staves, with the decision of which
stave to put a note on being determined solely by its pitch, not by
which voice it belongs to.

Merging voices is a very handy feature of BarFly for getting a usable
score - most pianists don't like reading four-voice open score.  It'd
be good for abc2ps and clones to implement it.

===  ===


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

[abcusers] barlines at the beginning of a staff

[Jack Campin]

> At the other end of the staff, I've received  several  messages  from
> people  complaining about some of my files that put a bar line at the
> start of the staff.  They insist that this is illegal.  It isn't,  of
> course,  and  is  in  fact  common  practice  in some musical circles
> (mostly those who also write partial measures at the end of a staff).

The problem is not just that the barlines are at the start of a line.
That would just be a stylistic preference, albeit an irritating one.

What you do very often in your files is write two consecutive barlines
with no music in between them; one at the end of a line and one at the
beginning of the next line.

I don't care whether it is legal, it's a timewasting pain in the arse
that makes BarFly's (and probably Bryan Creer's) error checking utilities
gag - if you say your tune is in 4/4, 0/4 is not a legitimate bar length.
I have to edit this out before re-running the error checker to look for
more significant problems.  Support for error checkers is not mandated
by the ABC standard, but making it impossible to use them is not going
to do anything to help get ABC accepted or to improve the quality of the
ABC corpus.

Putting a barline at every point where *you* want the start of a line
to be also makes it gratuitously difficult for your users to choose a
different layout, either because they want a different note density
than you or because they want to switch between portrait and landscape.
There are *some* pieces where a specific layout is hard to avoid, but
for the ordinary one-voice tunes that make up the bulk of the ABC on
the web (and the bulk of what's on your site) there's no earthly need
to hardwire this in.  (I need to print some tunes for children in the
next few months; the notation will have to be much less dense than the
norm for ABC printing applications).

I have sometimes seen ABC2WIN files where a linefeed occurs between the
two strokes of a double bar.  How is a buggy-ABC-fixer supposed to tell
that isn't what you did?

===  ===


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

[abcusers] !

[Jack Campin]

Phil Taylor:
> Do you think that Jim Vint should withdraw the exclamation mark
> used to mark end of line in abc2win?
>> Or that if a proposal such as, for example, the !symbol! notation was
>> adopted into the standard you would be happy to incorperate it into
>> BarFly?
> The existing version of BarFly can already deal with it.  I don't
> advertise the fact because I think it's a bad idea.

Whereas Jim's use of the ! symbol is a *good* idea that would fix the
problem BarFly has with linebreaks if you adopted it.  I think you made
exactly the wrong choice here.


-----
Jack Campin  *   11 Third Street, Newtongrange, Midlothian EH22 4PU, Scotland
tel 0131 660 4760  *  fax 0870 055 4975  *  http://www.purr.demon.co.uk/jack/
food intolerance data & recipes, freeware Mac logic fonts, and Scottish music


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

[abcusers] GIF

[Jack Campin]

> most of the tune finder's users seem to want it to return staff
> notation (usually in GIF - yuck!)

A lot of people can't print PostScript, JPEG looks foul for music,
and PDF is a bloated waste of space, so what else is there?

Presumably GIF music would look better if it were generated directly
by the typesetting application rather than filtered through a converter
with the resultant aliasing/quantization losses?  Anybody do that?

===  ===


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

[abcusers] Zel v ABC

[Jack Campin]

> Zel, in fact, it's described as a language to create midi files from
> a text file, eventually to load them in a sequencer for further editing.

I've been using ABC for years and have never wanted such a capability.
So why should I bother?

Is the developer of this thing ever going to make it capable of

- acting as a tune reference database, the way I can use ABC with BarFly?
  (i.e. create multi-tune files with headers listing alternative titles,
  composers, sources, etc, but no tune bodies except maybe the first
  couple of bars for indexing purposes)?

- assembling multiple tunes into sets, finding some of those I want
  on the Internet and using the computer to transpose them as needed
  and print them as conventional staff notation?

Your description makes the thing sound like a one-trick pony (and as
it only runs on Windows there's no point in me looking into it any
further).  The point of ABC is that there are many different things
you can do with it, you can make them integrate in useful ways, and
you aren't tied to any specific tool to achieve this.  Does the author
of Zel even *want* other people writing software to use his notation?

Let's try an example.  What does this tune look like in Zel?  It's a
flute arrangement of a song; despite being instrument-specific music,
it's entirely standard ABC 1.6.

X:339
T:Lord Gregory
S:Gow, Vocal Melodies arr. Henderson part 1 p13
Z:Jack Campin 1998-2001
M:3/4
L:1/8
K:Amin
"Slow"
   A2  |   e4(AB)   |  (A2 ^G2)  .E2 |A4B2  
|{B}c4
(3(ceg)|{f}e4(dc)   |  (c2  B2)   c>A| {c}B4
  (Be) |   e4(A/c/B/A/) |  (A2{BA})^G2   .E2 |A4   (Bc/d/)  
|{d}c4
(3(ceg)|{f}e4 {e}(dc)   |   c4 {c}B>A|A4   :|
   A2  |   e4(ef/g/)|{g}f4   (fe)| {e}d4d{ed^cd}e/f/|  
(f2e2)
   e>d |  (dc) c2(c3/d//e//)|  (e2  d2)  .c2 |   (c2B2)
  (Ee) |   e4(A/c/B/A/) |  (A2{BA})^G2E2 |{^G}A2 (3(ABc) (3(Bcd)
|{d}c4
(3(ceg)|  (fe) e2 {e}(dc)   |   c>d  {c}B3 A |A4   :|

The one real inadequacy ABC has with that is that I can't write
   Q:Slow
which is something no staff-notation generator ought to have any
problem with, and player programs can just ignore, so why on earth
hasn't anybody implemented it?  (And I would bet money that Zel
doesn't allow me to specify tempo that way either).

Note, I expect your solution to encode the number in the "X:" line (in my
setup it conveys useful information; tune 39 in section 3), the source, and
who the transcribers were (you and me).  You should end up with something
that a flute player could use to learn the tune from and get the same result
as from the ABC above.  The slurs are essential, so if MIDI is all the
flautist is going to get, they must be audible.  And I would also expect
you to be able to notate it showing the parallels in phrasing and the line
structure of the original song, as my line breaks and column alignments do
(not quite straightforward as it alternates 4- and 3-bar lines; really long
lines would be better).  Don't specify a specific tempo without indicating
in the source that it's an editorial interpretation of "Slow".  And you
should also end up with a piece of notation readable enough to play from
directly without computer intervention; I just got my flute out and did
exactly that with mine.

Over to you.

(Phil: re the "!" thread, what I would like to do here is put ! at the end
of lines 2 and 6 to force a linebreak without adding a barline. Or else
put ! at the ends of lines 2, 4, 6 and 8, which I think would make this
completely compatible with abc2win).

===  ===


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

Re: [abcusers] Folk band

[Jack Campin]

> I've accidentally written some band arrangements to a couple of
> English, Irish and Scottish tunes. And since I'm not exactly an expert
> on this subject, I wondered if someone who knows better than me could
> have a look at:
> http://www.musicaviva.com/folkband/
> and tell me what they thought.

Godalmighty, HOW BIG IS IT???

I started downloading the archive on a slow connection (probably slow
at both ends, I got a "broken pipe" error at one point) and gave up
after 2.6Mb.

BTW, "The Mason's Apron" and "The Bridal" are both Scottish (from the
early 18th and late 17th centuries) and I am fairly sure "Harvest
Home" is English.  "Brochan Lom", not "Brocham Lom" (the Scots title
is "Orange and Blue").  "The Red-Haired Boy" is an Irish name for
the Scots tune "Gilderoy", which in turn is probably a variant of an
older English tune (known English versions of it are more recent than
the Scots one, but there are zillions of them).

===  ===


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

Re: [abcusers] Three-handed job.

[Jack Campin]

> The Apple writer did admit that there was still a roughly 2-second
> delay in switching between keyboard and mouse.  If the users of
> this sort of UI would just make the necessary hardware upgrades
> to take advantage of the design, this delay could be eliminated
> entirely, and users could make full use of its capabilities with
> no clumsy switching  delays.  But for some reason, users insist
> on sticking with their legacy 2-handed hardware.
> Sometimes users can be so bullheaded ...

People used to talk about the "man-machine interface".  Not a phrase
used much now for obvious reasons, but it always seemed to me that
it ought to mean never needing to use your thumb on the space bar.
Or perhaps, with a bit more training, a pointing device.  A vertical
trackpad on the edge of the desk ought to do it.

===  ===


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

[abcusers] Tune Finder oddities

[Jack Campin]

Two peculiarities of John Chambers' Tune Finder:

> If an index is zero, the entire file is returned; if nonzero, only that
> tune is returned.

Does this mean that if I convert my tune files to have only zero indices
for all the tunes, I can ensure that they are only downloaded or converted
in their entirety?

What would other software make of this?  (BarFly doesn't care).


>  GGet  returns entire file.
>  AABC  returns selected ABC tune as "text/vnd.abc".
>  TTXT  returns selected ABC tune as "text/plain".

So you only get to control file type if you download tunes individually?

===  ===


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

[abcusers] on being ripped off

[Jack Campin]

I have a transcription of Clarkson's American tunes of 1805 on my website.
It contains this note, at the start where no reader could miss it:

> % Please don't redistribute this without including the complete file
> % here (e.g. it's ok to make a version without the bass for your own
> % use but add this as well if you pass it on).  If the ABC standard
> % changes to make the multi-voice stuff work differently, I'll upload
> % a new version of this.

Now I discover via JC's tune finder a file of uniformly good-quality
transcriptions called longlist.txt with all those tunes in it, like this:

> X:334
> T:The Whim
> S:John Clarkson Jr., American Tunes no 1, arr. for the Piano Forte c. 1805
> N:Edinburgh Printed and Sold by J. Clarkson
> N:to be had at his House No. 63 South Bridge
> B:NLS MH.e.41
> Z:Jack Campin , Sep 2000
> Z: posted by Andrew Kuntz 2/01
[body omitted here]

All of them had been edited to cut the bass out, exactly as I asked
people NOT to do (the full versions were NOT included).  Andrew never
contacted me about this before doing it.  And there is a significant
change in one line of the header.  My original had:

> Z:Jack Campin , Sep 2000

That is, Andrew deliberately cut the URL of the original source to make
it difficult for his readers to find it (or the related file of early
American fife music, which would surely be of interest to almost anybody
getting the Clarkson stuff).

There was bugger-all point in this editing, as these tunes are meant for
the piano anyway - they have right-hand chords and are in keys unsuitable
for the flute or fiddle, both of which features Andrew left in.

I am not best pleased.

What the hell do you think you're doing, Andrew?  What list was this
posted to and where is the archive?  The file contained no indication
of where it was stored or who maintains it.

What I want you to do: post an apology to that list and replace each
of my tunes in that file with an entry like this: 

> X:334
> T:The Whim
> S:John Clarkson Jr., American Tunes no 1, arr. for the Piano Forte c. 1805
> N:Obtain the complete file of these tunes from Jack
> N:Campin's site, <http://www.purr.demon.co.uk/jack/>

(with no tune body).

The same file has a great stack of compositions by Ed Reavy (posted by
someone else), far more ABC tunes than I've seen in one place by any
one in-copyright composer; were any of them done with the copyright-
holder's permission?

I have cc'ed this to Andrew, as I don't know if he reads the ABC list
or not.  (Also cc'ed to Nigel Gathere, who seems to have contributed
to this file, wittingly or not, and so presumably knows what the list
is).  I don't wish to get into a discussion on the other list, whatever
it might be.


-
Jack Campin  *   11 Third Street, Newtongrange, Midlothian EH22 4PU, Scotland
tel 0131 660 4760  *  fax 0870 055 4975  *  http://www.purr.demon.co.uk/jack/
food intolerance data & recipes, freeware Mac logic fonts, and Scottish music


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

[abcusers] ABC in an internet cafe

[Jack Campin]

A couple of my musician friends don't have computers of their own,
they use Hotmail or Yahoo accounts at work or at internet cafes.
Installing an ABC application at either isn't on.  Hotmail doesn't
even know how to display an attached GIF.

How can somebody on one of these systems use an emailed ABC file if
they aren't familiar enough with the notation to read the source?

===  ===


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

Re: [abcusers] ABC in an internet cafe

[Jack Campin]

>> I'm getting quite tempted by the idea of putting all the ABC on my
>> site into archive files so as to counter search engine abuse.
> If you have access to the root level directory on your site you can put
> up a Robots.txt file to tell webspiders not to index part or all of your
> site.  If you don't have such access there's also a Robots META tag you
> can include in each page that you don't want indexed.

I'm quite happy with indexing, it's random extraction of content I want
to discourage.  The WWW culture has been over this issue already, with
general consensus (backed up in the Shetland Times vs Shetland News case
by legal precedent); site links are always ok, pulling out bits of other
people's pages and plonking them into unattributed frames isn't.


[Tune Finder]
: One of the formats returned is MIDI. This is done by feeding the
: selected tune to abc2midi, which is the only program that I know
: of that can run on unix as a subprocess to a CGI script, read ABC,
: and produce MIDI. One of its properties is that it only translates
: the first tune in its input.

The Mac port didn't behave that way last time I tried it...


: So if you want to hear the 17th tune in the file, you must precede
: abc2midi with a filter that cuts out everything before the X:17 line.

I don't find this a problem, as I'm providing ABC for people who are
or are prepared to become ABC users (that's why I take care to make
it readable as source).  If your engine refused to convert any of my
stuff into other formats that'd be fine by me.


One piece of file-context-dependence that I am likely to introduce on my
site fairly soon is BarFly macros.  For some stuff I want to transcribe,
these make for a big improvement to source readability and accuracy of
transcription.  I believe some of the Windows implementors may be thinking
about supporting them (Henrik?  Laurie?)  but there seems to be no
interest as yet from the Unix camp.  I'd rather get the ABC right first
and wait for the programmers to catch up.  In this instance, the macros
need not even be in the same file as the tunes, though I don't intend to
exploit that possibility for a while yet.

===  ===


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

Re: [abcusers] ABC in an internet cafe

[Jack Campin]

>| What should happen in the second case is that when that tune appears
>| in a list of hits, the buttons which retrieve GIF, ps or midi would
>| be disabled, and the abc button would retrieve the whole file.
>| (I've no idea how easy that would be to implement - presumably the
>| index would need an extra field to hold the information.)
> This can be done when working with a real GUI toolkit, but to do this
> with HTML pages and CGI scripts means redirecting the user to a new
> page with the given UI properties.  The other solution is to write an
> applet in Java or Python (use the Java implementation called Jython)
> that will use AWT/Swing and basically be a "real" application, though
> it runs on the clients system so it would need a way to remotely
> access the index and the actual data.

Why does it need any special software?  The Tune Finder generates HTML
index pages with links that invoke CGI scripts to do the conversion.
If the links aren't put on the index pages, the user can't do those
invocations (or not without so much work it would be easier to just
get the tunes and and an ABC app and do it yourself).

A line of TuneFinder index contains a list of linked single-letter
buttons, like this one to generate MIDI:

http://rigel.csuchico.edu/~pubscout/tunes/perrie.html&X=1&T=PERRIEWERRIE&N=PerrieWerrie.midi";>M

All the index-generating script needs to do, for tunes which are not to
be converted, is to replace that button with " ".  SQL (I presume
that's what the database uses?) provides the means to identify which
tunes require which treatment and process them accordingly.  No need for
any of that do be done on the client machine.



===  ===


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

[abcusers] macros

[Jack Campin]

> If I understand BarFly macros correctly, they're simply bits of text that
> get replaced by other bits of text. If we're suitably desperate, writing
> a simple preprocessor to do that shouldn't take more than a Perl
> interpreter and a rainy afternoon, and it will basically macro-enable
> all Unix-based abc tools at the cost of a minor inconvenience.

They're a bit more complicated than that - they're parametrized, so you
can give one a note and have it expand into an ornament based on that
note or into a chord with that note as the root.  Here's an example; the
chords could hardly be simpler (play the lower octave along with the
named note), but even here there's less to type and read than writing
them out explicitly.  Simple bass parts ought to be simple to notate.

X:1
T:Lady Robert Kerr's Strathspey
C:Niel Gow Jnr
S:Collection of compositions by Niel Gow Jnr pub posthumously by Nathaniel Gow, 1837
N:for the pianoforte, harp, violin and violoncello
B:NLS Glen.411
M:C|
L:1/8
m: On =[nn,]
m: On/ = [n/n,/]
V:1
V:2 bass
K:G Minor
V:1
"Slowly"
B/c/|dB  G>d (c/B/).A/.G/|A>fF>f c>F   (A/B/c/).A/|\
 dB G>d (c/B/).A/.G/|cd/e/ (d/c/).B/.A/ G2 "#"~GB/c/ |
V:2 [L:1/4]
z/  |OG, OG, OG,  OG,|OF,OF, OF,OF,   |\
 OG, OG, OG,  OG,|OC,OD, OG,OG,   |
V:1 [L:1/8]
 dB  G>d (c/B/).A/.G/|A>fF>f c>FA/B/c/A/  |\
 dB G>d (c/B/).A/.G/|cd/e/ (d/c/).B/.A/ G2 G||
V:2 [L:1/4]
 OG, OG, OG,  OG,|OF,OF, OF,OF,   |\
 OG, OG, OG,  OG,|OC,OD, OG,OG,/ ||
V:1 [L:1/8]
d|"#"~ga/b/ (b/a/).g/.^f/ gddg  |f>cdfc/B/A/G/ F>d  |\
  "#"~ga/b/ (b/a/).g/.^f/ gddg  |f>c d/c/B/A/ dGGd  |
V:2 [L:1/4]
z/|   OG,D,   OG,OG,|OA, OB,  OF,  OF,  |\
  OG,D,   OG,OG,|OC, OD,  OG,  OG,  |
V:1 [L:1/8]
  "#"~ga/b/ (b/a/).g/.^f/ gddg  |f>cdfc/B/A/G/ F>A  |\
  G>BA/B/c/A/ B>dc>e|d>B d/c/B/A/ dGG  |]
V:2 [L:1/4]
  OG,D,   OG,OG,|OA, OB,  OF,  OF,  |\
  OG,D,   OG,OC,|OD, OD,  OG,  OG,/|]

which expands into:

X:2
T:Lady Robert Kerr's Strathspey
C:Niel Gow Jnr
S:Collection of compositions by Niel Gow Jnr pub posthumously by Nathaniel Gow, 1837
N:for the pianoforte, harp, violin and violoncello
B:NLS Glen.411
M:C|
L:1/8
m: On =[nn,]
m: On/ = [n/n,/]
V:1
V:2 bass
K:G Minor
V:1
"Slowly"
B/c/|dB  G>d (c/B/).A/.G/|A>fF>f c>F   (A/B/c/).A/|\
 dB G>d (c/B/).A/.G/|cd/e/ (d/c/).B/.A/ G2 "#"~GB/c/ |
V:2 [L:1/4]
z/  |[G,G,,] [G,G,,] [G,G,,]  [G,G,,]|[F,F,,][F,F,,] [F,F,,]
[F,F,,]   |\
 [G,G,,] [G,G,,] [G,G,,]  [G,G,,]|[C,C,,][D,D,,] [G,G,,]
[G,G,,]   |
V:1 [L:1/8]
 dB  G>d (c/B/).A/.G/|A>fF>f c>FA/B/c/A/  |\
 dB G>d (c/B/).A/.G/|cd/e/ (d/c/).B/.A/ G2 G||
V:2 [L:1/4]
 [G,G,,] [G,G,,] [G,G,,]  [G,G,,]|[F,F,,][F,F,,] [F,F,,]
[F,F,,]   |\
 [G,G,,] [G,G,,] [G,G,,]  [G,G,,]|[C,C,,][D,D,,] [G,G,,]
[G,/G,,/] ||
V:1 [L:1/8]
d|"#"~ga/b/ (b/a/).g/.^f/ gddg  |f>cdfc/B/A/G/ F>d  |\
  "#"~ga/b/ (b/a/).g/.^f/ gddg  |f>c d/c/B/A/ dGGd  |
V:2 [L:1/4]
z/|   [G,G,,]D,   [G,G,,][G,G,,]|[A,A,,] [B,B,,]  [F,F,,]  [F,F,,] 
 |\
  [G,G,,]D,   [G,G,,][G,G,,]|[C,C,,] [D,D,,]  [G,G,,]  [G,G,,] 
 |
V:1 [L:1/8]
  "#"~ga/b/ (b/a/).g/.^f/ gddg  |f>cdfc/B/A/G/ F>A  |\
  G>BA/B/c/A/ B>dc>e|d>B d/c/B/A/ dGG  |]
V:2 [L:1/4]
  [G,G,,]D,   [G,G,,][G,G,,]|[A,A,,] [B,B,,]  [F,F,,]  [F,F,,] 
 |\
  [G,G,,]D,   [G,G,,][C,C,,]|[D,D,,] [D,D,,]  [G,G,,]  
[G,/G,,/]|]

You can imagine the kind of difference that makes with denser textures.

I'd like to see some more discussion and experiment with these.  If
you're used to something like TeX macros, BarFly's model seems too
limited (e.g. you usually have to write the same code out multiple
times, once for each note length you intend to apply it to).  On the
other hand I wouldn't like to see ABC tunes looking like TeX source.
And I still haven't figured out a naming scheme for chord macros
that combines the concision required for clear layout with mnemonic
helpfulness.

===  ===


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

Re: [abcusers] abcmac - BarFly-style abc macro preprocessor inPerl

[Jack Campin]

>> I'm confused now. Suppose I had definitions for `Mn' and `Mn2'. What
>> would happen (a) for `Mc' (b) for `Mc2' (c) for `Mc4' in the body of
>> a tune? The interesting point is whether the `n' includes a length or
>> not.
> (a) and (b) will expand, (c) will not, since there is no macro definition
> for that length. 'n' does not itself include the length, but the length
> (if any) is part of the target string.

I wonder if we need two different kinds of macro?  I can see the point
of having the length-dependent ones, for the original purpose you had
in mind (ornamentation) but the macros I've written have been about
50:50 ornaments and chords, and for chords the length-dependence is just
a nuisance.

The problem is that since the point of macros is to abbreviate, you want
them to have very short names, which means you have very few options if
you want those names to be at all mnemonic.  You can't multiply them at
will.

Maybe it would be better to allow macros to select different behaviour
for different lengths by a pattern-matching or conditional construct?
That way you could reuse the same name for conceptually identical
constructs ("trill" or "mordent" on different lengths of note).


> I wasn't able to test the script, unfortunately.  MacPerl has got itself
> into a fankle [...]  Us Mac users don't have a lot of fun with perl.
> Every time I try to use it I end up concluding that it would be quicker
> to write a program in C or Pascal to do the job.

I think I've got three versions of MacPerl sitting around on my machines
and none of them ever worked.  Python anybody?  That does work on the Mac.
(I'd prefer Prolog or ML, both of which I can actually read, but I can't
see there being too many takers for either). 

===  ===


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

Re: [abcusers] Mirror of Joyce's book "Old Irish folk music andsongs"

[Jack Campin]

> I also checked with amazon.com and bn.com (Barnes & Noble); both told
> me  that  the  book is out of print.  This might just mean that their
> databases don't know where to get it.  The 1965  publication  was  by
> Cooper  Square  Publishers  in  New  York,  and  they have a web site
> (www.coopersquarepress.com) with a search facility.  It doesn't  find
> any  matches  for  the  title or author.  Any idea whether it's still
> being published, and if so, by whom?

Llanerch maybe?  They've done very similar stuff, like the Petrie
collection.

===  ===


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

[abcusers] net-friendly information

[Jack Campin]

I have been looking round other people's transcriptions on the net
over the last few days and I'm getting reminded of a few missing
features of ABC that would make web-trawls for music more productive.

- universal identifiers, along the lines of the Message-IDs used with
  email and Usenet postings.  These tell you whether you've found another
  copy of something you've already got, and (if they have some internal
  structure, as Message-IDs usually do) can help direct you to the human
  who did the transcription or made it available.

- checksums.  These tell you whether you've got the tune or complete
  file the way the transcriber or uploader originally had it.

- URLs.  Not as useful as universal identifiers, because they're
  relatively transient, but they would usually help in tracing
  associated material for a few years after being disseminated.

- keywords.  Currently there is no way to search for music by intended
  instrument, genre, period, the performer it was associated with, range,
  or intended function ("wedding march", "mobile ringtone").  Keywords
  can support that.

This is the same sort of thing that HTML does with META tags.  I suggest
that we now allocate a field to these web-related functions, and like
the META tag, specialize that field into subsidiary types later.  These
fields could occur either on their own in a file or within a tune header.
A single file or tune could contain several of them.  They would be one-
line fields, each containing only information of a single subsidiary type.

I suggest the subsidiary type information is represented in a similar way
to META tags:

 < typetag = data >

where "typetag" is a case-independent string composed of alphameric
charcters or "_" and the spaces around the = sign and next to the <
and > signs are insignificant.  The "data" field may have its own
syntax dependent on the typetag.

Examples:

   E:http://www.purr.demon.co.uk/jack/McLennan.abc>

or

   E:

or

   E:

where Sir Andrew would presumably have registered the part to the right of
the @ sign somewhere to guarantee global uniqueness of the ID, with the
part to the left being solely his responsibility (as with Message-IDs -
this generally means using locally-generated sequence numbers somehow).
 
As the E: field is not used by any currently supported software I propose
we reallocate that.  "G" would be another possibility, handily standing
for "global", but I believe that does still get *some* use, albeit in
rather trivial ways.  I've never seen either in a tune I've got off the
net.

===  ===


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

Re: [abcusers] Susato's Danseryes

[Jack Campin]

> I would find it much better to write the music voice after voice.  It
> is not really possible to read the four voices in parallel in the abc
> text anyway

Not unless the source is laid out helpfully, but for this sort of
music it can be quite easily.  I haven't changed a note in Frank's
transcription, or made any changes to the generated staff notation,
to do this.  It does need a wider-than-80-column screen but nothing
very exotic.  You can see exactly which chord is being played at
every point.  I have yet to see a four-part hymn setting for which
this layout methodology won't work.

X:5
T:La mourisque
T:(Basse dansse 5)
C:Tielman Susato
S:Tileman Susato: Danserye (1551)
Z:Transcribed by Frank Nordberg - http://www.musicaviva.com
%This is a temporary version - please don't redistribute yet
N:adapted by Jack Campin to regularize the layout for vertical reading, use more
N:reasonable clefs, and to employ instruments that sound better on a small Mac
V:1 Program 1 68 alto % oboe
V:2 Program 1 68 alto % oboe
V:3 Program 1 70 bass % bassoon
V:4 Program 1 57 bass % trombone
R:Basse dance
M:4/2
L:1/2
Q:1/2=210
K:C
V:1 E/ F/  G G G |G3  F |E  C  C  D |B,2  G,2 |E/ F/  G  G G |G3  F |E  C  C D  
|G,2 G,2:|
V:2 C/ A,/ C C C |C3  A,|C  A, A, A,|G,2  B,2 |C/ A,/ C  C C |C3  A,|C  A, A,B, 
|C2  C2 :|
V:3 G,/F,/ E,E,E,|E,3 F,|C, E, E, F,|D,2  D,G,|G,/F,/ E, E,E,|E,3 F,|C,>D, E,/C,/G, 
|E,2 E,2:|
V:4 C,/D,/ C,C,C,|C,3 D,|A,,A,,A,,D,|G,,2 G,,2|C,/D,/ C, C,C,|C,3 D,|A,,A,,A,,   
G,,|C,2 C,2:|
%
V:1 z E  E C  |C  D  E C  |F D  E C |C  D  B,2 |G, E  E C  |C  D  E C  |F D  E C |C  D 
 G,2:|
V:2 z E, G,A, |A, E, G,C, |A,B, C C,|E, D, D,2 |D, E, E,A, |A, D, G,C, |A,B, C G,|A, 
G, E,2:|
V:3 z G, E,E, |F, F, E,A, |F,G, E,E,|A, F, G,2 |G, G, E,E, |F, F, E,A, |F,G, E,E,|E, 
D, C,2:|
V:4 z C, C,A,,|A,,B,,C,A,,|D,G,,C,C,|A,,D, G,,2|G,,C, 
C,A,,|A,,B,,C,A,,|D,G,,C,C,|A,,B,,C,2:|
%
W:
W:  From Musica Viva - http://www.musicaviva.com
W:  the Internet center for free sheet music downloads.

This second example goes further, lining up corresponding beats both within
and between sections so you can compare chord progressions between them:

X:38
T:Mille regretz
C:Tielman Susato
S:Susato1551
Z:Transcribed by Frank Nordberg - http://www.musicaviva.com
%This is a temporary version - please don't redistribute yet
N:adapted by Jack Campin to regularize the layout for vertical reading
N:and to employ instruments that sound better on a small Mac
V:1 Program 1 74  % recorder
V:2 Program 1 46  % harp pretending to be a lute
V:3 Program 1 46 alto % harp pretending to be a lute
V:4 Program 1 33 bass % electric bass guitar pretending to be a theorbo
R:Pavane
M:C|
L:1/4
K:Am
V:1 E4   |A2A2  |G3F/E/|D  C  D2  |C c  c  c |B2A> B  |c>B  A2  |^G2  
z2:|
V:2 B,4  |A,2   D2  |B,3   A,  |B, C  A,2 |C>D  E  F |G2F2|E E> C D | E2  
z2:|
V:3 E4   |C2F2  |E3D/C/|B, E  FD  |E3  C |D  E  C2|A,B, C A,| B,2 
z2:|
V:4 E,4  |F,2   D,2 |E,3   F,  |G, A, D,2 |A,2  A, A,|G, E, F,>G, |A,G, F,2 | E,2 
z2:|
%
V:1 c2  B  A |G A   A A |G E  F2   |E2zB  |c2   A2   |B2e2|d c  B A |^G2  
z2.|
V:2 G2  G  E |E E   F D |E E  D2   |G,2   G,2 |A,C> B, A,|G, G, C> B, |A,G, G E | E2  
z2:|
V:3 E2  D  C |B,C   C A,|B,C2  B,  |C2B,2 |E2   E2   |E3   E  |F E  D C | B,2 
z2:|
V:4 C,2 G, A,|E,A,, F,F,|E,C, D,2  |C,2   E,2 |A,,2 A,,2 |E,2   C,2   |D,E, G,A,| E,2 
z2:|
%
V:1 E2  G  G |D  d  d d |c2   B2   |A  A  A A |G2   F2   |E  E  G  E  |G2   E>F | G2  
z2:|
V:2 G,2 G, G,|D> E  F G |E2   E2   |E  F  F F |E2   D2   |C  C  B, C  |B,2  C2  | B,2 
z2:|
V:3 C2  B, G,|B,>C  D B,|C A,2 G,  |A, C  C C |C2   A,>B,|C  A, G, A, |G,2  A,2 | G,2 
z2:|
V:4 C,2 E,>F,|G, G, D,G,|A,2  E,2  |A,,F, F,F,|C,2  D,2  |A,,A,,E, A,,|E,2  A,,2| E,2 
z2:|
%
W:
W:  From Musica Viva - http://www.musicaviva.com
W:  the Internet center for free sheet music downloads.


> and it is complicate to extract parts for playing.

This is a pretty trivial editing task, BarFly has most of this
functionality built in already, and it can't take more than a few
lines of some scripting/patternmatching language to achieve it.

Where do you get MIDI programs 2, 3 and 4 from?  Are they part of
Quicktime 5 or something?


-----
Jack Campin  *   11 Third Street, Newtongrange, Midlothian EH22 4PU, Scotland
tel 0131 660 4760  *  fax 0870 055 4975  *  http://www.purr.demon.co.uk/jack/
food intolerance data & recipes, freeware Mac logic fonts, and Scottish music


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

Re: [abcusers] Susato's Danseryes

[Jack Campin]

[voice alignment in ABC source]
> how are you doing with beamed music ? Most the traditional music
> I am dealing with is made up from 1/8 and 1/16 notes. The beams
> contain a lot of the rhythmical information.

It is an absolute bugger that there isn't a portable something-other-
than-code-32 space in the ASCII character set that ABC could use (so
as to have a visual space in the source that wouldn't produce a beam
break).  Standard Mac fonts have one (which works in BarFly if you
don't try to combine it with too many other beaming-related features)
but there's no way any non-Mac system could use it.

So what I do is align the initial notes of beamed groups: lots of
examples on my website.  This is better than making no attempt at
readability, though it doesn't go as far as I'd like.  (Highland pipe
music can be difficult, with beamed melody note groups containing
multiple separately beamed groups of gracenotes).  Sometimes I'll
introduce a beam break that isn't in the score I'm working from if
I judge that source readability matters more than reproducing the
original exactly - often there are alternate conventions for length
of beams anyway.

===  ===


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

Re: [abcusers] Susato & work planning

[Jack Campin]

> So it may be a good thing if we could find a webspace (a message
> board) where we could write "publicly" who is transcribing what
> (like for the O'neill tunes).

What I'm doing: all the GS McLennan tunes that I think it's legal to
put on the web, in full gracenoted detail and with a complete tunography
of everything I haven't done (this is finished bar a few bits of minor
tweaking) and the music from Maier's _Atalanta Fugiens_ (about a quarter
of the way through, but it's a relatively quick job, at least until I
start making it an all-out multimedia document using very trick known
to BarFly).

===  ===


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

Re: [abcusers] Susato's Danseryes

[Jack Campin]

> 3. Separated or intermingled voice lines.
> This is a rather messy problem we ought to discuss at length here at
> abcusers. It's not an issue specially related to Susato, though.

Well it is, sort of.  The point of my reformatting of your source
was that for music in Susato's idiom - metrical dance pieces with
the voices running closely in parallel and where each structural unit
fits happily into one line of source - intermingled lines are better.
For imitative contrapuntal pieces of the same era they might not be.
We need both, and we need our software to interconvert between the
two forms without treating one or other as second-class.


> 5. Line terminators
>> This file has  terminated lines...
> I'm afraid that problem is a bit beyond me. As far as I know,
> SaintEdit is the only Macintosh text processor that allows you
> to specify line terminators, and I don't fancy opening each and
> every Musica Viva document in SaintEdit before uploading.

BBEdit Lite does the same (and the full version of BBEdit also manages
site uploading for you).  But the problem isn't with text processors,
it's with brainless transfer agents that don't convert terminators in
text files properly.  If the original file uses any of the standard
options coherently, it's not the source site's problem if duff web
browsers and mail agents fuck up.

===  ===


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

Re: [abcusers] ghostnotes

[Jack Campin]

> Is it possible in abcm2ps, whish I'm running, to notate ghostnotes,
> either with the note in "(" and ")", with a cross for note head or
> as a smaller note?
> Gracenotes {} won't do, since that makes a slur to the following note.

That slur is a design bug in abc2ps.  No other program makes the same
blunder, and there are fixed versions of abc2ps available.

What's a "ghostnote", anyway?  When you say crossed noteheads, do you
mean the unpitched notes used to indicate claps, stamps and the like?

===  ===


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

Re: [abcusers] Steganography

[Jack Campin]

> I wonder if there any known cases of musicians encoding  messages  in
> the fine details of how they play?  This is done with song lyrics all
> the time, of course, mostly by using metaphor. But I don't think I've
> read of it being done with the music itself.

There are some stories of this in the piobaireachd tradition: one is of
a piper who was being held hostage on the ship of a force that was about
to attack his home village.  Being asked to play something innocuous as
they neared land, he instead launched into the clan's alarm call.  The
attackers killed him on the spot but the warning was enough to beat off
the raid.  (I don't think any of these stories are verifiable, but there
are quite a few of them).  But coding a bunch of set prearranged signals
is easy.

I seem to remember something closer to what you want in a story about
a woman singing a lullaby to her child in such a way as to warn her
lover that her husband was around; she emphasized certain words in the
lullaby so as to spell out a message meaning "go away".

This tune has a cleverly encoded piece of symbolism, albeit of rather
limited application:

X:1
T:Old Nick's Lumber Room, or the Pawnbroker's Warehouse
S:Edinburgh Public Library "Musical Scraps" v2 p116
Z:Jack Campin 1998
N:press cutting in 19th century style
N:anybody know where it comes from?
M:6/8
L:1/8
K:A
A3 (cAc)|eae  cAc|E3 (GEG)|B^dB GEG|A3   cAc|eae cAc|faf ^dBd|e3- [e3E3] :|
E3  GEG |B^dB GEG|A3  cAc |eae  cAc|faf ^dBd|eae cAc|B^dB GEG|A3  [A3A,3]:|


===  ===


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

Re: [abcusers] Gloggauer Liederbuch

[Jack Campin]

> I look for the "Gloggauer Liederbuch", does anyone know if there
> is an internet source for this renaissance song book ?

*boggle*

Do you realize how BIG it is???

It's no more complex than the Atalanta Fugiens pieces I just did, but
it would be months of work to code it all.

A hard copy cost as much as a fairly good bicycle last time I looked.

Also, it's probably still copyright.  It was first published complete
in 1936.  I can't see anybody working from a facsimile of the MS, as
re-editing would add maybe another couple of years to the time.  You'd
need clearance from Barenreiter to code up their edition.  (I once
expressed a hope that this was covered by the loss of intellectual
property rights on Third Reich products imposed as war reparations
after WW2, but it seems that only applied to technological stuff like
the design of the Leica, and was short-lived in effect).

It's "Glogauer", incidentally.

===  ===


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

[abcusers] PGP = Paranoid Guff in Postings

[Jack Campin]

> Taral <[EMAIL PROTECTED]> wrote:
> This message is digitally signed. Please PGP encrypt mail to me.
> Content-Type: application/pgp-signature
> Content-Disposition: inline

I have now trashed six of these things.  I haven't looked at a single
one of them.  Has anybody here?

Please stop this.  It's just annoying clutter we have to delete.
I'm not paranoid enough to care if somebody might be impersonating
you.  And since I'd never heard of you until two days ago and you
don't use a real name it's a non-question; impersonating somebody
anonymous would be pointless.

Nobody on this list needs their identity authenticated.  If your
opinions are worth hearing (and yours obviously are) nothing else
matters.


-----
Jack Campin  *   11 Third Street, Newtongrange, Midlothian EH22 4PU, Scotland
tel 0131 660 4760  *  fax 0870 055 4975  *  http://www.purr.demon.co.uk/jack/
food intolerance data & recipes, freeware Mac logic fonts, and Scottish music


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

Re: [abcusers] PGP = Paranoid Guff in Postings

[Jack Campin]

>> I have now trashed six of these things.  I haven't looked at a single
>> one of them.  Has anybody here?
> Apparently lots of people read them, since I have had plenty of good
> discussion here.

I was talking about the attachments (that was what I quoted) not your
messages.  If there has been any discussion of your PGP signature I
missed it.


> The fact that you're seeing them and not my message is
> indicative of the poor quality of your mail client

I'm seeing both.  I want your messages, I don't want the attachments.
(Some mailing lists automatically reject any messages with attachments,
you're lucky you can get anything through at all with them stuck on).


> (as is the invalid empty Sender: header field).

I don't create those header fields, the mailing list software does.
Your messages have the same feature, as does anything coming out of
argyll.wisemagic.com.

===  ===


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

[abcusers] Lynx and ABC

[Jack Campin]

I am trying to figure out how to make MacLynx fire up BarFly for ABC
files.  The lynx.cfg file says how to set the image viewer, but not
other kinds of helper applications.  Ideas?


===  ===


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

Re: [abcusers] dynamics

[Jack Campin]

>> I'm probably going to have to provide an "abcfix" program that
>> attempts to "standardize" non-compliant abc files. 
> I'd like to see how that handles BarFly output. 

BarFly doesn't *have* output; it's a text editor, it doesn't enforce
any ABC dialect any more than Emacs does.  I've used it to write ABC
that no version of the program itself could play or print.

While I'd like to see a bit more interoperability, I'd be more
interested in functionality - there are still lots of musical
features that could be fitted into ABC without drastic upheaval
but which no ABC implementation yet does right.  There is no way
ABC is going to take off in any genres beyond those it's got to
already unless some extensions are made available; why should
users with divergent specialist needs (rehearsal marks, editorial
annotations, microtonality, lead sheets, text in two-byte character
sets...) have to wait until *every* application implements them?

One problem with using a common library: turnaround time for bugfixes.
Some of the most-used ABC applications out there get updated no more
than yearly, others get fixed within days of having a bug reported.
If a bug is discovered in a library, this adds a new source of delay;
the library maintainer will need to work fast to keep up with the
quickest application developers.  For some specialized library functions
the open-source model might not help all that much as there might only
be one developer in the group who understands what the code is supposed
to do.

On the other hand, a common specification (a real one, rather than the
handwaving in the current documents or purely syntactic stuff like
Henrik's BNF) would benefit everybody without introducing new problems
like this.  What formalisms would all the developers find readable?

===  ===


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

Re: [abcusers] dynamics (again)

[Jack Campin]

>> BarFly doesn't *have* output; it's a text editor, it doesn't enforce 
>> any ABC dialect any more than Emacs does. 
> Don't text editors have output?  
> I am not a Mac user so I have no direct experience of the nature o
> BarFly, but I do know that a number of people have posted tunes in
> abc generated by using BarFly.  From where I'm standing these are
> BarFly output.  They appear to have various characteristics which
> make them incompatible with the abc software available to me.  Do
> these not arise from the use of BarFly, or is it just that all
> BarFly users are working to a different definition of the abc
> standard? 

Programs like abc2win only let you output ABC they can interpret.
BarFly lets you write any text you want and never modifies it without
you asking it to.  There's a built-in incentive to write stuff that
BarFly can print or play, but no more than that.  Quite a bit of the
stuff in the modes tutorial on my website gives horrible staff-notation
output when BarFly typesets it; I regarded source legibility as more
important. 

You could use it as a C++ programming editor if you wanted to.  I've
occasionally written email messages with it before copying them to my
mail client.  I have stacks of poems and bibliographic references
originally copied with it.  When I'm using a laptop with very limited
memory it helps if I can work with only one text-editing application
running and have it do the whole job.  I don't expect it to make
musical sense of a letter describing an 18th century riot.

I don't confine myself to the subset of ABC it implements; if I need
a feature in ABC to represent a piece of music in front of me I'll
invent it and let the programmers catch up when they can.  This is part
of ABC's inheritance from similar paper notations - the user is in
control - and it's something that shouldn't be lost.

Given the basic idea of ABC - that it's tunes notated in text files
which may contain other material - no more restrictive attitude makes
sense.  If the "other material" in a tune file can be any text, that
text can be an arbitrarily close approximation to valid ABC.  It's
fine for an application to report that it can't figure such stuff out,
or to say that it doesn't meet some agreed standard, but that doesn't
mean it shouldn't be there.

===  ===


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

Re: [abcusers] requesting goodies from developers

[Jack Campin]

Gianni Cunich wrote:

[Gianni, please don't quote an entire message when replying; you quoted
 a heck of a lot in your reply and then your software appended the whole
 of my text as well.]

>> What features do you need and why?  Does anybody else need them?
> I'm not concerned about asking new or particular features. I've been
> asking for an update of the standard, introducing what has been agreed
> about in the drafts, plus a solutions to the main features the developers
> on this mailing least have not been able to reach any agreement at all
> so far - i.e. multistave and multivoice scores -. Do you think I'm alone
> in this requests?

No, but that amounts to asking for a lot more new features to be added
to *all* the ABC applications out there; a different set for each one
and with the difficulty of implementation of an extension being very
variable depending on which platform you're adding it to.  (John Chambers'
extended-variant-repeat construct is easy to add to a purely graphical
implementation and quite hard for a player program; my suggestion for
percussion staves is easy to add to a pure player program and a lot
harder for a staff-notation generator if the assumption that staves
have five lines was wired in too deep).


> In other words, what I am concerned with is a developement of the abc
> notation as an exchange format. I wish to be sure that if I upload on the
> web or swap on a mailing list anything that's not a sketchy Irish session
> tune written in sketchy Irish session tunes fashion - say a three part
> Italian fiddles plus bass transcription - those who will be wishing to
> make use of it could trust, whatever software they use, that they will
> be able to display (at least for what matters) the score I'd print with
> the software I use, or listen to a midi files that ensure a correct
> listening rather than making a mess of the tune.

With the multi-voice stuff, the differences are resolvable with fairly
simple editing; the main problem is the different pitch conventions
for non-treble staves between BarFly and the abc2ps variants, and BarFly
has transposition utilities to help with that (I presume something
analogous is possible on platforms that support abc2ps).  I've used
Laura's ABC files without much trouble and she's done the same with
mine, though neither of us has made any concessions to the other's
usual platform.

One of ABC's main strengths is that the user can easily tinker with it
(impossible for graphic file formats); need a version with different
note density, different chording or an unusual transposition? - just
make it yourself.  It's a format for musicians, not for the sort of
passive listeners who are best served by MIDI files.  Learning to play
a piece always takes a certain amount of time, so it's no great hardship
if a fraction of that time is spent in getting the piece into a form you
can use.

The user makes more difference than the developer here.  If an ABC
file is clearly written *as source*, with the right choice of default
note length and laid out with some regard to the musical structure,
it's easy to work round dialect differences because you can see what
you're editing.  Easier than it is to modify a sloppily-encoded piece
that fits your own platform's model perfectly but in ways only a
computer can understand.  (We should maybe have an annual obfuscated
ABC contest to underline this point).

So, what you could do is carefully code up a piece of the sort you're
talking about and upload it somewhere.  Doesn't matter which platform
you use; if the music's worthwhile it'll act as an incentive for the
developers to add features to handle it.  (BTW, isn't Frank's Vivaldi
concerto an example of the sort of thing you're talking about?  What
goes wrong with it?)


> [attributed to a developer] "the abc is such a poorly implemented
> standard, full of inconsistencies and ambiguities..."

The 1.6 standard is doing pretty well, in that virtually everything
in it *is* implemented consistently; there are only three significant
misimplementations I can think of - abc2win's idea of tempo, BarFly's
idea of where a line breaks, and abc2ps's way of handling gracenotes -
and only the last of those lets the user in for much typing to work
round it.

The last one is a specific problem for abc2ps.  It has been fixed
in some of the variants, but there's nothing at present to dissuade
somebody doing a new version based on the unfixed code and thereby
resurrect the bug.  A shared code library where the gracenote-handling
modules could be once-and-for-all, definitively updated would finally
bury the earlier version with a stake through its heart (with pipers
the world around dancing on its grave).

===  ===


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

[abcusers] text line break

[Jack Campin]

I've been doing a lot of stuff lately where it make sense to indicate
where text lines in a song finish, without doing full-on underlay of
the sort allowed for by the w: construct.

The way I've been doing it is the way old hymnbooks did it, using
double bars.  But this seems rather heavyweight and clashes with
ABC's repeat syntax.

Would a special symbol help anybody else?  "!!" maybe (in the hope
that abc2win's "!" gets into the standard and hence becomes reserved).

Note that in BarFly (and any other program with the same attitude
to linebreaks) this would HAVE to allow a staff break as a barline
or double bar does at present, there'd be no point in having it
otherwise - you don't want to start a text line on the last note
of a staff line, which is what would happen where lines begin with
upbeats.

===  ===


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

Re: [abcusers] requesting goodies from developers

[Jack Campin]

>> The user makes more difference than the developer here.  If an ABC
>> file is clearly written *as source*, with the right choice of default
>> note length and laid out with some regard to the musical structure,
>> it's easy to work round dialect differences because you can see what
>> you're editing.  Easier than it is to modify a sloppily-encoded piece
>> that fits your own platform's model perfectly but in ways only a
>> computer can understand.  (We should maybe have an annual obfuscated
>> ABC contest to underline this point).
> Maybe, sorry to quote you entirely again, an upadated standard, ridden
> of the inconsistencies and the ambiguities of the old one, and stating
> clearly as a number of new features were to be notated, would give
> exactly the same results, but with no need to learn different abc
> dialects or to edit the files!

You can't change the past.  There are tens of thousands of ABC files
already out there on the web and a lot of them conform to no standard
that has ever existed.  They're not going to disappear, most are not
going to be fixed on their home sites, many will go on echoing down
the years in their original form on mirror sites even if they do get
fixed by their creator, and they're not going to lose their musical
value.  So new standards won't help avoid the need for editing.

For an example, look at the American fife tunes on my site.  That
was a rescue job: I had a copy from a defunct website.  It was the
only one anybody knew of and the original transcriber had vanished.
Whatever print sources he was working from seemed to be unknown to
anyone else.  So this stuff was unique.  It was also a thoroughly
slapdash piece of work, with syntax errors and just plain gibberish
making it unusable on *any* ABC implementation.  I cleaned it up
manually; the file on my site contains both the cleanup and the
original so you can see what I've done.  Creating a new standard
would not have solved this problem: human editing was the only way
out (which involved me learning a dialect of ABC which seems to have
existed only in the transcriber's mind).  It wasn't a particularly
big job but it wasn't an automatable one.

Being more standardized may not necessarily make a version of a tune
preferable.  When I'm looking for a tune in a hurry I quite often use
John Chambers' versions: he has one irritating habit which invariably
forces me to edit - putting empty bars into the ABC source because
that way his typesetting software puts a barline at the start of each
line given the linebreaks he prefers - but nonetheless his versions
are accurate, they have good chordings and they are laid out readably
so if I want to monkey about with something (e.g. rewriting a phrase
of fiddle music to fit the flute) I can easily identify which bit needs
monkeyed with.

At this point, I think editing tools would be more useful than more
standardization.  Software for transposing, changing the default
note length in tunes, introducing broken-rhythm signs in the right
places when the original uses numbers, changing multivoice conventions,
putting header fields into your preferred order, swapping between
"T:.*, The" and "T:The .*", computing a checksum and putting it into
the header, checking for gross mistakes and helping to fix them (bars
that don't add up, ties between notes of different pitches, notes out
of range or impossible gracenotes when using an HP key signature),
"diff"-like tools that locate similar phrases and display their
differences, tools to identify chunks that could be abbreviated using
repeat syntax and to expand repeats into fully-written-out forms.
Given enough whizzbangs like this, standards become less important,
as it's easy to transform stuff from one style of ABC to another.


> I [...] stated [...] that the abc standard, as far as the native
> softwares were concerned, had a built in line break carachter: a
> blank P: field in the body. Actually, Jean-Francois Moine hacked
> abcm2ps (yes, as far as Windows is concerned, this is the only
> native abc free source software that IMHO is worth consideration!)
> to enable printing a part label in the middle of a music line -
> yet, I don't think anybody else has done anything similar

BarFly does what you want here (sort of: the part label doesn't appear
where you type it but after the next bar, which is horrible for sections
with upbeats, but at least you don't get a line break when you don't
want one).


> I am simply asking, to start with,  to be able to notate a second
> treble voice on the melody line, and a bass line on a second staff.

There is no reason why every implementation has to allow this.  If a
developer's primary focus is on doing a really good job for a single
kind of music - say, guitar-accompanied songs or Highland pipe music,
both of which have picky requirements and neither of which needs the
feature you're asking for - users who get the software because it does
what they want don't necessarily need to worry about wh

[abcusers] mailing list abusers

[Jack Campin]

Would I be correct in assuming there is a category of net abuser
who lurks on a mailing list for just long enough to find out how
to start a pointlessly destructive discussion and then tries to
drown the forum in crap?

If so, I assume there must be resources for identifying such people
and dealing with the abuse.  There is no point in knocking them off
this list if they're just going to move on and do the same thing on
lists devoted to baseball or palaeontology.


===  ===


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

[abcusers] something really simple

[Jack Campin]

> And, oh yes, let's start discussing something really simple. We all
> need some discussing practice before we try to handle the big stuff.

Okay: tempi in words.

It ought to be possible to write

   Q:allegro

in a tune header or

   [Q:allegro]

in a tune body, and optionally define outside the tune (earlier in
the same file or maybe in a separate settings file) what "allegro"
might mean in numerical terms, with a line like this:

   Q:allegro 1/4=120

I suggest that in addition, a tune header might contain mixed tempo
specifications, so that when the line

   Q:allegro 1/4=120

occurs in a tune header or

   [Q:allegro 1/4=120]

in a tune body, both the word and the number are displayed/printed
and that number is used by player programs.

Where there is no number in the header, you would expect only "allegro"
to appear in the staff notation, regardless of whether it was numerically
defined elsewhere.

Further: it should be possible to define tempi in ranges, like

   Q:allegro 1/4=120-128

Staff notation programs should print this range if it appears in a tune
header; player programs should use a value from that range (how it is to
be chosen is outside the scope of the specification).

Yes, this requires that programs scan an entire tune file to find these
definitions.  I can't imagine there being any file big enough or any
computer slow enough for that to matter.  (How long would it take a
state-of-the-art personal machine like a fast Mac with Altivec, using
an efficient matching algorithm, to scan the entire world-wide ABC
corpus for lines like the above, once it was all in-core?  A lot less
than a second, I suspect).

In BNF:

   number ::= numeral*
   textchar   ::= alphabetic | space | ""
   tempolabel ::= alphabetic
   tempolabel ::= alphabetic [textchar* | alphabetic]
   tempoLHS   ::= number "/" number
   range  ::= number "-" number
   tempoRHS   ::= number | range
   tempospec  ::= tempoLHS "=" tempoRHS
   tempo  ::= "Q" ":" tempolabel
   tempo  ::= "Q" ":" tempospec
   tempo  ::= "Q" ":" tempolabel tempospec

which rules out tempo labels like "presto as defined by Quantz in 1750"
because of the date but should be general enough to be useful.

I don't think there is any point in extending the old "Q:120" style of
tempo specification in this direction.  It was a bad idea in the first
place and it needs to go.  Let's not do anything that might encourage
people to still use it in more elaborated contexts.

===  ===


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

Re: [abcusers] something really simple

[Jack Campin]

> The point is that you might want to specify a tempo for a MIDI player,
> but not print it for a human player.
> Or to specify a tempo in quarter notes per minute for a MIDI player
> but with a word like "allegro" for the human.

That's exactly my motivation for wanting this added to BarFly, but
BarFly uses QuickTime as its usual playback mechanism - MIDI is
supported as an export format, but the program itself doesn't play
MIDIs.

This make a difference for pipe tunes - the MIDI-exported versions
don't have the continuous drone that BarFly can add to them, as MIDI
can't represent a note that long while QuickTime can.

If we are going to have this sort of environment-specific control,
wouldn't it better to layer it into three levels, so that at the top
level you had a distinction between sound, graphic and database-
related aspects, at a lower level distinctions between the file formats
involved (MIDI, AIFF, QT, GIF, EPS, PDF, BibTeX, SYLK...) and at the
lowest level distinctions between specific programs?

But there's no reason why a sound-generating program couldn't make
sense of "allegro", via an external table of tempi or the syntax
I suggested, so there's no need to go down that road for this issue.

===  ===


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

[abcusers] ABC used as tablature

[Jack Campin]

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 mandour, a sort of five-course ukelele.

By using BarFly's text colouring capability you can make the x's less
conspicuous (or colour them white and make them vanish entirely) which
improves readability.

The staff notation this generates isn't as good as if you'd written the
ABC optimally for that, but it's usable.

X:1
T:Adew Dundie
S:Skene MS, early 17th century Scotland
S:Dauney, Ancient Scotish Melodies (1843)
V:1 program 1 46   down % a
V:2 program 1 46 merge down % d
V:3 program 1 46 merge down % A
V:4 program 1 46 merge down % D
V:5 program 1 46 merge down % A,
M:3/4
L:1/4
Q:3/4=56
K:D Dorian
V:1 x  x  x |x  x  x |x  x  x |x  x  x |a2c'|a2c'|a  x  x |x  x  x:|
V:2 x  d  d |d2d |x  x  d |e  g2   |x  x  x |x  x  x |x  g  e |d2x:|
V:3 A  x  x |x  x  x |c2x |A2x |A2x |A2x |x  x  x |x  x  x:|
V:4 x  x  x |D2x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |D2D:|
V:5 A, x  x |x  x  x |C2x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x:|
%
V:1 a  c' c'|c'2   c'|x  x  x |x  x  x |a  d' d'|d'2   d'|d' c' b |a3  |
V:2 x  x  x |x  x  x |x  x  d |e  g2   |x  x  x |x  x  x |x  x  x |x  x  x |
V:3 x  x  x |c2x |c2x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |
V:4 x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |A3  |
V:5 x  x  x |x  x  x |C2x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |
%
V:1 a  c' c'|c'2   c'|x  x  x |x  x  x |a2c'|a2c'|a  x  x |x  x  x|]
V:2 x  x  x |x  x  x |x  x  d |e  g2   |x  x  x |x  x  x |x  g  e |d3 |]
V:3 x  x  x |c2x |c2x |x  x  x |A2x |A2x |A2x |x  x  x|]
V:4 x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x |D3 |]
V:5 x  x  x |x  x  x |C2x |x  x  x |x  x  x |x  x  x |x  x  x |x  x  x|]

(Phil - your mode guessing utility gets this one badly wrong, and it seems
fairly clear why).


===  ===


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

Re: [abcusers] possible abctab2ps extensions

[Jack Campin]

>> I defintely don't want to have to write a Highland 
>> pipe jig (typical grace = 1/32) like:
>> L:1/8
>> K:HP
>> {g//}A{d//}A{e//}A {g//e//f//}e2 f | {g//}ec{G//}c {g//e//f//}e2

> 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

Why the quotes?

I'd prefer

  L:1/8 {1/32}

and for the functionality Ewan wants, setting this once and for all for
a bunch of tunes, have a line near the start of the file just saying

  L:{1/32}

with the default length for melody notes unspecified and maybe varying
throughout the file.


: The format = is preferable because it is more flexible
: and allows future extensions.

In this case there aren't likely to be any future extensions, so
readability becomes a more important consideration.  Even when there
are likely to be extensions, this syntax can be too ugly to consider;
e.g. for non-Western key signatures, would you really rather have
"K:D Major second=_E sixth=_B" than "K:D Major _E _B" ?

I think of the header fields in ABC as being typed, and *not* all of
type "string".  For such information alternative lexical syntaxes
are usually appropriate.  The type of this field is presently that
of rational fractions and the proposal makes it a variant, rational
fraction or pair of rational fractions (or perhaps ordered pair of
[rational|NULL]).  I can think of only one piece in all music where
you'd want anything different, Nancarrow's player piano piece where
the basic note lengths of the two parts are in the ratio 1:sqrt(2).


: And most important, it solves most compatibility problems: programs
: only interpret the  clauses which they know and ignore the other.

It's no harder for a program to ignore "{1/32}" than "grace="1/32"", is
it?


BTW, there is a seriously hairy problem with the semantics of variable-
length gracenotes in Highland pipe music.  There are bunch of pibroch
transcriptions on the web which encode them in full gory detail using
the Piob Mhor notation; I don't have a machine which can process that,
but I think the effect is that it plays right while also generating the
usual sort of score, which has the timing oversimplified.  I don't think
it's reasonable to ask the implementors of player programs to understand
details of interpretation that are normally passed on by oral tradition,
but if their software can accept gracenote groups like {ge4d} without
gagging and maybe play them as {ged} that'll do for a start.

But let's get tempo fixed first.


===  ===


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