Re: [abcusers] Recommendations for graphical entry software
You may have a try with MusiCAD 3.0 beta. It uses abc as its 'second language' for import/export and adheres (more or less) to the 2.0 draft spec. see http://www.musicad.com for more info and download. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc for Pocket PC
From: Derek Bone [EMAIL PROTECTED] Sent: Monday, September 08, 2003 11:19 PM Subject: RE: [abcusers] abc for Pocket PC I've subscribed to the abc user list, but I don't know how to contribute Please could you tell me how to ask a question of the other users ? Youve' just done so ;-) Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] decorations 2.18
Regarding the whole bunch of decorations it seems more or less logical to explicitly divide them into a few groups. 1) +trill+ real 'decoration' commands 2) +upbow+ instrument specific commands 3) +1+ fingering commands 4) +D.S.+ playing order commands 5) +fff+ change of something (volume, whatever) 6) +(+ combined with +)+ start/end commands 7) +/+ notehead commands (percussion!) changing the appearance of the note-head Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: backslashes
- Original Message - From: Phil Taylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 2:02 AM Subject: Re: [abcusers] Re: backslashes Jack Campin wrote: 1. continued lines cannot have a trailing comment 2. pseudocomments cannot be continued The current text of ABC 2.0 does not allow either. Ad. 1: Comments can not be included on lines that end with a backslash. That would make it impossible to comment out a block of text without editing it first, since many other kinds of line might end with backslashes. And then you'd have to remember where the backslashes used to be when undoing the commenting-out. I hadn't thought of that. Commenting out part of an abc tune by placing % at the beginning of each line is a useful debugging technique. Anyway, I think we've moved on from that position, and the developing standard now allows 1. (or am I confused?) Commenting-out could well introduce pseudo-pseudo-comments. I doubt we can do anything about that. What about % I:ignored field ignored-abcline %%ignored-pseudo-comment % or something similar. Seems as harmless as useful... Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Floating voices
From: Wil Macaulay To: [EMAIL PROTECTED] Sent: Friday, August 01, 2003 4:59 PM Subject: Re: [abcusers] Floating voices Given Bernard's statement, and that we are proposing incompatibilities anyway, I would propose that you only use a line if you _DO_ want barlines between staves. In other words, the default is not to join staves, but you can put a line between if you want barlines. Seems fine to me Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Stick to established notation conventions
From: I. Oppenheim [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 10:22 PM Subject: Re: [abcusers] ABC Standard 2.0 revision III On Tue, 29 Jul 2003, Arent Storm wrote: For the church-modes part I agree, the explicit accidental signature will confuse anyone trying to play the music from paper (except for the authors band perhaps) Klezmer musicians all use explicit key sigs I' think that observation is 'wishfull' thinking. Some do, some(most?) don't (including me) and even more don't bother as they don't play from paper... and so do musicologists. The fact that you *can* bend music-notation-conventions at will (you can very easily when notating by hand) doesn't mean that you *should*, just to accommodate each need as it arises. You will do the intended audience more of a favor when you stick to established conventions with respect to notation. Compare musicology with fonology. While fonologists can read eachothers notations, mere human beings mostly won't. The same will hold for musicologists. I think of abc as a languge for musicians, not a language made for musicologists leaving most of the musicians in the dark when using obscure features. Musicians are lucky because the written language they use is legible all over the world (because of the notation conventions) In fact, it are only clasically trained musicians that excludes me for sure that get confused from this notation, I'm getting confused every time... because they do not understand how non-western scales are structured. I know, but still get confused and make unneccesary mistakes on encounting explicit key sigs But don't get me wrong, the arising abc-standard is a nice thing (it should of course refrain from weird things like exlicit key-sigs) ;-) Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] N-times repeats
From: John Chambers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 12:38 AM Subject: [abcusers] N-times repeats I. Oppenheim writes: | I've now also updated the ties and slurs section of | http://www.joods.nl/~chazzanut/abc/abc2-draft.html | to give PNG examples of nested slurs. | Please have a look to see if you can agree. It's getting to look better and better. One thing I noticed missing: The repeat section doesn't mention the N-times-through notation like |:: ... ::| % Play this three times. |::: ... :::| % Play this four times. I've implemented this in jcabc2ps, and used it in a few tunes. I've found that, although musicians will say that they've never seen this the first time I saw it was in abc... they invariably know exactly what it means. after some explaining I guess ;-) Of course, when a phrase is played three or more times, you usually do have different endings. This is why many people haven't seen this notation. But it can be very handy when you're just writing a basic version of a tune, and you note that one phrase really is played four times. The upcoming standard is not yet explicit in allowing/disallowing variant ending out of a P-part notation (which is missing begin repeats) Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC Standard 2.0 revision III
From: Bernard Hill [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 10:43 AM Subject: Re: [abcusers] ABC Standard 2.0 revision III In message [EMAIL PROTECTED], John Walsh [EMAIL PROTECTED] writes Correction: in Irish music, a roll is a specific way of playing several repeated notes, not a general ornament on a given note. It's basic to the music, which is why it's part of abc. I'm not at all surprised rolls aren't in the standard notation texts. Matter of fact, I'd be surprised if they were. Then I suggest the term roll in the standard be changed to Irish Roll or otherwise commented on in a footnote. In normal music a roll means something quite different. hear hear! BTW, what's normal music ? ;-) I implemented a roll as a tremolo (and it sounded good!) by just working from the standard. You *have* to make your standards document intelligible by normal musicians if you want the abc standard to be taken up by a wider musical community than that represented here. I second that! Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] ABC20-draft review
Irwin, * I think it would be wise to explicitely reserve the use of nonmentioned letters E, Y lowercase letters. for future extension and urge implementors who need more to use %%packagename-fieldname instead Move ''exended information fields'' paragraph to front, just after the normal ones * irregular compound meter: two ways of display 1) 3+2+2/8 displayed as is 2) (3+2+2)/8 displayed as 7/8 *G: group; clarify (I still don't get its definition) or explicit allow any useage... *H:is (the only?) field that can contimue on the next line without repeat of the H: ? *K: field move all the mode stuff, pipers stuff etc. to an appendix. allow mode= signature= and depricate previous use of keysigs mode fields etc. *w: to appendix * Tune-fields: rename to use of fields within body, explicit note which fields may be used in-tune. * ~ I always thought that ~ is used for a prall-trill by default. Hardly anybody will know what an Irish-roll is (is it eatable?) *chordsymbols (rather than accompaniment chords). Note that programs will regard anything written between double quotes, notn starting with one of the special characters as a chord. (there quite a few chord notations out there... being not compatible at all; so leave it to the interpreteing program to do whatever it sees fit best.) That done, just discard any not agreed on examples of chords ( C C# G7 Bbm Ebm7) would do IMO, but as this will reraise previous discussions make a statement like 'programs should treat chord symbols quite liberately' * clefs: Is K: Am transpose=-2 illegal where K: Am treble transpose=-2 is not ''clef'' starts the specication (I'd rather like to see clef=clefname than clef alone there are not many abc tunes in the wild using other clefs than treble yet) The K: syntax is complicated enough already) Allow for more than ''the 7'' keys (clef=clefname will do so) *voices state that all voices to be mentioned in the abc-body have to be declared in the header when using the [V:ID] syntax, where each ID will be referenced over and over. *special characters Reserve some unicode encoding scheme for future enhancements (forward compatibility) So characters like copyright signs, trademark or whatever may be used in the (near) future: proposal: \$UnicodeSymbolName; Current (ABC2) implementations should just ignore it, replace with some other sign or simply ignore it (but should parse the syntax) for the time being and implement it in version 3 or so. (please deprecate the archaic and insufficient octal seqences!!!) *reserved characters Try to make clear where/why which characters is reserved. Even better: reserve characters in a specialized context. - global - within body - within header - within textstrings - within w: and/or W: lines reserved syntax would be a nice thing to have. Knowing which generic syntax might be used in the future will render software useable for a longer time. *stylesheets The draft suggests that %%staves is likely to be moved to a stylesheet. So a stylesheet gets firmly boud to a specific abc-tune. I think that's a bad idea. The way CSS-sheets are usually used is that multiple HTML files reference the CSS for layout purposes. The %%staves example do not fit in at all. Fonts, papersizes, spacing do also %text, %%vskip, %%newpage etc certainly do not. Programs should provide a list of stylesheet defaults (so the need arises for a complete current list of ABC2-directives) *special characters: why use = for a macron and/or stroke through - or _ is more logical The oe ligature is missing (fine to me as there is a readable workaround for it). It would violate the rules to allow \oe but on the other hand e-ring is not used anywhere (is it?) z-circumflex is not available in latin-extended-A (especially not as it typesetted here ;-) My 2 (or 3) cents Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] ABC Standard 2.0 revision III - review
* I think it would be wise to explicitely reserve the use of nonmentioned letters E, Y lowercase letters. Move ''exended information fields'' paragraph to front, just after the normal ones * irregular compound meter: two ways of display 1) 3+2+2/8 displayed as is 2) (3+2+2)/8 displayed as 7/8 *G: group; clarify (I still don't get its definition) or explicit allow any useage... *H:is (the only?) field that can contimue on the next line without repeat of the H: ? *K: field move all the mode stuff, pipers stuff etc. to an appendix. allow mode= signature= and depricate previous use of keysigs mode fields etc. *w: to appendix * Tune-fields: rename to Use of fields within body, explicit note which fields may be used in-tune. * ~ I always thought that ~ is used for a prall-trill by default. Hardly anybody will know what an Irish-roll is (is it eatable?) *chordsymbols (rather than accompaniment chords). Note that programs will regard anything written between double quotes, notn starting with one of the special characters as a chord. (there quite a few chord notations out there... being not compatible at all; so leave it to the interpreteing program to do whatever it sees fit best.) That done, just discard any not agreed on examples of chords ( C C# G7 Bbm Ebm7) would do IMO, But as this will reraise previous discussions make a statement like 'programs should treat chord symbols quite liberately' * clefs: Is K: Am transpose=-2 illegal where K: Am treble transpose=-2 is not? since clefname starts the specication (I'd rather like to see clef=clefname than clef alone there are not many abc tunes in the wild using other clefs than treble yet so... The K: syntax is complicated enough already) Allow for more than ''the 7'' keys (clef=clefname will do so) will ensure forward compatibility easy parsing *voices state that all voices to be mentioned in the abc-body have to be declared in the header when using the [V:ID] syntax, where each ID will be referenced over and over. *special characters Reserve some unicode encoding scheme for future enhancements (forward compatibility) So characters like copyright signs, trademark or whatever may be used in the (near) future: proposal: \$UnicodeSymbolName; Current (ABC2) implementations should just ignore it, replace with some other sign or simply ignore it (but should parse the syntax) for the time being and implement it in version 3 or so. (please deprecate the archaic and insufficient octal seqences!!!) *reserved characters Try to make clear where/why which characters is reserved. Even better: reserve characters in a specialized context. - global - within body - within header - within textstrings - within w: and/or W: lines reserved syntax would be a nice thing to have. Knowing which generic syntax might be used in the future will render software useable for a longer time. *stylesheets The draft suggests that %%staves is likely to be moved to a stylesheet. So a stylesheet gets firmly boud to a specific abc-tune. I think that's a *bad* idea. The way CSS-sheets are usually used is that multiple HTML files reference the CSS for layout purposes. The %%staves example does not fit in that way at all. Fonts, papersizes, spacing do. %%text, %%vskip, %%newpage etc certainly do not. Programs should provide a list of stylesheet defaults (so the need arises for a complete current list of ABC2-directives) *special characters: why use = for a macron and/or stroke through - or _ is more logical The oe ligature is missing (fine to me as there is a readable workaround for it). It would violate the rules to allow \oe but on the other hand e-ring is not used anywhere (is it?) z-circumflex is not available in latin-extended-A (especially not as it typesetted here ;-) My 2 (or 3) cents Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC20-draft review
From: Phil Taylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 4:27 PM Subject: Re: [abcusers] ABC20-draft review Arent Storm wrote: * ~ I always thought that ~ is used for a prall-trill by default. Hardly anybody will know what an Irish-roll is (is it eatable?) I'll bet there are at least a hundred times as many abc users who know what an Irish Roll is as there are those who recognise what a prall-trill is. Actually, I think the English word for it is Pralltriller, but most people would call it an upper mordent, and in abc it's normally represented by the letter P. I have seen lots of ~ but rarely seen any P Most musicians will know the ~ sign but most will call it by different names; I see the ~ sign as the most common embellishment-sign in any (folk)music I've seen The meaning of ~ is context-dependent. In classical music it will mean a turn (that's what the symbol looks like), and in most places a turn symbol in the staff notation will be correct. What kind of twiddle gets played depends on the tradition that the music comes from. Agree * clefs: Is K: Am transpose=-2 illegal where K: Am treble transpose=-2 is not No. transpose (or t=) is a directive which affects only playing and has nothing to do with clefs, so both are legal. I meant illegal in the sense of the draft spec. ''clef'' starts the specication (I'd rather like to see clef=clefname than clef alone Why? The clef names treble, alto, tenor and bass are all unique identifiers which can't mean anything but a clef, so clef= is redundant. More complicated clef specifications should use the clef= syntax though. It makes the use of the K: field for at least anything other than key more readable / parseable / orthogonal *voices state that all voices to be mentioned in the abc-body have to be declared in the header when using the [V:ID] syntax, where each ID will be referenced over and over. It's good practice, but I don't see why it should be mandatory. To enable software to flag possible typo's when you have header V:First V:Second V:Third body [V:Fisrt] someoabcline2 [V:Second]someabcline3 [V:Third]someabcline What should a program do on encounter of [V:Fisrt] with or without the header. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC20-draft review
From: Ray Davies [EMAIL PROTECTED]
From: Jon Freeman [EMAIL PROTECTED]
From: Arent Storm [EMAIL PROTECTED]
Hardly anybody will know what an Irish-roll is (is it eatable?)
Is there even such thing? In Krassen's version of O'Neils,
I find mention of a long roll and a short roll in Irish fiddle playing.
He also comments that
his notation is only appropriate for fiddle and that players of other
instruments may have to modify it. It seems to me that the situation is a
lot more complicated than just one universal Irish roll.
Agreed.
My main concern is the name it seems to get.
As far as I know, ornamentation signs are heavily used
in two main areas:
- Baroque/Classical/Romantical periods in Classicalmusic
- Folk music from all over the world.
There's more (folk)music than that from the British isles,
so capturing a particular ornamentation sign to named
'Irish roll' makes it difficult.
It comes in handy as terminology remains context free.
- trill, prall, turn and mordent are used commonly names for
the 4 most common ornaments for many instruments:
trill ( tr )
prall ( ~ shaped thing )
mordent ( slashed ~ )
turn: ( 8 shaped thing (rotated 90deg ))
All 4 ornments come in lots of variations, most not having
a context free name.
- uppermordent and lowermordent is googled only in abc-context
so I would stop using the term
It's equivalent to a 'turn' ,
The note above the main note;
The main note;
The note below the main note;
The main note.
{B}A{G}A
A long roll has the main note played before the turn. A{B}A{G}A
But the constraints of any particular instrument and personal taste cause it
to be modified a lot.
Ray
To subscribe/unsubscribe, point your browser to:
http://www.tullochgorm.com/lists.html
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] %%staves
From: I. Oppenheim [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 30, 2003 6:11 PM
Subject: Re: [abcusers] %%staves
Dear Phil,
%%staves {1 2 3 4}
Will typeset 4 voices on one keyboard staff.
A keyboard staff consists of two coupled staves
that are connected with a { symbol in front of them.
I'd expect {(V1 V2)(V3 V4)} or something similar.
And what if I want one large { with four staves ?
%%staves (1 2)(3 4)
Will print two separate staves, with two voices on each of them.
No { symbol will appear in front of the staves.
===
%%staves {1} a keyboard staff with only one voice in the right hand.
%%staves {1 2} a keyboard staff with one voice in the right hand
and one voice in the left hand.
%%staves {1 2 3} a keyboard staff with two voices in the right hand
and one voice in the left hand.
%%staves {1 2 3 4} a keyboard staff with two voices in both hands.
Some (organ music) uses 3 staves...
It seems to me that the use of {} here is both redundant and
ambiguous.
I hope it is now clear.
I'm afraid that there are a few open ends here,
especially when taking the grand-staff as one keyboard-staff
(where abc will regard it as two)
Arent
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC Standard 2.0 revision III
From: Phil Taylor [EMAIL PROTECTED] Also I don't like the idea of %%MIDI nobarlines because it means something totally at odds with what it says. Bar lines have nothing to do with midi - the midi standard provides no way of representing them because they are a purely visual feature of printed music If you want to specify that accidentals are non-persistent you should not use %%midi becuase the implication is that a program which plays abc directly without using midi can ignore it. Seconded Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] %%staves
From: I. Oppenheim [EMAIL PROTECTED]
On Wed, 30 Jul 2003, Arent Storm wrote:
And what if I want one large { with four staves ?
You could use %%staves [1 2 3 4] instead,
which will place a [ before the staves, though.
We can of course consider to make the semantics of {..}
similar to [...].
Why not; seems perfectly logical to me.
I.e: %%staves {1 2 3 4} will print 4 staves with
a { before, while %%staves {(1 2) (3 4)} gives two
staves with two voices each.
Would that be a good suggestion?
Much better.
Arent
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abcm2ps and 'extras'
From: [EMAIL PROTECTED]
T:Plain 2/4
M:2/4
L:1/8
K:perc
%%graceslurs no
V:1 up
c|:7c{c}c {c}cc-|7c{c}c {c}cc-|7c{c}c {c}c/Lc/c/c/|\
[1.2.3. {c}c{c}c {c}cc-:|[2 {c}c{c}c {c}c{c}c||
The result ps looks surprisingly good, with the exception
of the slashes on the stems that I want to indicate a roll.
The note should look like this (pardon the ASCII art):
|
|
|/
/|/
/|
|
|
000|
0
0
000
This is the perception of a *roll* I am used to ;-)
I'd suggest that you use a few of the redefinable symbols
(you wont use mordents and the like in percussion do you?)
U: ~ = +roll1+
U: T = +roll2+
U: M = +roll3+
for 1 2 and 3 slashes through. These won't interfere with
the use of / as division.
Within the interpreteing program, drawing one or more slashes
trough a notestick is very similar as drawing a symbol near it.
BTW, I think that these symbols ar to be within the new standard
Every notation for mandoline and thelike needs them also.
Arent
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC Standard 2.0 revision III
From: I. Oppenheim [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 1:34 PM Subject: Re: [abcusers] ABC Standard 2.0 revision III They are non standard in Western music, but you will find something like [K:D _b _e ^f] often in e.g. Klezmer (Ahavoh Rabboh) or Arabic music (Maqam Hedjaz). My first thing will always be to remove any non standard explicit accidentals, replacing them with inline accidentals and inform the player textwise that he/she is playing an unusual mode/key. Anyway lots of klezmer tunes change mode/key every few bars so the need for non-classical is rather limited IMO. The mode/key/accidental stuff is way too complicated for the average folk player (in the Netherlands anyway - wer'e not so smart you know ;-) Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC Standard 2.0 revision III
- Original Message - From: John Chambers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 3:24 PM Subject: Re: [abcusers] ABC Standard 2.0 revision III Bernard Hill writes: While it is indeed common practice to omit begin-repeat symbols, this is not a nice thing to do to your readers. I've often found myself hunting for the beginning of a repeat, and thinking Why couldn't the f***ing idiots who did this take the half-second extra to mark the beginning of the repeat with a fat bar and two dots? In my experience, this produces more disasters during rehearsals (and sometimes during inadequately-rehearsed performances) than all other bad notation practices combined. If I had my druthers, I'd put a rule in saying that beginnings of repeated sections *must* be marked properly. *Hear hear !* But of course that's dreaming yet another impossible dream. sigh Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC Standard 2.0 revision III
On Tue, Jul 29, 2003 at 08:42:32PM +0200, Arent Storm wrote: They are non standard in Western music, but you will find something like [K:D _b _e ^f] often in e.g. Klezmer (Ahavoh Rabboh) or Arabic music (Maqam Hedjaz). My first thing will always be to remove any non standard explicit accidentals, replacing them with inline accidentals and inform the player textwise that he/she is playing an unusual mode/key. Anyway lots of klezmer tunes change mode/key every few bars so the need for non-classical is rather limited IMO. The mode/key/accidental stuff is way too complicated for the average folk player (in the Netherlands anyway - wer'e not so smart you know ;-) I remember when I first heard mention that modes could be introduced into the ABC key signature (or maybe it was when I discovered they had been. I don't remember it *that* well). I felt the same about that. Complicated, academic, abstract, who on earth needs it ? But I had a poke around with it, one rainy Sunday afternoon, just to see what happened. And I discovered, to my suprise, that it worked better than what I knew. It was a better description. I could get the key signature I wanted _and_ say what the tonic was, both in one move. I felt (more or less) the same for the modes part. But they fit in with the regular (classical) key-notation, so I decided to signal the mode-part in MusiCAD (textwise) as I expect very few of my users to dig into the abc and discover the key to be D-dorian instead of C Which *is* musically relevant but *isn't* notationally relevant. So it became worthwhile to understand them; and now, years later, I can even remember whether I mean dorian or mixolydian without having to look them up, though I don't use the others so much. If there are people who use ABC, or are considering using ABC, for music where non-standard signatures are less non-standard, they might make the same discovery. For the church-modes part I agree, the explicit accidental signature will confuse anyone trying to play the music from paper (except for the authors band perhaps) Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] voice properties
- Original Message - From: John Chambers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, July 26, 2003 6:40 PM Subject: Re: [abcusers] voice properties Arent Storm writes: | From: I. Oppenheim [EMAIL PROTECTED] | T1 in V:T1 is just an identifier that will make the ABC | source code more readable. | | As you know the name of the voice and other options | need to be spelled out only once, so having readable | identifiers throughout a big piece of ABC source code | is a big plus. | *NO* its not a plus; it's a minus | I'm not convinced at all. | The three different voicing methods are more than enough. | Stick with ciphering convention please! Another repeat topic! The abc2ps clones accept alphanumeric voice identifiers, but I don't know if anything else does. One funny aspect to this is that abc2ps doesn't actually need them, while probably other abc programs do. In particular, those that implement the proposed standard will. The reason is that, once you get beyond a few voices, it's a really good idea to be able to label them. You don't want to waste a big chunk of the left edge of the page for full part names, so the usual convention is that on all staff systems but the first, you use an abbreviation. Of course you need to label them (in abc and on paper, not nessecarily the same) my objection is within the use of the V-field. Now, abc2ps (and clones) has a way of doing this. You can define a voice as: V: 5 name=Bb Clarinet II sname=Cl.II thus 5 is the (internal) label, Bb clarinet the main text to be displayed with voice number 5, and Cl.II the name within a (larger) score before any line. Perfectly allright. The short name will be used after the first time. But I noticed that the proposed standard doesn't have the sname term, and there doesn't appear to be any other way to write this abbreviation. So how could we do it? it's called subname or snm... (in the proposed standard) but sname is as good/bad as subname Well, if you don't have sname, you could conceivably have an option that displays the voice's identifier. So you would write: V: Cl_II name=Bb Clarinet II Now, if the program showed the name the first time and the identifier thereafter, you'd get the conventional scores for orchestra/band music. And even better: You'd also see the abbreviations in the abc. This would be a huge help in getting the abc right. And get another level of possible mistakes. you may not spot the difference between Cl_I and Cl_l immediately but any program will and misbehave. So. If you object to alphanumeric voice identifiers, you should say how you propose to tell the software to label the parts of a score after the first system. The full name is NOT acceptable to anyone. agree A numeric part number is even worse. don't agree We could include the sname term in the standard. This would work, but has the minor problem of giving parts meaningless names in the abc. Or we can insist that alphanumeric voice identifiers be legal, and an option be provided to display them after the first staff system. This would be slightly better than the way that abc2ps does it. We could allow both, of course. The problem then would be that half the abc tools would implement only one, and when you got a score from someone, half the time you'd have to laboriously edit it to follow the other convention. That's somewhat the situation now, since many abc tools only implement numeric voice identifiers. as did I Personally, despite being a long-time abc2ps user, I'd be happy to discard the sname term and convert my (few) uses of voices to use the voice's abbreviation as its identifier. But we'd want to make sure that the conventional abbreviations can be used. Cl_II is ok, but the usual notation would be Cl.II. It would be nice if we could get such abbreviations printed in the music. display use and internal use (for whatever reason) should not be mixed up. I would want to write KL2 instead of Cl.II Also, a nice thing for vocalists would be to allow: V:S V:A V:T clef=tenor V:B clef=bass You can't get much more intuitive and user-friendly than that. The current proposed standard does in fact make this legal, and the abc2ps clones all implement it now. I'd think that this example by itself is sufficient grounds to want nonnumeric voice labels. V:1 V:2 V:3 clef=tenor V:4 clef=bass isn't that much of a difference (but has far fewer implementation headaches) Nonetheless V:1 name=Soprano subname=S V:2 name=Alto subname=A V:3 name=Tenor subname=T clef=tenor V:4 name=Bass subname=B clef=bass would be more complete and to the point Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Anyone used u:?
On Fri, 25 Jul 2003, Bernard Hill wrote: Hello, as you know, Irwin Oppenheim and I are trying to put together a proposal for ABC 2 standard. I have a simple question: has anybody actually seen the u: (lowercase u) field in ABC files? We are considering whether leaving it out. Suggestions are highly appreciated. Later, Guido =8-) You're going to have to remind us what u: does, I can find no mention of it... from the 1.7.6 draft: $ As a short cut to writing accents or other symbols which avoids the !symbol! $ syntax (see Accent above), the letters H-Z and h-w and the symbol ~ can be $ assigned with the U: and u: fields (the U: defines how the symbols are $ printed and the u: defines how they are played). Later, Guido =8-) I haven't made use of it (and I guess I won't) ;-) I can't find any abc-file that uses it. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] asterisks (and obelisks :-)
I have quite a few danish tunes fron at least 1999 disabling abc-'linebreaks' this way and end with a double ** What's the use of ** X:2 T:Tellings hopsa S:Hans Ole R:Hopsa O:Denmark M:2/4 L:1/8 K:D D | B2 c/B/^A/B/ | G2D2 | B2 c/B/^A/B/ |ed cB |\ A2B/A/^G/A/ | F2D2 | A2B/A/^G/A/| fe dc |\ B2c/B/^A/B/ | G2D2 | B2c/B/^A/B/ | ed cB |\ A2B/A/^G/A/ | f3 e | dc BA | G2 z ::\ K:D A|fA fA | aA fA | gA eA | fA dA | \ fA fA | aA fA | gA Bc | d2 z::\ K:G d3 e | d2B2 | b2 ag | f2 z2 |\ c3d | c2A2 | fe dc | B3z |\ d3e | d2B2 | e3f | e2c2 | f3f | (3fed (3cBA |\ G2 [B2g2]:|** X:3 T:Klaphopsa S:HO R:Hopsa O:Denmark M:4/4 K:A a2e2 a2e2 | dcdf ecA2 | a2e2 a2e2 | dcdBA2z2 ::\ Acec Acec | d2f2 f4 | eaga bagf | e2a2a4 |\ Acec Acec | d2f2 f4 | eagf edcB | A2A2 A2z2 :|** Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] voice properties
The current draft standard for multiple voices states: V: fields can contain voice specifiers such as name, clef, and so on. For example, V:T1 name=Tenor I clef=treble-8 indicates that voice `T1' will be drawn on a staff labelled Tenor I, using the treble clef with a small `8' underneath. Player programs will transpose the notes by one octave. Possible voice definitions include: name=voice name The voice name is printed on the left of the first staff only. The character `\n' produces a newline. subname=voice subname The voice subname is printed on the left of all staves but the first one. up/down Forces the note stem direction. clef= Specifies a clef; see section Clefs for details. The name specifier may be abbreviated to nm=. The subname specifier may be abbreviated to snm=. I see a few unnessacary inconsistencies omissions in it: 1) where does T1 come from 2) I expect all options of the form: option=value so up/down should be stem=[up|down] draw=[merge|hide|cuesize|preserved] to accomodate hidden voices, cuesize 3) the abbreviations do not contribute much 4) program v n is unclear to me; program=# channel=# bank=# would be much more readable and expandable) missing features: transpose=-2 (to note that clarinet is not playing the same as a flute) defaults to 0 stafflines=1 (accomodate gregorian chant and percussion) defaults to 5 instrument=clarinet (make clear which instrument should play) (not nessecarily the same as name=clarinet) so: V:1 name=Tenor I subname=T1 clef=treble-8 transpose=-2 V:1 draw=hide draw=cuesize program=71 channel=5 instrument=clarinet when using the whole bunch of options. Any program can safely ignore any options it does not handle but I think it's wise to define now how such a feature may be used in future. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] informationfield extension
I'd like to catch the use the the Y: field for future extensions like Y:someinfofield=some info field value This way we've maintained compitiblity with existing abc files while having the possibilty of future expansion. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] informationfield extension
- Original Message - From: I. Oppenheim [EMAIL PROTECTED] To: ABCusers [EMAIL PROTECTED] Sent: Friday, July 25, 2003 9:14 PM Subject: Re: [abcusers] informationfield extension On Fri, 25 Jul 2003, Arent Storm wrote: I'd like to catch the use the the Y: field for future extensions like Y:someinfofield=some info field value This way we've maintained compitiblity with existing abc files while having the possibilty of future expansion. Standard says already: Many of these field identifiers are currently unused, so programs that comply with this standard should ignore the occurrence of information fields not defined here. This will make it possible to extend the number of information fields in the future. I think you didn't got the point. I was trying to reserve Y not for one specific extension but to allow for new things to come Y: CD=BHA10051 Y: Accelerando=10 Y: Allegro=100 or whatever makes sense at some point in the future. Almost any other acb-field is been (mis)used for various things, so make Y: kind of 'reserved' (as wel as E and J) Thus to instruct new software to handle Y: to parse yet unknown tune-generic parameters just as V: does for a voice within a tune Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: About the choice of '!'
From: Bert Van Vreckem [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 25, 2003 11:18 PM Subject: Re: [abcusers] Re: About the choice of '!' Phil Taylor wrote: Changing abcm2ps to use *...* instead of !...! (it accepts ! for a linebreak already) would be a matter of minutes work for Jef. Changing ABC2Win is not possible. Changing all of the existing files which use !...! to use *...* is just a matter of search and replace; there are not many of them and we know where they are. Changing the existing ABC2Win files is not possible because there are many thousands of them and they're everywhere. It's the only logical way. I use the !decoration! syntax in my tunes. If the rest of you would finally agree to use *decoration* instead, I am more than willing to replace all instances in my collection. It's just as Phil says: since abc2win isn't supported anymore, we can't change it. !decoration! is more recent and I really think that most abc tunes on the web that use it are still maintained. Adapting it really shouldn't be a probem. Come on guys, let's get this over with finally! * has a few problems too but, less intervening than ! so I second the vote for *...* instead of !...! Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] voice properties
From: I. Oppenheim [EMAIL PROTECTED] To: ABCusers [EMAIL PROTECTED] Sent: Friday, July 25, 2003 9:12 PM Subject: Re: [abcusers] voice properties On Fri, 25 Jul 2003, Arent Storm wrote: 1) where does T1 come from T1 in V:T1 is just an identifier that will make the ABC source code more readable. As you know the name of the voice and other options need to be spelled out only once, so having readable identifiers throughout a big piece of ABC source code is a big plus. *NO* its not a plus; it's a minus I'm not convinced at all. The three different voicing methods are more than enough. Stick with ciphering convention please! 2) I expect all options of the form: option=value so up/down should be stem=[up|down] Agreed. draw=[merge|hide|cuesize|preserved] to accomodate hidden voices, cuesize These things should be done with %% directives. why set merge at V: lines and other related things in %% be as consequent as possible. 3) the abbreviations do not contribute much Well, ABC users are lazy :-) and incomprehenseable 4) program v n is unclear to me; program=# channel=# bank=# would be much more readable and expandable) Will come back on this later. transpose=-2 (to note that clarinet is not playing the same as a flute) defaults to 0 Will add. stafflines=1 (accomodate gregorian chant and percussion) defaults to 5 Will come back on this later. Most important thing is to keep the syntax clean expandable without compromising existing software. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] expandable information field
From: Jack Campin [EMAIL PROTECTED] To: ABC Users [EMAIL PROTECTED] Sent: Saturday, July 26, 2003 12:58 AM Subject: [abcusers] expandable information field I'd like to catch the use the the Y: field for future extensions like Y:someinfofield=some info field value This way we've maintained compitiblity with existing abc files while having the possibilty of future expansion. Perhaps Phil (as the person whose program has the strangest parser) is probably in the best position to answer this, but it occurred to me a while ago that maybe we don't need a whole new letter for such uses. Would it be feasible to allow multi-character header fields so long as they were introduced by a leading :? Wouldn't that break use of existing software? X:1 T:Thingummy's Reel M:C| :DanceInstructions: RSCDS Book 137, 2042 K:A ... That only needs one-character lookahead, which I think was what Phil was concerned about? I can imagine the trouble that it will give... (I'm going to be away for a week, OS 1:5 sheet 48 302241, a mile off the nearest road with no modem). Enjoy! Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
- Original Message - From: John Chambers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 24, 2003 1:22 AM Subject: Re: [abcusers] multivoice linecontinuation Arent Storm writes: | Someone else wrote: | I used to use it and stopped because I always let the software | determine the line breaks for me. But if I were still expecting to | determine my own line breaks, I might still be doing it that way. | | It was the original syntax, wasn't it ? It worked before the inline | field [M:...] syntax was introduced, so there may be a lot of older | tunes out there that have it. | There *may* be, but are there? | I haven't seen any... It's hard to find. I searched around through my collection, including a lot of abc taken from assorted mailing lists, and I had trouble finding more that a handful of files with M: or K: inside the music, either in the clumsy old form or bracketed. Even in classical music, such changes aren't common. It's much more common to just keep the same meter or key, and draw bar lines or accidentals as you need them. People seem to dislike changing such settings unless the change is for a big chunk of the music. So we're talking about what is a somewhat rare usage. Not much abc will have to change if we change the software's behavior for continuation lines in this case. Of course, if you're one of the very few people who do this sort of thing a lot, you might be a bit annoyed ... I was guessing so too, especially where most abc-tunes seem to be rather simple short (as by nature history of abc) Thanks for searching Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
- Original Message - From: Phil Taylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 6:21 PM Subject: Re: [abcusers] multivoice linecontinuation Arent Storm wrote: Where it comes to to line continuation in multivoice and/or in-line lyrics things can get (unneccessarily) complicated. IMO line continuation should be allowed only for single voice. For instance, the nicely text-layed-out multivoice canzonetta.abc from the 2.0 standard would become unreadable with line continuation used. Yes, I'm inclined to agree. The only exception should be where there is some limitation on line length (e.g. the tune is going to be emailed), then continuation should only be used to continue on the following line. I'd much prefer the ! for those (rare?) cases that you'd want to override the algoritmical linebreaks, and forget about linecontinuation at all, but I'm afraid that I'll be standing on many toes... Also, when using abc to store complex scores, I think that human readablity is of very small importance, if at all; it will be uncomprehensable anyway. Not all multivoice scores are impossible to read. Jack Campin has some beautifully-constructed abcs of tunes in two or three voices. Not impossible, but in general there will be very little need for it, I guess that sight-readers of ABC will haveno need for it, so it'll be more otr less pointless to try. The 3 different approaches of writing down multivoice I dislike. I would very much prefer one approach the: voice by voice Sight readers will be thus allowed to read their part as easy as they're used to. V1: abc|abc|abc|abc def|def|def:| V2: Abc|Abc|Abc|Abc Def|Def|Def:| over [V1]:abc|abc|abc|abc| [V2]:Abc|Abc|Abc|Abc| [V1]:def|def|def:| [V2]:Def|Def|Def:| Would there be abc-sight-reading conductors? and (least) V1: abc|abc|abc|abc| V2: Abc|Abc|Abc|Abc| V1: def|def|def:| V2: Def|Def|Def:| compatible but useless IMO I'd prefer them in the order 2,3,1. The first is what MusiCAD is exporting, while importing all three. As said before - in multivoice scores - human readability won't have to be/should not be/cannot be a major issue. BarFly won't be able to display the output from MusiCAD, then. Why not give your users the option of all three? If MusiCAD prints music it must know where the line ends should come, so options 2 and 3 should be possible. Its not impossible, only requires a major rewrite of the abc-writing module I'll be (trying) to comply to the upcoming standard though, but as long as option 1 actually is in the standard I'm complying already... Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
From: I. Oppenheim [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 6:36 PM Subject: Re: [abcusers] multivoice linecontinuation On Tue, 22 Jul 2003, Phil Taylor wrote: Yes, I'm inclined to agree. The only exception should be where there is some limitation on line length (e.g. the tune is going to be emailed), then continuation should only be used to continue on the following line. I would prefer it STRONGLY that the end-of-line backspace would always mean: continue on the next physical line of music. YES However it seems that there is legacy code around that expects these lines: % variant A G2G2A4 | (FEF) D (A2G) G|\ M:4/4 K:C c2c2(B2c2) | to be interpreted as equivalent to: % variant B G2G2A4 | (FEF) D (A2G) G| [M:4/4] [K:C] c2c2(B2c2) | So I would like to know from you all, if any of you would have serious problems if from now on, backward compatibility with variant A would be discontinued in favour of a simpler continuation mechanism. Hmmm... Let's please forget about the headaching variant A % variant 2 [V1]:abc|abc|abc|abc| [V2]:Abc|Abc|Abc|Abc| [V1]:def|def|def:| [V2]:Def|Def|Def:| I'd prefer them in the order 2,3,1. I also prefer variant 2. Anyone who strongly disagrees? I must note, however, that it should be [V:1] and not [V1]: ! Ooops (of course) Groeten, Insgelijks ;-) Irwin Oppenheim Atent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
From: Laura Conrad [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 6:52 PM Subject: Re: [abcusers] multivoice linecontinuation Irwin == I Oppenheim [EMAIL PROTECTED] writes: Irwin % variant A Irwin G2G2A4 | (FEF) D (A2G) G|\ Irwin M:4/4 Irwin K:C Irwin c2c2(B2c2) | I think this is actually an example of a recommended syntax in some pretty widespread documentation. (Probably something that comes with abcMIDI or abc2ps.) So you can deprecate it, but you aren't going to be able to not handle it, if you want to deal with what's out there. Is it used often? Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
- Original Message - From: Jack Campin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 1:41 AM Subject: Re: [abcusers] multivoice linecontinuation As said before - in multivoice scores - human readability won't have to be/should not be/cannot be a major issue. Why bother with ABC at all, then? Look at the Atalanta Fugiens scores on my webpage. The way I have laid them out, anybody - including a blind person - can read them vertically and figure out the harmony at every point. Or this (needs a window with 96 columns, fixed-width font): X:5 T:Meine Seel' erhebt den Herren S:Bach/Riemenschneider #358 C:J.S. Bach M:C L:1/4 V:1 V:2 V:3 bass V:4 bass K:GMin V:1 d2 f2 |d d d d |e2d2 |c2c2 |HB4 | V:2 G2 F2 |F ^F G A |G F2 G |G2F2 |HF4 | V:3 B,2 C2 |D C B, A,|B, C2B,|B,2 A,2|HD4 | V:4 G,2 A,2|B, A, G,^F,|G, A, B, G,|E, C, F,2|HB,,4| % V:1 d2 f2 |c c c G |B2A2 |HG4 | V:2 F4 |F F E G |G2 ^F2 |HD4 | V:3 B,4|A, C C C |D3 C |HB,4 | V:4 B,2 D,2|F, A, G, E,|D, C, D,2 |HG,,4| % V:1 d2 f2 |d d d d |e2d2 |c2c2 |HB4 | V:2 G2 A2 |F3 ^F |G A B2- |B B B A|HF4 | V:3 B,2 C2 |D C D2|D C B, F |G2F C|HD4 | V:4 G,2 F,2|B, C B, A,|B, C F, D,|E, C, F,2|HB,,4| % V:1 d2 f2 |c c c c |c2G A|B2 A2 | G4-|G4- |G4 |H G4 |] V:2 z4 |F G A B |c2C2 |D2 D C |=B, D G F |E4- |E2 D C |H D4 |] V:3 z2 F, G,|A, B, C2- |C D =E ^F|G2=F E | D =B, C D-|D G, C2- |C2 =B, A,|H=B,4 |] V:4 B,, C, D, E,|F,3 G,|A, B, C2 |B,, C, D, E,| F,2 E, D,|C, D, E, F,|G,4 |H G,,4|] (Note, this is deliberately *not* designed for good staff notation output - I've put each line of the chorale as a separate system in the ABC source, the last one would be denser than the first three). I guess I'm to use a non proportional font to benefit optimally... ;-) If you can't make your ABC source human-readable you shouldn't be using it. If all you want is staff notation, Finale or Sibelius will do it better. At some expense... It's the other uses of ABC that make it unique, and most of those uses depend on readability. I'm just using abc as 'second language' enabling my users to use already written abc, and to provide the abc-community with the MusiCAD user groups files http://muzamus.dse.nl (dutch) Aremt To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] About the choice of '!'
From: Jean-Francois Moine [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 10:10 PM Subject: Re: [abcusers] About the choice of '!' On Mon, 21 Jul 2003 13:08:29 +0200 (CEST), Guido Gonzato [EMAIL PROTECTED] wrote: [snip] BTW - Jean-François, how do you tell whether '!' is a line break or the start of a decoration? When encountering a '!', I scan forward. If I find any of |[:] (and soon a blank or tab), or the end of line, it is a line break. Else, if I find a '!', it is a decoration. This means that a decoration name cannot contain any of these characters (for instance, '!da Capo!' or '![rit]!' will not work, while '!crescendo(!' is OK). Does this solve all the problems? Sounds fine to me. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] linebreaks and paper sizes
From: Jack Campin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 1:38 AM Subject: [abcusers] linebreaks and paper sizes BarFly makes ignoring linebreaks an option (except for multi-voice music where it isn't practical); what I do sometimes is first let the program have a go at doing the layout, then optimize the result by putting explicit linebreaks in better places myself. BarFly's spacing algorithm is not very sophisticated (monospace type printed on elastic), but the same approach would be handy for any program. As I see music engraving, you should care about linebreak/pagebreak just before you start printing. You never know the paper size beforehand do you? I do. It's always A4, either portrait or landscape. Which implies in fact two sizes; if it will fit on landscape it won't fit an portrait (unless you use a square portion of it)... Much of my users seem to like to have marching-band sized paper (something like 15 x 10cm) landscape. For the tunes on my CD-ROMs, the GIF scores (generated by BarFly) are intended for practical use by folk instrumentalists who operate the way I see them working in Scotland: everybody (beginners to pro ceilidh bands) uses A4 folders with clear plastic pouches. The music in them is usually portrait layout, be it printed, xeroxed or hand- written. So I design for that use; my users will print the tunes themselves as needed and arrange them in whatever categories they want. (Epicycle: I try not to use the full height of A4, so American users can fit my stuff onto their letter size without rescaling; I presume they use the plastic pouches too). For the flute CD-ROM, I did every tune in both portrait and landscape; that stuff is significantly more complex than the Embro, Embro or Aird tunes, and often landscape layout works better. Harder to use on a stand, but I was expecting people to use the scores for memorization rather than in performance. In many cases (and increasingly as LCD screens become more prevalent) people will simply learn the tunes off the computer screen (maybe aided by sound files) and never print them. There are so many advantages to this format that hopefully I've just killed the printed-and-bound tune anthology. But what I really want is singing digital paper. or even hornpiping papers (all of them slightly out of tune...) Wouldn't that be great ;-) Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: continuations
From: Phil Taylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 2:59 AM Subject: Re: [abcusers] Re: continuations John Chambers wrote: Another fringe case is what happens when a line ends with '\', a space, and a newline. It's common for many implementations to not recognize this as a continuation. This one is really baffling to a user, who usually can't see the space. The right way to handle this is to strip off the trailing spaces (and tabs), and then check for the final '\'. The input routine is now not quite as trivial (though it's still pretty trivial). BarFly does that (at least for spaces - I'm not sure about other whitespaces). Another thing that's a problem is % comments following the backslash. That's more complicated to deal with, and I'd like to see it illegal. I'd second that! Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New standard(s)
From: Bernard Hill [EMAIL PROTECTED] not to speak of hemisemidemiquavers It's actually hemidemisemiquavers. But my Australian customers explicly told me they use hdsqs. And 1/128th notes are semihemidemisemiquavers You must be kidding! Ludicrous! Why? I admit that there is logic to the US terms, but I have to think carefully how many flags has a 1/32nd note? whereas I know a demisemiquaver has 3. Most musicians can translate though I must admit I cannot, then you have never read a British or Australian book on music I take it. I think that most books which are seeking for a large audience use quarter, eight etc. instead of the more antique semihemidemisemiquavers ore whatever. I am aware that there exists something like semihemidemisemiquavers but I'm quite sure that there are few dutch musicians who know to use them, unless you read a lot of UK-english books on that topic. I do have quite some books on the topic of music engraving but apparently non of them is using semihemidemisemiquavers. :-) nor can I make much sense of miles, fl.oz, Fahrenheit, gallons, and all those other outlandish measurements you guys have mantioned. I need a calculator most of the times, but is cannot transform semihemidemisemiquavers ;-) However personally I prefer the US terms in that area. It's not something specifically American; the fraction designations for note lengths are used and understood throughout the world, save for the United Kingdom, it seems. I can't speak for the world, but in the Netherlands: anyway. No, as I say it's also Australasia. In fact if you add up the countries or inhabitants it's probably more use the British terms. I know they do in many places in Europe, and I certainly have Dutch customers who use them when writing to me. Funny, they have been extraordinarily well been music-educated It's not something you encounter every day in the Netherlands And I didn't say we don't understand them. We are broad-minded enough to read US books and dictionaries and program notes etc. Here in continental Europe, we have Euros, kilometers, liters, celsius, and 1/128th notes, and we do not understand anything more exotic than that... Of course you do. don't be too sure... Fahrenheit isn't understood by most dutch since apart from the notion that it has something to do with temperature, and that 100F is different from 100C... You know about dollars and pounds for exchange rates. dollar=euro pound=??? (lookup somewhere) The French even have livres = pounds (weight). And I have read French technical articles on chemical engineering which refer to pouce = inch. From which century? The French started the SI system... To be honest, in Holland we used to have an ''ons'' for 100g en ''pond voor 500g but they are officially abandoned since a few decades, and fit in with the metric system. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
- Original Message - From: Richard Robinson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 5:05 PM Subject: Re: [abcusers] multivoice linecontinuation On Wed, Jul 23, 2003 at 10:56:15AM -0400, Laura Conrad wrote: Arent == Arent Storm [EMAIL PROTECTED] writes: Irwin % variant A Irwin G2G2A4 | (FEF) D (A2G) G|\ Irwin M:4/4 Irwin K:C Irwin c2c2(B2c2) | I think this is actually an example of a recommended syntax in some pretty widespread documentation. (Probably something that comes with abcMIDI or abc2ps.) So you can deprecate it, but you aren't going to be able to not handle it, if you want to deal with what's out there. Arent Is it used often? I used to use it and stopped because I always let the software determine the line breaks for me. But if I were still expecting to determine my own line breaks, I might still be doing it that way. It was the original syntax, wasn't it ? It worked before the inline field [M:...] syntax was introduced, so there may be a lot of older tunes out there that have it. -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] expected abc audience
When trying to fit abcusers in a few groups having [1] abc-sightreaders (without much need for software) [2] abc-collectors [3] abc-software-only-users (1st language) [4] abc-as- interchange-file-format-users (2nd language) Two questions arise - is this a meaningful division? - if so, how large do we expect the groups to be? My answer to the first question is -of course- yes ;-) The second is the hard one my first (wild)guess would be: 1: 200 (1%) 2: 500 (3%) 3: 1000, 1 (30%) 4: 1 (66%) the remainder Any thoughts? Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] About the choice of '!'
Please don't think me rude, but I think you've missed a very large category of users completely. These are people who record large collections of tunes (admittedly, each tune is likely to be a 'simple folk melody' with or without lyrics), often in the hundreds or thousands of tunes, related by genre or origin. They will use abc instead of or in addition to tunebooks. These people collect tunes and transcribe them, exchange them via email, publish them as a resource on the internet or as a collection on CD-ROM and also want to print them as dots or play them when required. They need software to proofread or proofhear what they've entered, to index, to search, to compare tunes, etc. Sophisticated typesetting is not likely to be a first-order requirement, certainly not at the expense of readability. But do they 'look' at the abc by means of software or directly. I have collected 1++ of them myself over the years (small and large collections/files) and find myself looking at the abc-source only if the software is behaving unexpectedly, so I would place the collectors group in (2). The idea of multiple tunes within one file I personally do not like much (I'd rather zip them when transferring) Arent Storm wrote: Having read the discussion about bang co for quite a while I' d like to add my two (euro)cents. I have more or less implemented a full abc import/export of ABC in MusiCAD based on 1.6 and beyond, trying to accommodate as much extensions as possible (words/multivoice/etc). When implementing linebreaks the CR/LF, I took the approach of ignoring CR/LF at all. MusiCAD determines clustering, barlines, linebreaks pagebreaks and so on, so the information abc provides in this respect was simply ignored without much consequenses. I guess the same will hold for other notation software using abc as second language. agreed As far I can see there are two main visions within the abc-community 1) People using ABC for sight reading, in fact not in need of any software whatsoever. replace 'sight reading' by 'exchange, archival and reference format' and rethink your statement If so, it would be quite easy to do the suggested format change(s) within the collectors collections, and use that as a starting point. When you are using abc this way (where it has its roots) the need for ! as forced line-break is obviously very low. I guess that a lot of other header info will not be used either. Music thus written has to be as concise and clear formatted as possible; linebreak equals CR/LF is a perfect solution for that job. other header info is remarkably important All bellswhistles like multiple staves, fancy !trill! symbols in-line words and so on will also disturb the ease of human reading that was the power of abc. A line continuation is more or less nessecary because the paper (screen) that they're writing on is also limited. For group1 the upcoming standard will be more or less ignorable... as long as ABC2.0 compliant software will read/play/display their abc's albeit with linebreaks at different places 2) People who use abc mainly as a language to engrave music (the majority?) might look at it differently. Not the majority if you weight the users by the amount of published material, I suspect. Won't that be a little bit tricky viewpoint...? One user with 1 pubished tunes would outweigh 9000 users publishing 1 tune, so the needs of 1 would outweigh the need of the other 9000 users (or am I missing something) Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] About the choice of '!'
From: Jack Campin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 12:46 PM Subject: Re: [abcusers] About the choice of '!' Having read the discussion about bang co for quite a while I'd like to add my two (euro)cents. I have more or less implemented a full abc import/export of ABC in MusiCAD based on 1.6 and beyond, trying to accommodate as much extensions as possible (words/multivoice/etc). When implementing linebreaks the CR/LF, I took the approach of ignoring CR/LF at all. MusiCAD determines clustering, barlines, linebreaks pagebreaks and so on, so the information abc provides in this respect was simply ignored without much consequenses. Which means anybody using ABC for Highland pipe music will dump the demo of your program in the trash/wastebasket/recycle-bin after they try the first tune. All phrases go on one line. No exceptions, soldier. I think/hope that that'll be too pessimistic. Just by setting (otpional) 4 bar/line I, think that most of the tunes will be just fine. Ditto a lot of people typesetting songs and hymns - look at Hymns Ancient and Modern, for example. You hardly ever find a text line running over two staff lines. And that's where ! would fit in perfectly. No need to clutter up with \ just to get a CR/LF linebreak. BarFly makes ignoring linebreaks an option (except for multi-voice music where it isn't practical); what I do sometimes is first let the program have a go at doing the layout, then optimize the result by putting explicit linebreaks in better places myself. BarFly's spacing algorithm is not very sophisticated (monospace type printed on elastic), but the same approach would be handy for any program. As I see music engraving, you should care about linebreak/pagebreak just before you start printing. You never know the paper size beforehand do you? So I implemented heaps of layout features just to enable me to get as much notes on paper as I want. And yes, there will be conflicting issues like readability and need to get as much on a single sheet as possible. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] expected abc audience
When trying to fit abcusers in a few groups having [1] abc-sightreaders (without much need for software) [2] abc-collectors [3] abc-software-only-users (1st language) [4] abc-as- interchange-file-format-users (2nd language) Two questions arise - is this a meaningful division? - if so, how large do we expect the groups to be? My answer to the first question is -of course- yes ;-) The second is the hard one my first (wild)guess would be: 1: 200 (1%) 2: 500 (3%) 3: 1000, 1 (30%) 4: 1 (66%) the remainder Any thoughts? Arent [5] software developers I don't expect to *use* abc format in anger as it's not where I am musically, but I expect to understand it and serve others as I write abc interfaces to my software. Bernard Hill I would say [5] is within [4] and I'm regarding myself also in that position. I started writing MusiCAD as a DOS program back in 1989, with more or less the same criteria as abc, though not as compact as abc, and focus to balkan music instead of bagpipe co. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] BarFly 1.4 available
From: Phil Taylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 3:19 PM Subject: [abcusers] BarFly 1.4 available I have just uploaded a new version of BarFly. snap You can now optionally have the program ignore line ends in the abc source, placing staff breaks only where marked by an exclamation mark (emulates ABC2Win). sounds fine You can use the ` character as a spacer in the text without breaking beams or generating errors. FWIW: I don't like the feature (hope it doesn't get used) if it does I gues I'll have to implement it too (sigh) Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] About the choice of '!'
From: Richard Robinson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 3:34 PM Subject: Re: [abcusers] About the choice of '!' Please don't think me rude, but I think you've missed a very large category of users completely. These are people who record large collections of tunes (admittedly, each tune is likely to be a 'simple folk melody' with or without lyrics), often in the hundreds or thousands of tunes, related by genre or origin. They will use abc instead of or in addition to tunebooks. These people collect tunes and transcribe them, exchange them via email, publish them as a resource on the internet or as a collection on CD-ROM and also want to print them as dots or play them when required. They need software to proofread or proofhear what they've entered, to index, to search, to compare tunes, etc. Sophisticated typesetting is not likely to be a first-order requirement, certainly not at the expense of readability. But do they 'look' at the abc by means of software or directly. I have collected 1++ of them myself over the years (small and large collections/files) and find myself looking at the abc-source only if the software is behaving unexpectedly, so I would place the collectors group in (2). The idea of multiple tunes within one file I personally do not like much (I'd rather zip them when transferring) Interesting. It's always struck me as one of the useful points about ABC, when dealing with several thousand tunes, that you don't have to have them all in separate files. When it comes to downloading/distributing: YES When it comes to handeling: definately NO Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] expected abc audience
From: Richard Robinson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 3:54 PM Subject: Re: [abcusers] expected abc audience snap I'm not sure if the distinction between abc-only software and converters-to-other-formats is meaningful - after all, midi, ps, png, whatever, are other file formats, too. I wouldn't regard .ps .png enz as musical relevant music strorage formats... midi is a special case but not targetted towards engraving so it is in most cases a very lossfull option. Importing midi will often lead to misinterpretations too. abc-to-other-music-storage and vice versa can be pretty much lossless. Surely the main point is that all software needs to parse ABC ? abc-exporting-only software has not ;-) Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] multivoice linecontinuation
Where it comes to to line continuation in multivoice and/or in-line lyrics things can get (unneccessarily) complicated. IMO line continuation should be allowed only for single voice. For instance, the nicely text-layed-out multivoice canzonetta.abc from the 2.0 standard would become unreadable with line continuation used. Also, when using abc to store complex scores, I think that human readablity is of very small importance, if at all; it will be uncomprehensable anyway. The 3 different approaches of writing down multivoice I dislike. I would very much prefer one approach the: voice by voice V1: abc|abc|abc|abc def|def|def:| V2: Abc|Abc|Abc|Abc Def|Def|Def:| over [V1]:abc|abc|abc|abc| [V2]:Abc|Abc|Abc|Abc| [V1]:def|def|def:| [V2]:Def|Def|Def:| and (least) V1: abc|abc|abc|abc| V2: Abc|Abc|Abc|Abc| V1: def|def|def:| V2: Def|Def|Def:| The first is what MusiCAD is exporting, while importing all three. As said before - in multivoice scores - human readability won't have to be/should not be/cannot be a major issue. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] meta comments 2.0
I would suggest that all meta-comments should be prefixed with an appropriate string indicating the target. Like %%FMT-composerfont Times-Bold 32 so that any abc-accepting can easily filter relevant settings for its context. Every abc exporting/writing program should write some fingerprint in every tune (not file) like: %%APP-ProgramName or whatever, safely to be ignored but probably useful for some other reason afterwards. I support the idea of marking the intended abc-version as a meta comment. %%VER-abc20 Where score layout is indeed a layout topic, I prefer the %%staves style: %%FMT-staves [1|2|3] a lot over V1: options V2: options V3: options Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] About the choice of '!'
Having read the discussion about bang co for quite a while I' d like to add my two (euro)cents. I have more or less implemented a full abc import/export of ABC in MusiCAD based on 1.6 and beyond, trying to accommodate as much extensions as possible (words/multivoice/etc). When implementing linebreaks the CR/LF, I took the approach of ignoring CR/LF at all. MusiCAD determines clustering, barlines, linebreaks pagebreaks and so on, so the information abc provides in this respect was simply ignored without much consequenses. I guess the same will hold for other notation software using abc as second language. As far I can see there are two main visions within the abc-community 1) People using ABC for sight reading, in fact not in need of any software whatsoever. When you are using abc this way (where it has its roots) the need for ! as forced line-break is obviously very low. I guess that a lot of other header info will not be used either. Music thus written has to be as concise and clear formatted as possible; linebreak equals CR/LF is a perfect solution for that job. All bellswhistles like multiple staves, fancy !trill! symbols in-line words and so on will also disturb the ease of human reading that was the power of abc. A line continuation is more or less nessecary because the paper (screen) that they're writing on is also limited. For group1 the upcoming standard will be more or less ignorable... as long as ABC2.0 compliant software will read/play/display their abc's albeit with linebreaks at different places 2) People who use abc mainly as a language to engrave music (the majority?) might look at it differently. As soon as abc is fed into software to engrave it on paper, the layout *CANNOT* be assumed to fit on paper (which size paper/screen should it fit on?) Software will of course take care of linebreaks (and should do the same for barlines...) When using abc this way a forced-linebreak-device other than CR/LF is simply nessecary and the layout should not be cluttered by CR/LF linebreaks. Luckily notation software can easily be instructed to ignore CR/LF and place linebreaks where nessecary for the job based on layout instructions in the program itself or meta-comments in the file itself like %%FMT-BarsPerLine 4 %%FMT-LinesPerPage 11 %%FMT-TitleFont Roman 11 bold (all instructions not meant for goup1) ;-) Thus the original abc remains unbroken, and musically intact, be it that the beforementioned layout will be different than perhaps intended by the author, which seems a minor issue. I am afraid that you cannot have everything of both worlds simple abc as in thge average reel or a multi-voice symphony In fact the current standard tries to describe the layout of a tune using CR/LF which is IMO undesirable; it should describe the music only not the way it must fit on paper. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
