Re: [abcusers] Re: ABC, AHC, Do-Re-Mi
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
FA | B2(EF)E2(AG) | (FA)(EF) D2
(de) |\
(fe)(dB) (dB)(AF) |B2 (EF)E2
:|
(TFE)| D2(de)d3 e| (fe/f/) (e/d/)(c/B/) A3
d |\
B2(ef)e3 f|({a}g)f ({f}e)d B2
(de) |
f2 ({a}g)f e2 ({g}f)e |dedB ABde
|\
(fd)(eB) (dA) (B/A/F/A/)|B2 EF E2
:|
(FA)| B2 E2 d3 c/B/ |A(B/G/) ({A}G)(F/E/)D2
de |\
fdef (DEF)A |B2 EF E2
:|
(TFE)| 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
(de) |
(fe/f/ g)f(ed/e/ f)e |d(c/B/) dF A2
(de) |\
f/(e/d/f/) e/(d/B/e/) (d/B/A/d/) (B/A/F/A/)|B2 EF E2
:|
FA | BE2 F G(A/B/) AG|F/(d/c/B/) A/(G/F/E/) D2
(de) |\
f (3(e/d/c/) d (3(c/B/A/) BDEF |B2 EF E2
:|
(TFE)| 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
(de) |
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 EF 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...
...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] Distributing DLLs
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] Re: abcusers-digest V1 #364
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
[abcusers] Lewes's little local difficulty
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|] TITLE 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. /TITLE 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*.] === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
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}feae {g}f4 |
{g}Bf {g}eB {GBG}c3 B|{g}f{e}f {e}Hf2 {g}f4 |\
{g}e2 {fege}f2 a3 e|{g}feae {g}f4||
{g}fa {eAfA}e2 f3 c|{g}e2 {fege}f2 {ag}a4 |\
fe ae f3 c|{g}e{A}He {A}e2 {g}He4||
{g}e2 {fege}f2 a3 e|{g}feae {g}f4 |\
{g}fa {eAfA}e2 f3 c|{g}ef {g}ef {ag}a4|]
=== http://www.purr.demon.co.uk/jack/ ===
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Gonna be off-list for a while
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... === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
RE: [abcusers] Update to jaabc2ps
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] accidentals in ()
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
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? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] the Dead ABC Scrolls
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] developers/users
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] developers/users
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] !
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Global Accidentals
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] variant-octave key signatures
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 BAB|c2A F2D|GAG B2c|d2g d2c|B2c d2e|f2d B2G|ded cBA|G3 G2:| d|g2d B2G |c2A F2D|g2d B2c|d2g d2c|B2c d2e|f2d B2G|ded 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?... === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] problems with the R: field
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 |Ac Bd | 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? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Chord notation
guitar chord = silence|chord silence = X chord = root[modifier][/bass] root = note bass = note note = note letter[accid] note letter = A|B|C|D|E|F|G accid = #|b modifier = 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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Chord notation
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Chord notation
[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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The abc committee (Was: Hi)
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)
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] do these chords have a standard meaning?
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? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] parts, voices and ostinatos
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 |]
=== http://www.purr.demon.co.uk/jack/ ===
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Composer/Lyricist Distinction
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Making PDF (Was: ABC standards committee webpage)
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? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Tune archive updated
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? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] small fragments?
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Pythagoras
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] how about 372 key/mode combos, then?
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: v04003a50b6add422bc5a@[128.173.232.136] [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. He also shows how various modes can be transposed to
Re: [abcusers] midi2abc (was: Wanted: ABC transcription...)
The cc 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] Does anybody kow this ballad?
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] linux only ?
(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? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] barlines at the beginning of a staff
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? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] GIF
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? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Folk band
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). === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Three-handed job.
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Tune Finder oddities
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? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] on being ripped off
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 www.purr.demon.co.uk/jack/, 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
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? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC in an internet cafe
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] macros
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/|dGdB Gd (c/B/).A/.G/|AfFf cF (A/B/c/).A/|\ dGTdB Gd (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] dGdB Gd (c/B/).A/.G/|AfFf cFA/B/c/A/ |\ dGTdB Gd (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 |fcdfc/B/A/G/ Fd |\ #~ga/b/ (b/a/).g/.^f/ gddg |fc 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 |fcdfc/B/A/G/ FA |\ GBA/B/c/A/ Bdce|dB 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/|dGdB Gd (c/B/).A/.G/|AfFf cF (A/B/c/).A/|\ dGTdB Gd (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] dGdB Gd (c/B/).A/.G/|AfFf cFA/B/c/A/ |\ dGTdB Gd (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 |fcdfc/B/A/G/ Fd |\ #~ga/b/ (b/a/).g/.^f/ gddg |fc 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 |fcdfc/B/A/G/ FA |\ GBA/B/c/A/ Bdce|dB 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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abcmac - BarFly-style abc macro preprocessor inPerl
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). === http://www.purr.demon.co.uk/jack/ === 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
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] net-friendly information
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:url = http://www.purr.demon.co.uk/jack/McLennan.abc or E:KEYWORD = accordion, musette, Viseur or E:ID = Evita/DontCryForMeArgentina/FullScore@TheReallyUsefulCompany 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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Susato's Danseryes
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 |cB A2 |^G2 z2:| V:2 B,4 |A,2 D2 |B,3 A, |B, C A,2 |CD 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 EF | 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 work planning
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). === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ghostnotes
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?
=== http://www.purr.demon.co.uk/jack/ ===
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Steganography
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]:| === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Gloggauer Liederbuch
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] PGP = Paranoid Guff in Postings
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
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Lynx and ABC
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? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics
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? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics (again)
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] text line break
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] requesting goodies from developers
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 what it can't do. There are other
[abcusers] something really simple
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. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] ABC used as tablature
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). === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] possible abctab2ps extensions
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 param=value 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 param 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.
=== http://www.purr.demon.co.uk/jack/ ===
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something fairly complicated (Q: field)
Is there any mileage in something like Q:Allegro=120 % definition ... Q:3/8=Allegro % use, meaning that the beat is 3/8 in this case I hadn't thought about the problem of varying beat length in my initial proposal and I should have. What I would prefer would be to allow: Q:[6/8] Allegro 3/8=124 % definition Q:[C|] Allegro 1/2=120 % definition so that the speed you'd get from a later use would depend on the time signature. It's quite likely that this happens in some musical genres already. That way, the tempo definitions could be in the file header, perhaps written by somebody other than the tune transcriber, and the transcriber would not need to think about the size of a beat on a per- tune level. The fact that Jim Vint and his users have been getting the notions of beat and default note length muddled for years suggests that (a) beat size is something it's easy to get wrong and (b) it isn't going to be easy to get people fluent with the correct concept. The scheme above would also allow for more generality when the M: field gets extended. You can't make a once-and-for-all, culture-independent definition of what the right beat unit for 9/8 is, regardless of whether it's 3+3+3 (slip jig) or 2+2+2+3 (aksak). Whereas when we get to be able to write an aksak time signature explicitly the above simply extends to Q:[(2+2+2+3)/8] Allegro 2/8=120 which would not match with the header of any slip jig and hence not confuse their tempi. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
I belive it is not really neccessary to define the beat of allegro in Balkan music (like 3+3+2), I've never heard of such a definition in any other music notation context. And for sure it would be an abuse of the classical music's tempo word Allegro. I just fished out my copy of Maud Karpeles' Folk Songs of Europe (1956). She has: - a Latvian song in 3/4:4/4, Moderato patetico - a Czech song in 2/4:3/4, Andante - a Hungarian song with no time signature, Parlando - a Romanian song, ditto, Vivo - a Macedonian song in 7/16, Allegro giocoso - a Dutch song mixing 9/8, 6/8 and 3/8, Allegro - an English song in 5/4, Allegretto e semplice etc. Italian tempo names are used all the time by ethnomusicologists. Or if you want one from an entirely non-Western context, here's one from a collection of Kurdish folk songs. The songs are given in the original Kurdish, the commentary is in Turkish, and the tempo markings are entirely in Italian. No metronome marks at all and no explanation of the markings; the reader is expected to know, and if they'd gone through the standard Turkish high school music syllabus, they would. X:1 T:Hey lo, Seni B:Mehmet Bayrak: Kurt Halk Turkuleri, Ozge Yayinlari, 1991 Z:Jack Campin 2001 M:8/8 L:1/8 Q:Moderato N:Bar 6 is (3B,/F/E/- E E/ D D C- C (3D/(D/C/)| in the N:book, which doesn't add up so I'm assuming it's a typo K:B Minor AF2 A/F/ A F2A/F/ | AF2 A/F/ F E (D E/)F/ | FE2 E/D/ D C2D/E/ | F DD CC B,- B, (3C/(D/C/) | E/D/ D/C/ C B,- B, B, B,2 | (3B,/F/E/- EE DD C- C (3D/(D/C/) | F DD CC B,- B, (3C/(D/C/) | E DD CC B,- B,- (3B,/B,/B,/|] And if ever it will be possible to use 3+3+2/8 in an abc M: field, we can find a way to define allegro under such a M: field. I don't understand this at all. Why would you want to roll tempo definitions into a field already designed for something entirely different? Are you suggesting this would make it *easier*? How? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
In an attempt to wrap up this thread, would the following proposal for a new field meet everyone's requirements ? Field Name: q:playing style Header: Yes Tune Body: No Description: Contains a written non-numerical description of the tune's tempo or mood. Examples: q:Allegro q:Lento That says exactly nothing about the semantics. Unless your q: field provides me with a way of DEFINING those strings in a musically intuitive way so that a numerical playback speed can be statically deduced from the musical text (e.g. by a playback program), there is no point in what you're suggesting. There are already about 10 different ways to put uninterpreted text into a tune header, we *do not* need another one. And these *have* to go in tune bodies. It is quite routine for tempo to change in the middle of a piece. That suggestion ignores 95% of the issues we've discussed in this thread so it's nowhere near wrapping it up. The central problem is how to specify the required definition mechanism. If nobody else jumps in first, I'll try to do a revised formulation of my proposal (in the light of the subtleties I hadn't thought of) in a week or two (too busy to launch into it immediately). === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
Unless your q: field provides me with a way of DEFINING those strings in a musically intuitive way so that a numerical playback speed can be statically deduced from the musical text (e.g. by a playback program), there is no point in what you're suggesting. There are already about 10 different ways to put uninterpreted text into a tune header, we *do not* need another one. The problem I have with the definition idea is that definitions are only useful if you re-use the definition. If a term is defined at the beginning of a tune, used once and then lost there is no point in having it. This seems to be how written tempos are normally used. No it isn't. A typical dance tune book will use reel time or waltz tempo the same way all through. In the Kurdish song book I quoted, the same Italian tempo terms are used over and over again and are NEVER defined at the beginning of a tune. There wouldn't be any point in tempo terms unless they had an understood meaning in a context wider than an individual tune. Today, everybody who has a metronome uses the commonest 8 or so Italian terms in the same way to about 1% precision because they're engraved on the scale, and I would guess the world contains a few million more metronome users than ABC users. A typical case where definitions need both to be shared among multiple tunes and also need to be easily redefinable: military marches. In some cases, British regiments have been using the same tunes to march to for 300 years. And they have usually had their tempi labelled the same way all that time: slow march, quickstep, retreat. But the numerical values of those tempi have risen steadily over the years, as soldiers have had better roads to march on and needed to carry less of their own equipment (the exact numbers are in period military manuals, and were insisted on; disagree with the RSM about the speed of a march and you could look forward to cleaning the parade ground with a toothbrush). And these terms have still faster definitions when the same tunes are used for country dances. So, if you've got a file of marches, and want to hear them as they might have been played in the American War of Independence or the Crimean War, it makes sense to just change the tempo definitions *once* at the start of the file and have *all* the tunes interpreted consistently. In the case of pipe band marches, each band today has its own set of tempi. There are ABC files out there with hundreds of marches. It's up to the pipe-major to decide the speed, NOT the tune transcriber, and it's a waste of the P-M's time if they have to go through the whole file and treat every tune as a special case. It seems we haven't even agreed what the problem is. The problem is how to use textual descriptions of numerical playback speeds in ABC. I think it will be difficult to agree on a solution. We've had quite a few variant proposals but they're mostly in the same ballpark regarding what they can express, most of the differences are merely syntactic. So I don't think this is going to be all that hard. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] a request to developers
I am about to release a CD-ROM with a large number of very carefully
edited and documented tunes linked off a hypertext commentary (see
http://www.purr.demon.co.uk/embro/). This is the work which all the
ABC on my website is spinoffs from. I would like to include a choice
of ABC applications along with it. Would any developers out there
(other than the ones I've already contacted) like to get a copy, try
it out, and report major incompatibilities? I'm not changing any tune
at source level to work round temporary limitations in implementations,
as I expect people to still be using the material in ten or twenty years'
time.
I use some constructs only affecting a few tunes that I don't expect to
be widely implemented; hence my decision to provide BarFly-generated GIFs
and QT files for people whose platforms break on those. That *should*
only be multivoice ABC and underlaid words. If an application fails on
T for trills, can't do bagpipe-style gracenotes (like {dGAG}A{G}A with
no slurring), or insists on initial repeat signs, forget it. I don't
expect any implementor to do really systematic testing, but a general
idea of where a program is useful for my stuff and where it isn't would
be helpful.
=== http://www.purr.demon.co.uk/jack/ ===
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
: Most of
: the information fields are for use within a tune header but in
: addition some may be used in the tune body, or elsewhere in the
: tune file.
This is not a widely implemented feature of the abc standard and I
would personally like it to become deprecated. My reasoning is that
if you have global fields, you can't treat a single abc tune as
something that can be edited out of its source file (which you might
do if you wanted to print off just one tune from a collection).
You can't do a lot with a C function like
void thing()
{
x++;
}
unless you have a declaration for x in the environment, either.
You want to rewrite yaps in a language that uses those constraints?
(Only assembler does, as far as I know).
The point is that the non-local definability is USEFUL. Trivial tweaks
that only affect the typeface header fields are displayed in is an utter
waste of time. No ABC program is ever going to compete with a special-
purpose music typesetting engine and it's pointless trying. But ABC
*already* has richer semantics in some directions than they do, and much
greater flexibility of application. Those are directions in which further
extension will give it unique advantages among all other forms of musical
representation.
These non-local features are not exactly cutting-edge stuff to implement,
given that programming languages have had declarations since 1956 or
thereabouts and block scoping since 1960. And it was in the very first
computer implementation of ABC.
I don't *want* my tunes edited out of the context I presented them in.
Ever. Any proposal that helps prevent it is an advantage in my book.
Conversely, anyone who *does* want their tunes edited out of their
original file context can just avoid using non-local constructs. You
couldn't very well use them accidentally.
So the only people being hampered by this are people who want to use
music in a way that the original transcriber didn't want them to. Is
that a category of people we want to cripple the notation for?
] I'm on a number of mailing lists that use abc a lot, and I have some
] little programs to extract tunes from email messages and do something
] with them. The problem is that messages often have a bit of discussion
] of the tunes, including history and variants and other similar tunes.
] It isn't at all unusual for the text before the tunes to have fragments
] of abc, sometimes just a few header lines, and these fragments often
] have little or nothing to do with the later tunes in the message. So
] if the fragments are added into later tunes, the result is often not
] at all what was intended.
Perhaps having their messages automatically harvested by bots might not
have been what the authors intended either. You can't assume it unless
that was stated up-front as the policy of the list when they joined.
What was the problem with contacting the transcriber and asking them?
Maybe they might have wanted that history included (e.g. as comment
lines or embedded in H: fields). It's not like we're short of ways to
quote stuff. If somebody puts an ABC tune in an email message, a simple
default is just to put % signs at the start if every line that isn't the
tune.
=== http://www.purr.demon.co.uk/jack/ ===
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] tempo miscellanea
Chord notation is not free text. It is a chord. There may be no restriction to the syntax of a chord to be presented, but semantically, it's a chord. And for some playback programs (Muse is one, I think) chord semantics is both precisely defined and used by the interpreter; Laurie suggested standardizing it a while back and nobody seemed to have much problem with what he suggested (where there are idioms with different conventions, this is another place where a definition mechanism could be used). A tool that created ABC piano scores from guitar-style notation (are there any?) would need the same semantics, i.e. this isn't just about playback. Likewise, tempo indicators are not free text. They are tempo indicators. There may be no restriction to the syntax of a tempo indication, but semantically, it's a tempo indicator. Semantics is about giving expressions *values*. It's a feeble sense of the word that ignores that. An indication that doesn't have a value and can't be given one doesn't have a semantics the way I see it. _Excitedly and _Placidly are not tempo indicators. They may print out in tadpoles as tempo indicators, but they will not be read by human readers of the ABC notation, nor by playback programs, as tempo indicators. They fit just fine into the remit of the R: field, though. It wouldn't hurt a bit if we made finer distinctions than staff notation does over this one. (Icky example from a 19th century edition I've got: finale of Beethoven's string quartet op18 no6, La Malinconia Adagio all in the same font used for tempi elsewhere - since when was La Malinconia a tempo?) : So, *how* does it describe the speed? How does your suggestion : distinguish texts that define speeds from arbitrary gibberish? : It doesn't, at least it doesn't any more than a program can : distinguish between the actual title of the tune in the title field and : arbitrary gibberish. I don't see a standard (as in ABC standard) way : of being able to check this field without severely limiting the text : that can be put in here I suggested a way: sdbdkjvhfdb defines a tempo if there's a tempo definition in the environment, i.e. a line like Q:[3/4] sdbdkjvhfdb 1/4=96 : Any syntax that works in an external file can work in an ABC tune : file. : I don't think I understand what you're talking about here. Do you : mean that any external file that any program decides to use should : be capable of being put into an ABC file? I mean that if the external file syntax is sanely designed we can add the design to the syntax of ABC. As it stands, it seems that externality is being used as an excuse for using any old rubbish as notation - on the assumption that only one program will ever use it and hence that only one programmer needs to care how twisted it is. There are enough historical precedents now to say how dangerous an attitude that is in the long term. : What happens if you put a q: field into a tune and feed it to : abc2win? (If it breaks, there's no advantage over altering the : syntax for Q:). : And again, this illustrates the need for some sort of namespacing : to allow us to add features to the standard without breaking : backwards compatibility, and also to allow program specific : extensions. In future, yes, but for this specific case, if abc2win behaves as I'm guessing it might, there is *no* way forward without letting people create ABC files it can't handle. So we might as well redefine the existing field's syntax and save q: for something else later on. Once we get all commonly used programs doing the silent-acceptance thing, we can follow the line you're advocating. ] how does abc distinguish between `arbitrary gibberish' and music in ] general? The way it currently interprets the note A. The only way it can assign a duration to that is by looking up an L: field (or inferring one from an M: field) and the only way it can assign a definite pitch to it is by looking at the K: field. I'm suggesting tempo should be a matter for another environment lookup, but a nonlocal one to an extent that the standard already permits for M: and L:. It *might* be okay to relax things so that files didn't need to define all the tempi they use; that would not be portable, but it would be portable among display-only programs, and there aren't so many tempi in any one source that adding the definitions would be a great hassle for people using the same files for purposes like playback or the computation of overall timings. (I was talking about proposals for definitions of tempo by formalisms confined to external files...) ] Which has what syntax? ] field namecolontext ] examples: ] q:gayment ] q:allegro con moto That's not what I was I was asking for. That's *use*, I was talking about *definition*. How would you define allegro con moto in an external file? Why does doing so make the syntactic problem any easier? + in every printed score I own, the tempo text, expression
Re: [abcusers] tempo
Laurie wrote: I would like to propose the following. [suggestions I have hardly any problems with, except...] Q:C2=120 -- as before Do we really need this? Did it ever catch on? (I think you suggest deprecating it, I reckon something more drastic might be in order). Q:120=Allegro -- the popular example. Same idea Nothing else in ABC uses postfix definition, and it's pretty strange for most people to figure out and perhaps even stranger if you consider an audience of programmers instead of people... I guess you're doing it this way for easy parsing where the term might have spaces? I think I'd leave the = sign out if it's going to be in this order, or use =: or *something* to indicate that I'm not really trying to redefine the number 120. Your suggestions have exactly the expressive power I was asking for, with one minor omission: the label dotted minim = minim you get in staff notation when the metre changes. There seems to be nothing in your proposals that could trigger the printing of such a thing in the staff notation, even though the semantic effect is there. Can you see a way to fix this? Q:Allegro WITHOUT any previous setting of the beat has to be deprecated because it is as peculiar as the old Q:120 was We could be a bit more relaxed about this - a program that only needs to print could accept it. Anybody who put a tune like that on the web could then officially be told they'd be fielding emails saying what metronome speed did you have in mind? till hell freezes over, though... But basically I like this set of proposals and could live with it. - 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] tempo
Jack said ...Your suggestions have exactly the expressive power I was asking for, with one minor omission: the label dotted minim = minim you get in staff notation when the metre changes Q:1/2 -- sets the beat to minim abc abc Q:3/2 -- sets the beat to dotted minim which therefore equals the old minim (you mean 3/4) That's what I meant by saying you had the same semantics, but wouldn't that be difficult for a staff-notation generator to figure out? - the program has to look back some way to locate the RHS of the identity, and in the presence of variant repeats, the lookup would have to follow the dynamic order rather than the textual sequence even to discover whether anything needed to be printed at that point: M:2/2 Q:1/2 ... |: ... [1 [M:3/2] [Q:3/4]... :| [2 || % no metre or beat change ... [M:3/2][Q:3/4] % this *IS* a change of beat even though the % last beat assignment in the text is the same ... which is why I thought an explicit command might be easier to implement. (You could have even more fun by adding parts in different metres with a playing order in the header - there are examples of that in pibroch). If the implementors think it's not too hard, no problem. Heads-up for a special case that is going to appear eventually: someday we are going to have da capos, and if the DC is back to a different beat than the one currently in force, the change will have to be indicated at the DC mark, not at the start of the score (whereas these indications go above the first bar of the music with the new beat setting otherwise). === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: File-global header fields (R, M)
Hear, Hear! File-global header symbols are a minor convenience in that they save some typing if you have a large collection of say, 6/8 Jigs. They also make certain things possible to express that cannot be done reasonably any other way. I have beside me a book of Galician folksongs, Daniel Gonzalez's Asi Canta Galicia (1963). Most of the tempi are given in Italian, with no numerical equivalent. What speed is andantino as used by a Spanish folklorist in the Sixties? I've no idea; I could look it up, but why should I do so before I start transcribing? What speed is implied by aire de muineira, one of the non-Italian ones? Not a clue. But if I had redefinable file-global tempi I could still transcribe these pieces, knowing that I could *later* consult the New Grove or someone with specific knowledge and insert the correct definition. I have a bunch of files like this already, with tempi using the syntax I suggested. BarFly can't process them unless I comment the textual tempi out. But there is no way in hell I am going to post them on the web, ever, with my guess at the numerical values fixed per-tune; that would be utterly irresponsible stupidity, as bad as the abc2win tempo fuckup. Another example: ornamentation, as BarFly does it by macros. There are some ornament signs which are essentially style-dependent, and for that matter instrument-dependent. If you want to hear what a piece written for flute with trills might sound like on the harp, you had better redefine those trills to be no-ops, because the result would otherwise both be unplayable and sound hellacious. For the Highland pipes, there are tunes which have been played for 150 years or so with the ornaments getting steadily more complicated as players get more virtuosic. The natural way to write this in ABC is to have the ornament given as a macro defined at the start of the file or in an external file: that way you take a single tune and get 19th or 20th century versions of it just by changing one line. Editing pipe ornamentation in ABC is not easy, and any sort of abstraction mechanism will cut the workload by a substantial factor. It means you can't take a large collection and turn it into a ZIP archive, one member per tune, There are collections already that you can't do this with, simply because you won't have a clue how to use the music without the textual commentary provided by the file. Look at the George Skene pipe tunes on my website. Some are gibberish if you don't know their background. (I've had more emails about those than every other tune on my site put together; they're getting careful and informed attention by people who want to use them for real). or store an arbitrarily large collection of tunes in a relational database, etc., etc. Twaddle. Add a few extra fields to represent the values inherited from the environment and, to be on the safe side, another one identifying the file (or other environment) the tune was extracted from. It takes a certain amount of pre-processing to get that information (something you could write in Awk or Perl in an afternoon if you're halfway competent with either) but *storing* it is no problem at all for the relational model. In fact the relational model is specifically designed to avoid update anomalies of the sort I was talking about, and the reasoning behind my proposal is absolutely standard in data modelling. *Not* doing some such normalization in a relational design for a tune database would be laughable - what do you think higher normal forms are for? Is 1NF as far as you think? Do you even know the difference between a relational database and a personal computer address book? Adopting James' proposal represents a significant gain at a trivial cost. A simple one-pass conversion tool could be provided to read in any valid existing ABC file and spit out a copy, with all the global fields properly distributed to each individual tune which lacked them. Since it would only alter tunes lacking the global fields, such a tool is always safe to run, even on input already converted. It's safe except that it loses global redefinability, which is the point of using the more interesting global fields in the first place. There might be times when such a tool could be useful - e.g. when adapting well-structured ABC files to a crippled or legacy implementation - but for most purposes it would be better inside the ABC interpreter. (For macros, BarFly already provides this as a source-to-source utility, as well as an internal function). In these days of cut and paste, the saved typing convenience is inconsequential. If you've looked at any of the ABC I've written you should see instantly that typing convenience is *not* something I concern myself with. Some of that stuff must be among the slowest-entered ABC on the web. A fast 6/8 Jig should not become a slow 3/4 March just because you re-organize how you store your tunes. And *how* fast is a jig,
[abcusers] a partial solution to the tempo definition problem by macros
BarFly's macro mechanism provides part of what I need. I can define two separate macro files, each defining a q macro, one containing the line: m: q con moto = [Q:1/4=120] and the other: m: q con moto = ^Con Moto and then use the definition in a tune file like this: X:1 T:test M:C L:1/4 K:C q con moto cdec|] which when I get the program to expand macros, becomes X:1 T:test M:C L:1/4 K:C [Q:1/4=120] cdec|] for playback if I choose the first macro file or X:1 T:test M:C L:1/4 K:C ^Con Moto cdec|] for printing if I choose the second macro file. The problems with that are: - it's a hack - there's no syntax identifying the macros as tempo constructs - I can't put the required macros at the top of the file (I don't understand this, it works for other macros as in Phil's Goldberg Variations example) - they have to be in a separate file - there's nothing like a #include construct to link a file to the macros it needs - the linkage has to be done through application preferences - I can only use this in tune bodies since macros don't work in headers (not much of a problem for me, maybe would be for other people) - it would be much nicer if BarFly never printed numerical tempi in the first place; that way I could get away with just one macro file - I'd hate to ask anybody else to do it. But I'd *much* rather insist on people going through those hoops, and additionally restrict them to using software that can handle Barfly- style macros, than hardwire my interpretive guesses till the end of time. So, in the absence of any discernible progress, I think I'll just start doing it, and put a pair of suitable macro files on my website that you will have to use to make sense of anything I upload from now on. Note, this mechanism subsumes the suggestions made for constructs that would put the tempo indication in a distinctive typeface, because the quoted-string mechanisms of programs that allow multiple typefaces can be invoked by whatever I put on the RHS of a macro definition. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] what's the problem with the Tune Finder?
I haven't been able to connect to John Chambers' Tune Finder for a few days now. Demon said they were doing some maintenance on their US links but this seems too long an outage to be entirely their problem. Two things I'm looking for which ought to be out there: (1) a tune called The Old Polka, quite often played in Scotland, and (2) the simple Renaissance dance tune (frottola?) Schiarazula Marazula, in four parts, which I thought I had on paper but can't locate now I need it. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] what's the problem with the Tune Finder?
Two things I'm looking for which ought to be out there: (1) a tune called The Old Polka, quite often played in Scotland, and (2) the simple Renaissance dance tune (frottola?) Schiarazula Marazula, in four parts, which I thought I had on paper but can't locate now I need it. According to my own Musica Viva Sheet Music Search, you can find the Old Polka at La Taberna: http://www.navegalia.com/hosting/00071/niltoni/index.html Fortunately the TuneFinder came back up - that's a 1.7Mb zip archive on a slow site. There are two versions out there, of a tune I know, but both seem to be different from what I was looking for (a four- section tune). As for Schiarazula Marazula, I seriously doubt there's an ABC of that one on internet, but here's a quick transcription Thanks! There's less going on in the lower parts than I thought there was, but it'll still do fine for what I have in mind (as a first multi-part piece for a children's recorder group). === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] alchemical music
I've put the music from Michael Maier's Atalanta Fugiens (1617-18) on my website; it's more or less a song cycle on making the Philosopher's Stone, for three voices, based on a plainsong cantus firmus. In the reading of related material I've been doing lately, I came across what I believe to be the toughest copyright restriction in history, at the beginning of: http://www.esotericarchives.com/juratus/juratus.htm (It's for real; this tradition goes back as far as the work is traceable, though quite how it fits in with putting it on the web is not too clear). I was kinda tempted, but no I haven't insisted on anything like that. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: Tune finder, collections, header fields
There's another situation (already out there on the web) where getting a bunch of related tunes together matters but where they don't all come from the same book: when you want a set of tunes for a specific country dance. If you type Hamilton House into a search engine you might want the tune of that name, but you might also want an entire set for the corresponding dance. There is no unique source for such sets; different bands have different ones. There's no standard ABC field to put in the header saying which dance the tune is for, and even if there were it wouldn't help much, because some sequences of tunes work and others don't, you can't just put any tunes associated with the dance together in any order and expect to get a playable result. You are right, there is no satisfying solution for it and this is a shame. On the other hand it could simply and instantainously be done by implementing a DA: = dance field into the header. Since there is no such field, it cannot make any existing abc's outdated, and since it is not active, I belive it could be used from now on. In itself, this doesn't completely meet the requirement: the same tune may be used for many dances, and in a specific dance set it has to occur at a specific point in the sequence. So your DA: header field would need to point to multiple instances of sequences of tunes or (more concretely) multiple segments of files; this would need a rather complex syntax, and you can't expect a danceband arranger to think in terms of database schema design when typing up a few sets for new players. Surely it's better just to have a way of identifying dance sets in their own right and saying what individual tunes comprise them and in what order? - this is what the people who put a header like X:0 T:dance set title at the start of each set are doing. Doesn't existing software already complain on encountering an unknown header field more often than it does on encountering an instance of the zero-index no-tune-body convention? James Allwright wrote: : Sorry, this won't work. You can only have 1 character before the : colon, otherwise you are going to have lots of parsers complaining. This has surely *got* to be fixed, or ABC is going to keep on banging against that limit over and over again for years to come. The header namespace is too darn crowded. Comaptibility with existing software isn't a very serious consideration. Nearly every ABC tune you download off the web needs some sort of editing before you can use it the way you want to. How difficult can it be to just remove a header field your program doesn't understand? It only takes a few seconds and it'll take far longer than that to make any real use of the music. There's quite a bit of useful ABC out there that no currently supported program can use directly, and the proportion's going to keep growing. But you have to locate it before you can massage it, so tweaks that help the Tune Finder do its thing have to receive higher priority than compatibility with players and formatters. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] tempo
Whew! a lot of syntax... One extra thing you get in actual scores: multiple names for the same tempo, which in your notation might be Q:allegro=Tempo I so that Tempo I is defined by a double indirection, in your BNF QLine ::= Q: string = string This might also be useful in translating terms between different languages. I am not sure what your proposal does about leading and trailing spaces in tempo names. They mustn't make any difference, anyway - otherwise trying to spot why your tempo definition isn't being acted on could get impossibly difficult as these would all have different effects: Q:1/4=124=allegro Q:1/4=124=allegro Q:1/4=124 =allegro % from Hogwood's recording Q:1/4=124= allegro % from Hogwood's recording Q:1/4=124=allegro % from Hogwood's recording That is, the lines QLine ::= Q: speed = string QLine ::= Q: beat = speed = string need to use a definition of string that eliminates leading and trailing spaces. (You should still be able to surround the string with whitespace for readability). Otherwise, spot-on. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard
After several online discussions, I (and probably a few others) have implemented the rather trivial extension of allowing any string of digits, commas, hyphens and periods to label an ending. This means that endings like [1,3 and [1-3 work with a very few abc tools. It seems that this should be a rather trivial addition to most abc programs (though players would have a bigger problem of needing to actually understand the ending syntax in some minimal sense). Does it behave correctly in this case?... ... K:D ...(a)... |: ...(b)... [1,3 [K:D Minor] ...(c)... :| [2 ...(d)... || % no key change ...(e)... The key signature is two sharps for the (a), (b) and (d) music and one flat for the (c) and (e) sections. (I can easily imagine a piece actually having this structure, and if there isn't one already out there maybe I'll just write one...) Display-only programs sometimes need to simulate execution too. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard
| After several online discussions, I (and probably a few others) have | implemented the rather trivial extension of allowing any string of | digits, commas, hyphens and periods to label an ending. This means | that endings like [1,3 and [1-3 work with a very few abc tools. ... | | Does it behave correctly in this case?... |... |K:D |...(a)... ||: ...(b)... [1,3 [K:D Minor] ...(c)... :| | [2 ...(d)... || % no key change |...(e)... | | The key signature is two sharps for the (a), (b) and (d) music and | one flat for the (c) and (e) sections. (I can easily imagine a piece | actually having this structure, and if there isn't one already out | there maybe I'll just write one...) Well, what I'd say is that it doesn't much matter, because this is rather bad notation. If you were to stick it on stands in front of a bunch of musicians, some would play (e) in D major and others would play (d) in D minor. You can insult the musicians all you want, but that wouldn't get them to do it right. (Of course, it's still a bit odd to see abc notation on a music stand. ;-) The right way is to put an advisory key change at the start of (e) to make it clear to everyone (human and software) what the intended key is. Otherwise, you are asking for a disaster when that point in the music is reached. If the semantics is specified it *is* clear to the software. You could simply say my example was illegal and *require* such an advisory key signature, but your software would have to do exactly the same semantic analysis to decide that the advisory was needed. So that's no simplification at all for programmers. Standard music notation is a bit of an oxymoron, and subtleties like this are not understood in any consistent manner by musicians. Doesn't matter if the musician is using the output of a correctly implemented ABC-to-staff-notation generator. It'll put the right key signature in for section (e) and the user doesn't need to know how it got there. I'd also predict that, no matter what we might decide here, many of the folks who write abc software would probably not much notice, and would do whatever they damned well please. Or they'd not even consider the problem, and what the code does would be an accident. So, while it may be a Good Idea to say in the standard what happens in such cases, it wouldn't help all that much. The point of my raising it was to get people to consider the problem. I don't think there are any currently active developers as disconnected from this list as you're suggesting. What abc2ps does is just take things in order. The [K:Dminor] causes a D minor signature to appear thereafter, until there's another K field. This is correct if thereafter means the actual sequence of notes played, wrong if it means the sequence of characters in the file. In fact the description above wouldn't even work with the latter interpretation for a 1.6-standard [1 ... [2 ... repeat, if the key change was only on the first time. (I wonder if there are any players that would stay in D minor for the start of the repeat? Isn't that what the music says? ;-) Laurie went over the precise analogue of this for the case of tempo and beat constructs. The only difference is that key is something display programs can't ignore. Here is a real-life example (slightly reorganized from one in my modes tutorial): X:1 T:Sister Jean S:Catriona Macdonald M:6/8 L:1/8 Q:3/8=80 R:andante K:DDor D2E F2G|ABA G2F|E2C C2G|E3D2C|D2E F2G|ABA A2G| A2d d2c|d3 D3:| K:DMix A2B c2d|efe e2c|A2B c2G|E3 [1 C3 |A2B c2d|efe e2d|[K:D]f2d d2c|d3 A3:| [2 C2B|A2A F2D|A2A F2D| A2d d2c|d3 D3|] BarFly gets the staff notation for that wrong but plays it correctly: that is, the c's in the second-time repeat are printed sharp and played natural. Does abc2ps print a two-sharp signature for the last line too? Yes, it would be more conventional to just notate the above using accidentals, but in the context it came from there was a specific reason for using key/mode signatures instead. There's no excuse for this not being in abc after all these years. Not having its interaction with the rest of the notation properly specified so that it can be generally implemented seems a pretty good excuse to me. I imagine many implementors vaguely anticipated troubles along the lines of the those I've described, decided here be dragons, and put it off to such time as it might be unavoidable. But the difficulties aren't insurmountable. Unrolling repeats and header-controlled part order are source-to-source operations of the sort that any decent ABC editing toolkit ought to have; they don't require the implementors of player programs to understand PostScript or those of formatters to understand MIDI. This stuff should be common ground. If we're considering an open-source parser there's no excuse
Re: [abcusers] Sharps 'n flats
|| What the accidentals =3D, ^, _ mean? Are they absolute (e g _e means || e flat) or are they in relation to the key (e g =3De means e flat || in Bb major)? | They're absolute, just as in conventional music notation. Just out of curiosity, are there any musical traditions/styles that use a relative (or cumulative) approach? I've never seen any, but that doesn't mean they don't exist. It's quite common in early music for a sharp-turned-45-degrees sign to mean either a sharp or a naturalization of a flat. This seems somewhat related to the old question of the persistence of accidentals. Current conventional practice is that accidentals last to the next bar line, but there are several musical styles that use the only the one note rule. This is true for European music before 1600 or so, and also for much modern music (especially atonal). Looking up the first two atonal scores that came to hand, neither of them do this. Robert Crawford's Variations for Recorder and Piano uses the ordinary to-the-next-barline rule, and Schoenberg's Variations for Orchestra uses a third rule, every note gets an accidental on its first occurrence in a bar, and that accidental stays in force until there is a change in pitch (there are a lot of repeated notes in the score). I think Webern did the same, but can't find a score at the moment. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard
Something I've also implemented is the conventional |:: ... ::| notation that says three times through. Every now and then I see repeat signs with 4 dots in a line instead of 2, which are simply a different style of ordinary repeat. Do you have a reference to back up your assertion that |:: is conventional ? This is certainly a useful thing to have, but it would be good to be sure that we are using widely understood conventions rather than adopting someone's ad hoc solution. The other reservation I have about this notation is that it doesn't generalize very well to n times through. In music I've seen that uses this construct, it's represented by printing (3x) above the staff. A staff-notation generator could do whatever it liked with |:: ... ::|, but I suspect that most non-Scandiwegian users would be happier with some such explicit representation using honest-to-god numerals. Does any system of notation have a sign for repeat this bit as often as you feel like? The definitive use of that is in Terry Riley's In C, but it occurs implicitly in quite a few genres. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is: |:: ... ::|
there is no reason to reject ::| and :::| notation as far as I see. You go on to suggest a more powerful formalism, so one reason would be that we simply don't need it. [Simon's message rearranged...] Additive complementary constructs (intriguing to me) could be: :numeral| This looks good, but perhaps it would help to do the same as staff notation here: use paired bracketing signs. |numeral: ... :numeral| Where the numerals must match. With a construct like this you don't want people invoking it accidentally by a single miskeying; it might not be obvious you'd made a mistake and you could perpetrate persistent misinformation. How this gets displayed is up to the staff notation software and maybe the user. It could print |:: and ::| signs or (3x) above the staff depending on what the programmer likes, or the user might be given a choice. They mean the same, it's just a presentation issue. Maybe we could add some free choice constructs the same way: |2-: ... :2-| repeat at most once if you want |2+: ... :2+| repeat at least once No tearing hurry for that, I guess. :text| the text construct would allow to specify freely any text that gives information on the number of repeats. examples: :repeat this bit as often as you feel like| :3 times| :(3x)| :add one repeatation every time through| by chance existing programs may accept this 'text' like any other text in quotes, and only those who have such a feature implemented will recognize a 'text' within the repeat sign as being a special text for describing the number of repeatations. In extention to this clever playback programms eventually could filter through the :'text'| and search for numerals and even numbers in words and use these for playback. This sounds like a recipe for trouble: ... :repeated only on the 1930 recording| but probably not repeated 1930 times, as an over-helpful player program might conclude. As a final extention-extention :numeraltext| could be allowed where the numeral defines the number of repeats for playback and the 'text' is displayed. This may be usefull if the 'text' does *not* contain computer-readable information, and the transcriber wants to suggest that the section should be repeated by the playback program three or maybe nine times exemplarily. I much prefer this, it separates the bits computers and people are expected to understand. Text should rarely be needed: only the last of your examples is something a computer implementation would have real trouble with (in fact I've seen a program that played cumulative song tunes from a grammar rule specification some 20 years ago, but the notation it interpreted wasn't as general as ABC). Most often you'd want these textual instructions to be printed at the start of the repeated section, so they might be better placed there in the ABC as well. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is [1,3
The obvious problem for a player is that people can easily type all sorts of of malformed endings. For example: |: ... |1,3 ... :|4 ... :| There's no 2nd ending here. I'd probably say that there are at least two possible behaviors here: You could play it three times, skipping the missing 2nd pass. Or you could play it four times, with a null ending on the second pass. I'd suggest that if the listed endings don't form a proper 1..N progression, that the behavior is up to the implementer. I would suggest that interpreting it as a null ending should be in the spec as required behaviour. This is something I've often wanted with the existing repeat syntax but BarFly (at least) doesn't support it. It'd be particularly helpful for getting anacruses to add up when the tune shifts them between repeats (which is quite common). There is a problem with the way you've written that. The existing standard says there is NO extra repeat sign at the end, so it ought to have been |: ... |1,3 ... :|4 ... || The way you had it suggests you do the whole thing again once you get to the end of the 4th time. I have seen that kind of nested-repeat syntax used for real, but only in a manuscript by somebody who was desperate to save space. This is a mistake you find all over the net and it would be a great help if more programs produced warnings about it. It's an annoyance for sightreading: you see that repeat sign and briefly think back to where?, however often you've seen it before. I would much prefer it if there were some redundancy checking for this construct, by declaring the number of times at the start too. So your example would go |4: ... |1,3 ... :|4 ... || That would assist a program in correctness checking and it would warn the reader of the ABC source that something unusual was about to happen. There would be no obligation on display programs to print anything corresponding to the initial number. Also, I take it you mean to accept ... |[1,3 ... :|[4 ... and ... |... [1,3 ... :|... [4 ... as well? I never use the number-next-to-a-bar special case any more (the more general [n syntax is enough for me and it suits the kind of source layout I prefer). : I would like to add: :[1+3 : and :[13 Please NO. We might need those characters for something else one day (e.g. controlling the voice entries in rounds). : and a way of saying for example : [last time Good idea, but I don't think this is the same construct; usually it goes on the end of the *whole tune*, and strophic repeats are not represented in ABC (they'd need a nested-repeat syntax, as the tune might have internal repeats). It's a distinct topic. As this is a more emphatic, large-scale sort of variant repeat, how about this? [[^ ... % first time [[. ... % usual case [[$ ... % last time Any notation is going to be unfamiliar to most people but at least that's vaguely mnemonic to folks who've used Unix pattern matchers. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multiple Endings
I think it is reasonable to require |: at the start of a repeat section Not given the amount of ABC out there that doesn't have one. Like all of mine. And I am NOT interested in re-editing the whole damn lot to please simpleminded fussbudget implementations. : If we can have multiple alternate endings, why not multiple alternate : segments within a repeat, not necessarily at the end? This is common : in pipe music, and we have seen requests for it on this list. I suggest we hold off on this one and get the simpler extension fixed first (while bearing in mind that it might be added later and shouldn't be precluded). The historical reason why it's so common in pipe music is because of the format of pipe tune books. For a really big umpty-part tune, you needed to save space to get it all one page (see David Glen's collections of about 100 years ago for most of the examples; you can watch his typo- graphy getting increasingly desperate as he approaches the bottom of the page). Publishers less concerned about saving paper, as in most modern tune collections, make much less use of it. There is probably no point in going for it unless we can do an altogether more sophisticated structure. A very long time ago (years) I posted an example of what such a structure might do: the 9/8 march Heights of Dargai has the form ABAC DBDC, and I've seen that in a modern book (in two staff lines) as [1,2 A [1,3 B :| [3,4 D [2,4 C :| which was remarkably readable (unlike some of Glen's stunts). But the amount of structural analysis required to use such a feature is far beyond what most ABC coders do. It might get more use if we had editing tools that could identify common sections and create variant-repeat structures to make more compact notation, but as yet we don't. +| At present, when it encounters a repeat BarFly searches backwards for +| one of the following symbols: |:, ||, |], [|, a P: field, or the start +| of the tune. This seems to give the least problems, but it does mean +| that you can't use a double bar or thin/thick bar within a repeat. + Going back to || or [| isn't a very good idea. It's common practice + to use double bars to mark the major phrases within a section, and + they are (almost) never used as repeat boundaries. The code should go + back to |: or the start of the tune. We oughta state this in the ABC + standard docs. This would both answer the question, and make life + easier for implementers. ...if those implementers didn't actually care whether their software could handle existing ABC written years before they thought up this restriction. A futureproof way of allowing repeats to cross double bars would be to introduce a new kind of repeat-transparent double bar. This would print the same way as || does, but would tell player programs to search back past it for the start of the repeated section. That wouldn't break any existing ABC (*all* of which has the semantics Phil described insofar as the transcriber thought about it) but would allow transcribers to get the behaviour John wants for new material. A sign like |.| or |:| would do it. ? As a concrete suggestion for the multiple repeat syntax, how about: ?!4x!|: ...:| I already suggested a syntax for it: |4: ... :4| which has the advantage of not using ! signs (a complete no-no given the amount of ABC out there written for abc2win, which puts ! to a far more productive use that would be much better adopted by any new standard). It also has bracketing which humans or computers can use to check that the transcriber hasn't forgotten something. ? The idea being that 4x is attached to the immediately following start ? repeat by a printer program and detected as the repeat count by a player ? program. CHARACTERS IN ABC SOURCE DON'T NEED TO GET PRINTED IN STAFF NOTATION! As John Chambers says, a lot of users would rather have :: in the middle of the staff. Others might like 4x, 4 defa or whatever. Formatters can generate any of them no matter what the ABC notation looks like, so long as it's unambiguous, and a *good* formatter will give the user a choice. The focus needs to be on designing a notation to be intrinsically readable, helps avoid mistakes, and is easy to implement for whatever purpose ABC might be put to. ASCII-fying a particular style of staff notation isn't going to get there. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: Initial repeats
A somewhat trickier problem is that there's currently a fair amount of abc tunes that don't even use the initial repeat on second and later sections. Some users seems to think that :| is a fine way to start a repeated section. This is also what many printed sources do, e.g. Kerr's Merry Melodies (as popular as all other Scottish tunebooks put together and then some) and the Northumbrian Pipers' Tunebooks (later numbers of which were typeset with abc2mtex, but I haven't seen those). and I could have added that O'Neill's 1001 did the same thing (probably influenced by Kerr, the layout is generally similar). Which implies that pretty much everybody who's seen book versions of the material that forms the bulk of the ABC corpus will be used to repeats written the way I do it. I also checked the oldest piece of music paper I've got, a manuscript from 1816 that contains Scottish music and Mozart piano pieces, and the people who compiled that did it the same way, systematically all through. So Kerr didn't invent this. (To be more precise: the convention is that you use a double-sided or left repeat if it occurs in the middle of a line, but never at either end). I've had a look through my collections and the only ones I can find that ever use a begin-repeat sign at the start of a whole tune are Highland pipe music books. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Initial repeats
repeat signs are bars, I don't think so. At a quick glance, seven out of the first twelve tunes in the Northumbrian Piper's Tune Book have repeat symbols that don't coincide with bars. Okay, I guess both I and the 1.6 standard are wrong on that. For instance, I want to be able to do this - X:1 T:Brighton Camp I:abc2nwc M:4/4 L:1/8 K:G |:gf|e2dc B2A2|B2G2E2D2|G2G2GABc|d4B2gf| e2dc B2A2|B2G2E2G2|FG A2D2EF|G4G2:| |:dc|B2d2e2f2|g2dc BA G2|Bc d2e2f2|g4f2gf| e2dc B2A2|B2G2E2G2|FG A2D2EF|G4G2:| Leaving out the first |: would be no problem but I prefer to keep the second. Insisting that repeat symbols coincide with barlines produces something like - gf|:e2dc B2A2|B2G2E2D2|G2G2GABc|d4B2gf| e2dc B2A2|B2G2E2G2|FG A2D2EF|1G4G2gf:|2G4G2dc|] B2d2e2f2|g2dc BA G2|Bc d2e2f2|g4f2gf| e2dc B2A2|B2G2E2G2|FG A2D2EF|1G4G2dc:|2G4G2|] which is unnecessarily complicated and ambiguous about where the repeat of the second half starts. You're right about the unnecessary complication, but the convention in sources like Kerr's is absolutely clear. If ABC had a nested-repeat construction there would be an ambiguity, but that's years away. I just looked that tune up in O'Neill's 1001 (it's #972). There is a notational convention there that I really *don't* think we oughta emulate... read a dotted crotchet as a minim??? For this one, he did put a repeat at the start of the line (he does it different ways in different places in the same book). Kerr (v3, The Girl I Left Behind Me) puts the whole tune on one line with no initial repeat and a double-sided repeat in the middle, his usual practice for tunes short enough to fit. Does anybody's software support O'Neill's attitude to clefs and key signatures? - one per tune is enough. I think I've seen that in other Irish sources. I don't mind either way. I think I've seen other Irish stuff that dropped the clef at the start too: you assume treble, trusting that St Patrick drove the others out of Ireland. You can do wonders of compression with nested repeats. There is a sheet in Murdoch Henderson's manuscripts titled 64 Great Scottish Reels in A Major, and he gets them all on one side, one line each, 64 lines (the sheet is the size of a folded tabloid page). There's no hint in the manuscripts of why he wanted to do this in the first place. Must have taken him days. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Initial repeats
are nested repeats common in serious music? Serious not meaning classical, just that someone is seriously expected to read it The obvious example is strophic songs. The way these are often transcribed, they are a good case for an extended-repeat notation, because folklorists like to write down small variations in specific stanzas. But there's more to it than that since nearly all ballads have internal repeats within each stanza. As you might represent it with a nested repeat (here without stanza variation): X:1 T:The Outlandish Knight B:Northumbrian Minstrelsy M:6/8 L:1/8 K:Eb [|18:|: B |BcB efe|dBB B2 [1 B |BcB edc|B3- B2:| [2 G/A/|BCB AFD|E3- E2|]:18|] I suppose P: allows for much the same expressive power. Hmm...before even thinking about nested repeats, how about making segnos and codas work? Absolutely. But perhaps nail down the extended-repeat thing first? We seem to covered most of what's involved. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Initial repeats
My theory is that once upon a time, the repeat sign consisted of two dots (:), and always coincided with a bar line. An interesting theory, but I don't buy it because your symbol is symmetrical and so you can't tell the difference between a start repeat and a end repeat. Suppose your music has the form A |: B :| C |: D :| E you are now in big trouble if you can't tell the difference between a start repeat and an end repeat. Big trouble or not, you do find similar syntax in 18th century Scottish sources, both print (e.g. Aird) and manuscript. They often got by with only symmetric repeat signs. A section was repeated if you could find a repeat sign (or the start of the tune) at each end of it. Effectively the symmetric repeat was the normal double bar, with the simple double bar being a special case indicating *non*-repetition (which is the statistically efficient way to arrange things with that repertoire, since most sections do get repeated). There was a special left repeat sign only used in practice when you had a non-repeating upbeat at the very start. I tried being faithful to Aird's notation in the transcript on my site by using :: repeat signs at the ends of tunes. I think that crashed BarFly with a memory error every time and I didn't expect any other implementation to allow for such lunacy, so out it went. One 18th century layout which is genuinely useful is the ultra- compact tunebook format where tunes don't need to start on a new line (see Rogier's _Oude en Nieuwe Boerenlietjes en Contradansen_ for a well-done example). Lots of manuscripts use that, with a paper size rather larger than A5 in landscape format. This was meant to be pocket-sized for some sufficiently large value of pocket. In that format you need something much more dramatic than a thin-thick bar to mark the end of a tune, so they used a series of parallel vertical lines starting the height of the staff and tapering down to a dot, or in manuscript a damped-harmonic- motion or Bessel function curve with 3 to 6 oscillations. The feature that often went along with this in manuscripts that you possibly don't want abc2ps to support is filling the book from both ends at once, opposite ways up. This was very common and nobody now knows why. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Z for whole bar rests
Some time ago, the syntax Zn was suggested for n bars of rest. I know that abcm2ps now implements this, and I'd like to know: 1. What other programs implement this ? 2. Are there programs where this usage would create a conflict ? (I'm thinking of the reserved characters H-Z here). One slight problem is that we have other extensions of the rest idea: x for non-printing rests and y for horizontal space. BarFly started this but I think other programs use them too. X for a whole bar of non-printing rest could be almost as useful as your proposed Z, but it's something else to check for conflicts. (The way BarFly uses y and does note spacing, a Y for a bar of horizontal space wouldn't give well-defined output, but maybe some other program might have a use for it). So you could expect to have at least one and maybe two other letters to check for conflicts. I can't envisage any myself, though. Example of where you might want multiple-bar non-printing rests: I recently tried to represent a song where the verse was monophonic and the chorus was in three or four parts (a common parlour trick in 19th century Scotland). BarFly doesn't let you switch the number of voices in mid-tune, and I suspect it would be hard to add that functionality. You could do it by writing the verse music out multiple times, which is redundant. If you were merging the voices on to a single staff line, and you used ordinary rests, they'd print rests all over the melody. Non-printing rests are the way to go, and you wouldn't need to write as many of them if you had a multiple-bar non-printing-rest construct. That example is a place where we could do better if the ABC spec was better defined. In my intuition, a part boundary is one place where a change of voicing ought to be allowed. But the relationship between parts and voices is not pinned down anywhere that I know of. (There's one example I can think of where a composition has different numbers of parts in different voices - a string quartet by Elliott Carter, the fourth I think, with 6 movements for two of the instruments and 4 for the others - but stuff like that is too exotic to bother with). There should perhaps be an even larger-scale kind of rest, a way to silence an instrument for a whole part. This is routine in orchestral music. There's another way to represent the multiple-bar rests you want that has more general application: a length modifier that would allow you to extend any note or chord over multiple bars. Say [c/e/g/]5 for 5 bars of c triads half the default notelength long, with being the do this for a whole bar sign. Then z8 for 8 bars of rest is just another special case. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
RE: [abcusers] Shared tunes
Here is another question. A friend asked me last night whether I knew of a site where she could search for tunes by author - rather than by title. I don't - have only searched by title myself. Does anyone out there know of one? You're in luck if the composer you're after is Ed Reavy, G.S. MacLennan or Thomas Morley. Anybody else... The problem is that very few people put the composer's name in the ABC when encoding a tune, so it isn't yet worth anybody's while putting this in search engine code. What would help: if search engines, when returning tunes, could also search for other copies of the tune (identifying them just by name to start with, anything else is too hard) that have a C: line, and tell you about it (sometimes you would get false matches, the results would need human discrimination to interpret). You have an interesting problem with names. There are tunes out there attributed in the score to GS McLennan G.S. McLennan G.S. MacLennan P.-M. G.S. McLennan George S. Mac Lennan George Stewart McLennan Pipe-Major George S. McLennan, The Gordon Highlanders and that's without getting into the Gaelic ways you can spell it. How many of him are there? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] attachements to the lists.
Please do not send attachments to the lists. It slams the mailserver. Slows down delivery of mail to all users and lists served by the machine. I don't want to have to set up a filter to bounce all mail with attachements. Thanks! and that goes *particularly* for Taral's PGP bumf. MIDI or PS files, while perhaps better transmitted in another way, often make useful points in a discussion; crypto signatures contribute absolutely nothing except clutter and annoyance. Hs anybody here ever run a PGP verifier over Taral's sig to authenticate one of his or her messages? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] char
There's another way to represent the multiple-bar rests you want that has more general application: a length modifier that would allow you to extend any note or chord over multiple bars. Say [c/e/g/]5 for 5 bars of c triads half the default notelength long, with being the do this for a whole bar sign. Is the characted implemented as above in standard ABC? I couldn't find it in the standards documentation. It seems to be quite useful... No it isn't. I suggested it on the principle that if we're going to use up yet another character we'd better get as much use out of it as possible, and this construct does far more than the proposed Z while taking up the same amount of lexical lebensraum. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] speed of mailings archives
I've been watching how the speed of the discussion on this list has picked up since I put the new fast mailserver in place. I dunno about the speed (given how slow my machines are I could hardly tell) but having a real honest-to-god From line at last is a *huge* relief. I am currently working on putting the entire archive of postings for the list from the past few years online and indexing the postings with Thunderstone search. I know some folks on here are sensitive about having their email addresses visible on the internet. I could avoid that by password protecting the archive(s). If the list members think that is a good solution, or have a better solution, let me know. Thanks! A better solution would be to edit out the email addresses and replace them by names or handles so the archive ends up looking like a typical web discussion board (e.g. Mudcat). I don't mind who sees the content of what I've written so long as it doesn't lead to even more spam than I'm getting now. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
| You can try to get ABC convenient, readable, close to some staff | notation or what ever you wan't. But first of all you must keep (or | get) it to contain unique (well formed or well defined if you want) | information. Well, now; I'm not sure I'd agree with that. Granted, I'd like to see such a computerized notation, and I suspect that both the lilypond and MusicML people are making good progress toward such a goal. But I don't think that we should push ABC in this direction. ABC's niche that led to its success is that it's a relatively simple, basic, plain-text notation that is compact and mailable. It doesn't require a sophisticated UI; it can be typed (and read) by mere humans. None of this would be true of any notation that is well formed and well defined. Predicate calculus is simpler than ABC and as well formed and well defined as anybody could want. It's sloppy, ill-defined notations that need fancy user interfaces. As far as I can see (from examples Laura has sent me) lilypond is nowhere near in the same league of precision as ABC - it's a random grab-bag of typesetting hacks. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Music request
I just got an e mail from a Musica Viva visitor asking for Croatian traditional music for flute. Is anybody here able to help? Does this person have a specific piece in mind? I don't think so. As I understand it, he's an American of Croatian origin who wanted to learn something about his ancestry. He probably don't know of a single Croatian tune at the moment. I have a thumping great book of Croatian tunes but I'm hardly going to start typing the whole lot in to meet this request... To explain what I've got: the book is Vinko Zganec, _Narodne Popijevke Hrvatskog Zagorja_ (1950). It's an ultra-scholarly collection of song tunes with a few instrumental pieces at the end. Everything is classified up the wazoo, which is probably why Francis Collinson had it - it came from his collection, it's an autographed copy. Collinson was an obsessional classifier; the book even has his own personal library catalogue number pencilled in. The classificatory annotations are way beyond ABC, but have textual equivalents. The music often uses compound rhythms with bars broken into subunits, but otherwise there isn't anything wildly complicated about it, except that some of the instrumental pieces use single-line percussion staves with up/down noteheads to distinguish the hands (an extension I proposed to ABC years ago, which doesn't seem all that complex either for a player or a formatter, but which no implementor has yet gone for). I just did one, but I can't email it except as an attachment; it's a simple dance tune with an optional text. There are two Croatian letters; no problem using ASCII equivalents there. The problem is in the underlay. It has an isolated letter k which goes *in between* two notes - it would be assimilated in speech. The only way I could see to represent that was by using a Macintosh non-breaking space (character $CA) to glue it on to the following word. BarFly processes that okay and the score it generates looks just like it should, but ASCII has no such character and hence, as far as I know (I haven't used w: much) ABC has no such functionality. Nor, as far as I know, does email portably encode a nonbreaking space, so I'm pretty well snookered. I can't be arsed linking a single tune unrelated to anything else into my website. If anybody wants this, given that attachments in this list are out, contact me and I'll pass it on with a GIF and some sound files to point out the problem. (I should perhaps add that my total knowledge of Croatian is a few isolated words and the phrases I love you and fuck your mother - I'm having to guess what features might be important in transcription). If anybody tries doing songs in Russian they're going to hit the same snag with knobs on. An isolated v assimilated to the following word occurs in almost every nontrivial Russian text. If I was in the Croatian-American flute player's position I'd try to pick the tunes up by ear off recordings anyway. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New Software Development
I'm in a software engineering course this semester, and we've decided we'd like to go at adding another product to realm of available 'abc' tools. [...] Right now, the idea is based mostly on writing new file format which will implement the current standard of ABC. We want to write our program to implement fully, and not expand at all on or deviate at all from the specifications of the current standard. However, we wish to develop a new file format which will contain standard abc notation _plus_ layout information generated by our program. Speculatively, we would call it something like abl (abc with layout), but we've not gone far as of yet to discover what registered existing filetypes are out there. Why do you need any new format? ABC already has comment lines, and some programs use special-purpose comment lines like BarFly's %%Bfly lines to encode application-specific data. So why not just put your extra stuff in %%ABL lines scattered through the source? - that way your files will just be standard ABC files and any ABC application will be able to use them. The effect of adopting a new format would be to limit the use of your software. To some extent this already happens: Muse uses a similar approach to the one you're suggesting, and nobody uses Muse files as an interchange medium - if the Muse-specific information had been done via comment lines, other ABC users would be able to use Muse files as is, and pehaps transmit them onwards to other Muse users. BarFly has a similar problem: certain information can be encoded in resource forks, but as that's totally Mac-specific, nobody ever uses it in a publicly available ABC file, and there is no easy way for it to be transmitted from one Mac user to another via a non-Mac system. (The only thing I ever do with it is drop my files onto the Res Fork Killer utility to get rid of it). We anticipate using a base 16bit unicode file format Why? The only benefit I can see from that would be in extending ABC to cover non-ASCII character sets, which would be no bad thing but methinks would need to be done with a bit more consultation. (Also, it doesn't make a lot of sense to allow for Arabic or Devanagari script when ABC isn't yet capable of encoding Arabic or Indian music). A final point. One of the core advantages of ABC is concision. People who use ASCII-based file formats don't like bloat. If your software leads to people being emailed things as pointlessly humungous as Microsoft Word files or Outlook-generated HTML-tagged text when a few K of plaintext would do, you're not going to make any more friends than Microsoft have done. So you need to keep extra layout data to the bare minimum, and extract as much formatting information as possible from the ABC itself - e.g. instead of encoding stem direction for each note individually, use a heuristic to cover most cases with necessary exceptions marked locally. BarFly's stemming heuristic (which doesn't let you do anything about the exceptions :-( ) is correct about 95% of the time, so such a policy could cut the amount of stem-direction data you need to store by a factor of 20. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] mystery Breton tune
Anybody know anything about this tune? (I already asked this on uk.music.folk, no answer). I got it as a graphics file off the Internet years ago and have been playing it ever since, but have come across it recently in two different contexts - a Canadian fiddler I know plays it, and the first half is similar to the opening of the 19th century Welsh hymn tune Alexander. So I'd like to know more about it; the Breton title would be a start. X:1 T:Breton tune N:octave shifts ad lib N:tempo unknown, seems to work at any speed M:2/4 L:1/16 K:E Minor E2B2 B2AB|c2B2 AGFG|A2A2 B2A2|GFEF G2F2| E2B2 B2AB|c2B2 AGFG|A2A2 B2A2|GFEF E4 :| E2E2 F2GF|E2E2 FEFG|A2A2 B2A2|GFEF G2F2| E2E2 F2GF|E2E2 FEFG|A2A2 B2A2|GFEF E4 :| === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: Folkband
King of the Fairies English?! I thought it was Irish, but it's a variant of an older tune, Gilderoy, which is first documented from Scotland but could equally well be English. Hold on, Jack! Last time we had this folkband discussion, you said that *Red-haired boy* was the same tune as Gilderoy! Gilderoy gets around... there's probably no other tune in the British Isles with so many descendants. Gilderoy *means* red haired boy. Its origins are pretty mystifying. The original text is in English, but written in a style that exactly mirrors a Gaelic lament genre used for other MacGregors (the McGregors specialized in very long and very vague poems in an archaic mediaeval manner). But the tune has no older Gaelic parallel. So it looks like whoever put it together was an impressively skilled bilingual scholar. There are no other examples I can think of where Gaelic content has crossed over into English or Scots folksong - generally if a Gaelic tune gets used for a Scots song, the Scots text has no relation at all to the Gaelic. - 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] another mystery tune, Norwegian this time
This one is the signature tune of the Edinburgh Shetland Fiddlers They think it's Norwegian but nobody can remember where they got it from Ideas? X:1 T:The Hoy Song Z:Jack Campin 2002 S:Edinburgh Shetland Fiddlers M:2/4 L:1/16 Q:1/4=128 K:A % or do we play it in G? I can't remember e2ee e2ee|e2ee f2e2|c2cc c2cc| c2cc d2c2 | B2B2 A2A2|G2G2 F2F2|E2d2 c2B2|[1 A2G2 F2E2:|\ [2 A4 z4 || E4 E2A2|c4 ^HOY!!z4 |c4 d2c2| B4 z4 | B2B2 A2A2|G2G2 F2F2|E2d2 c2B2|[1 A2G2 F2E2:|\ [2 A4 z4 |] The HOY!! is shouted in unison (After the astonishing background to what I'd assumed was a simple social dance tune or peasant ballad with that Breton number, I await the revelations) === http://wwwpurrdemoncouk/jack/ === To subscribe/unsubscribe, point your browser to: http://wwwtullochgormcom/listshtml
Re: [abcusers] RE : mystery Breton tune
This tune is really great !! It's one of my favorite in the celtic area We play it with my folk band You can find a cover of it by the famous breton band Tri Yann They called it Kerfank 1870 As usual there's a web page about it once you know what to look for: http://wwwbzhcom/keltia/galleg/musique/bretagne/tri-yann/kerfankhtm Follow the Conlie link for the history It's a remarkable story I knew nothing at all about (The French state has been using its colonial and minority peoples as cannon fodder in the same way ever since, of course) I looked up what Marx might have had to say about it (in The Civil War in France); he doesn't seem to have noticed it at all, only mentioning that some Breton forces (presumably a faction of the survivors) were absorbed into an early and ineffectual army raised to put down the Commune It must have been well covered up at the time Can you translate the Breton words in the song? === http://wwwpurrdemoncouk/jack/ === To subscribe/unsubscribe, point your browser to: http://wwwtullochgormcom/listshtml
Re: [abcusers] Fonts.
Anyone have the skinny on available fonts and licensing issues involved in
distributing those fonts? If there's a plethora, do you have a favorite,
and why is it your favorite
I guess more importantly, since I assume most of the fonts are a 'lookup
assignment table' type system, if possible, we'd like to use a font that
a) gives a good clean overall screen and print appearance especially when
a user resizes layout, b) contains tons of symbols to satisfy any musical
whim, c) is available and somewhat similar in font-metrics across
platforms { mac, pc, X }
TeX is cross-platform, sort of, and has all the symbols you want You
can also get its fonts in TrueType and PostScript versions, and I *think*
you can get most of what you want for free, at least if you're prepared
to do some conversion work Have a rummage round a TeX archive site
Your problems are (a) TeX has an idiosyncratic scheme for accessing
fonts which no other application can make use of, and (b) the standard
TeX text font, Computer Modern, is an etiolated abortion that nobody
in their right mind would want to use if they weren't stuck with TeX
and which appears to be the result of a conspiracy by headache-pill
manufacturers
I think it would be better to adopt one font for the symbols (music
encoded in ABC doesn't need a great number of them) and let users
assign other fonts to specific roles in the score themselves (title
font, composer font, text annotation font) A user who is trying
to embed scores generated by your software into other documents, or
match an existing house style for publication, will need the ability
to control these
If you must make a choice or set a default
My favourite variable-width serif text font is Palatino I arrived at
that choice by experiment: my vision is not particularly good, has been
deteriorating for years, and this was during a bad patch I printed a
pageful of the same text at the same size in every font I could find,
seeing which one was readable from the greatest distance Palatino
won by a big margin, with Computer Modern far at the bottom by an even
bigger one Bodoni, Garamond and Caslon would probably rate pretty
well too, I couldn't test them at the time
I haven't done the same experiment as thoroughly with other kinds of
font, but get the impression Gill Sans would beat any other sans-serif
proportional font at the same test I generally use Courier for fixed-
width but I'm sure there must be something better out there
=== http://wwwpurrdemoncouk/jack/ ===
To subscribe/unsubscribe, point your browser to: http://wwwtullochgormcom/listshtml
