Re: [abcusers] accidentals in ()
Laura Conrad writes: John seems that some people here are saying that in some cases cautionary John accidentals ARE musically significant. No, I think what we're saying is that cautionary accidentals are easy to confuse with editorial accidentals, which *are* musically significant. In my case, it's one of the things that makes lilypond easier to use for my purposes than ABC -- I'm not willing to enter editorial accidentals into my transcriptions unless I can distinguish them from the ones in my sources. Let's see if I understand the problem. There seem to be several different forms of accidentals, such as editorial accidentals and cautionary accidentals, which are played differently, but are the same on sheet music. (Or conversely, there are forms, e.g. ordinary and cautionary, which are played the same way but appear differently on sheet music.) We would like to have all of these kinds in abc. But we don't have a great amount of unclaimed notation to spare. To me, this would seem to be a good place for user-defined symbols. If there were a construct, say !accidentals_in_prens! built into abc, one could use the U: field to assign it to one of the free characters H--Z. That is, one could write, say, U:P=!accidental_in_prens! for instance, and then, whenever such an accidental came up, just write P before it. The advantage here is that something like !accidental_in_prens! only appears in the headers and doesn't need as compact a notation as something which appears in the abc: it only uses existing notation in the tune body. If one wants to distinguish between cautionary and editorial accidentals (which I gather are similar on sheet music) one can also define U:Q=!accidental_in_prens! and then write Q before the editorial accidentals, P before the cautionary accidentals, and thereby preserve the difference in the abc source. (The difference in playback can be taken care of in the m: field.) The same thing could be done for optional notes mentioned earlier in this thread, which are sometimes written in parentheses. That is, one could build in something like !note_in_prens! and assign it a letter in the U: field. I haven't checked, but I think this can already be done in abc2mtex by writing a couple of musictex macros. It is certainly the first thing I'd try if I needed it. HmmmI foresee someone objecting that if we have something as clumsy as !accidental_in_prens! around, people will use it in the body of the tune instead of the header. I doubt it'll happen often, but one could avoid it entirely by decreeing that commands enclosed by, say, double bangs, e.g. !!foo!!, can only be used in headers, and not in the tune body, and use that convention for these additional commands. Cheers, John Walsh To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accidentals in ()
At 09:32 AM 11/17/2000 +, Phil Taylor wrote: If I put in an accidental where none is required it's because I want it displayed there, and if I put it in parentheses it's because I want it to display that way. When music is put on paper there are two inputs, the MUSICAL input, and the STYLE input. In the case of abcm2ps, the music comes from an "abc" file and the style comes from a "fmt" file. I am a purist and I believe that ABC should not be contaminated with style information such as what font to use, whether stems should be up or down, and whether to insert cautionary accidentals or not. I think that cautionary accidentals are not musically significant. Whether or not to include them is an editorial decision. However, it seems that some people here are saying that in some cases cautionary accidentals ARE musically significant. If that is true, (and not too esoteric) then the ABC syntax should allow them. However, I think 99% of the time it is better to let the typesetter decide about cautionary accidentals, and not "hard-code" them in the ABC file. John Henckel alt. mailto:[EMAIL PROTECTED] Zumbro Falls, Minnesota, USA (507) 753-2216 http://geocities.com/jdhenckel/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accidentals in ()
"John" == John Henckel [EMAIL PROTECTED] writes: John I think that cautionary accidentals are not musically significant. John Whether or not to include them is an editorial decision. However, it John seems that some people here are saying that in some cases cautionary John accidentals ARE musically significant. No, I think what we're saying is that cautionary accidentals are easy to confuse with editorial accidentals, which *are* musically significant. In my case, it's one of the things that makes lilypond easier to use for my purposes than ABC -- I'm not willing to enter editorial accidentals into my transcriptions unless I can distinguish them from the ones in my sources. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org ) (Note the email and homepage address changes; please update your address book, bookmarks, and links.) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accidentals in ()
What I did for Skink was to write a parser in JavaCC (a java compiler compiler) which builds a list of objects that represent the elements of a tune - I then process that list sequentially to create the notation. The plan is to process the same list to produce the music, but since I haven't implemented that yet I don't know for sure whether I can just use the same list or whether I have to "unroll" repeats, etc. Java is nice and portable... wil Phil Taylor wrote: John Henckel wrote: It's true that when the new ABC standard become approved (I say, hopefully) then a lot of software will need to be rewritten to handle the new file format. Perhaps someone could write a really portable ABC parser and then give away the source code that each developer can just "plug it in" to their ABC tool (abc2midi, abc2abc, abc2ps, abc2win, abc2???, etc...) There's no sense in everyone reinventing the wheel. It's a lovely idea, but it gets awfully complicated when you think about it. What would the output of such a parser be? Some programs want to make a picture of the staff notation, and would therefore want postscript, gif or something of that ilk. Others want to play the music, and need MIDI or something equivalent. The first kind of parser can take a single pass through the abc, while the second needs to loop to deal with repeats. In practice, they are so different that I wrote two entirely separate tune parsers for BarFly. The only common code is the part which parses the header. What is needed perhaps is an intermediate representation of the music which is easy to convert to either picture or sound. The first stage parser which converts abc to this intermediate format could be used by us all, while the remaining part of the job would be handled by the developer's own code. The trouble is, we'd spend forever arguing about the details of the intermediate format... Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html -- Wil Macaulay email: [EMAIL PROTECTED] voice: +1-(905)-886-7818 xt2253FAX: +1-(905)-886-7824 Syndesis Ltd. 28 Fulton Way Richmond Hill, Ont Canada L4B 1J5 "... pay no attention to the man behind the curtain ..." To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accidentals in ()
It's true that when the new ABC standard become approved (I say, hopefully) then a lot of software will need to be rewritten to handle the new file format. Perhaps someone could write a really portable ABC parser and then give away the source code that each developer can just "plug it in" to their ABC tool (abc2midi, abc2abc, abc2ps, abc2win, abc2???, etc...) There's no sense in everyone reinventing the wheel. At 07:08 PM 11/15/2000 +, Steve Mansfield wrote: (^)A looks like a good compromise to me - but Ac2Win dislikes slurs which start and end on the same note when drawing the dots, and might also object to this arrangement - goes off and tries it - yes it does! (That's version 2.1k, Jim, if you're reading this :-) ) Not necessarily an objection to accepting this, but there's a lot of people running abc2Win who'll start getting error messages on files containing this syntax ... John Henckel tel. 507-753-2216 Zumbro Falls, Minnesota, USA alt. mailto:[EMAIL PROTECTED] Try it! http://www.SUBJEX.com The next generation search engine! Pagelab Networks, 43 Main Street SE, Suite 508, Minneapolis, Minnesota, USA Get AOL chat free at http://aim.aol.com and talk to me, "John Henckel" To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accidentals in ()
On Thu, 16 Nov 2000, Laura Conrad wrote: Either I don't understand what you're proposing, or you aren't talking about the same thing as the rest of us. How do you let the person printing the score control what accidentals are printed without providing a syntax for doing so? The (^) syntax is precisely a method for the person who wants to print a sharp in parentheses to specify this. Whether the sharp is one that the program would figure out to add or not. What's your idea for how to get this? The syntax being discussed is nothing but a way of saying, "this accidental isn't really necessary." We don't NEED a syntax to say that, the musical necessity of the accidental can be determined purely from its context. From there, it's trivial to provide software switches or parameters to decide what to do with accidentals that aren't musically necessary (throw them away, print them, or print them in parens). It's even pretty simple to add software options that do things like "put helper accidentals in the first two measures after any bar where a note was altered and not restored" -- thus adding helper accidentals even when they aren't present in the source. Again, doing it this way leaves it up to the person who will be printing, and presumably playing from, the score. So, if you don't like helper accidentals and I do, we can each have our cake and eat it too. -- John Atchley -- http://www.guitarnut.com http://www.guitarnuts.com So many guitars, so little time... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accidentals in ()
On Thu, 16 Nov 2000, Laura Conrad wrote:
The (^) syntax is precisely a method for the person who wants to print
a sharp in parentheses to specify this. Whether the sharp is one that
the program would figure out to add or not. What's your idea for how
to get this?
Just in case I got too wordy and unclear in my other response here's a bit
of pseudo-code:
if (accidental_in_abc_source is musically_necessary) {
unconditionally display accidental
} else {
/* Accidental is not musically necessary */
switch (user_desires_for_unnecessary_accidentals) {
case "throw it away":
do nothing
case "print it normally":
print the accidental
default:
print the accidental in parens
}
}
The logic for determining if a helper should be added when there isn't an
accidental in the source is a little more involved, but not much -- I've already
done it in jaabc2ps.
--
John Atchley
--
http://www.guitarnut.com
http://www.guitarnuts.com
So many guitars, so little time...
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accidentals in ()
"John" == John Atchley [EMAIL PROTECTED] writes:
John Just in case I got too wordy and unclear in my other
John response here's a bit of pseudo-code:
John if (accidental_in_abc_source is musically_necessary) {
John unconditionally display accidental
John } else {
John /* Accidental is not musically necessary */
John switch (user_desires_for_unnecessary_accidentals) {
So you're not planning on an option by note; just a way to clutter up
the clef with unnecessary accidentals whether they're useful or not?
I think you're missing an important point. There are *two* reasons for
putting accidentals in parentheses:
Cautionary accidentals, where the conventions of standard
notation mean that the accidental isn't necessary for a player
program, but the editor feels that human players will be more
likely to get the right note if the accidental is there.
Editorial accidentals, which are exactly like regular
accidentals in the sense that both a human and a computer
would need the accidental to know that they should play it,
but the editor wants to visually distinguish this accidental
from others. For instance, my transcriptions should have both
accidentals that occur in the facsimiles I'm transcribing
from, and accidentals that weren't printed there because in
the 16th century whether to play certain kinds of accidentals
was considered a performer's decision.
In my opinion, there's no need to distinguish these two cases in ABC for
either a playing or a printing program. That is, a player program
could ignore cautionary accidentals, but would get the same result as
if it played them, and would risk ignoring editorial accidentals which
it should play if it tried to make the distinction.
--
Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org )
(Note the email and homepage address changes; please update your
address book, bookmarks, and links.)
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accidentals in ()
John A.,
I agree with you 100% that cautionary accidentals can and should be handled
by the typesetting program, NOT with special syntax in the ABC music
file. I took the liberty to rewrite your pseudo code. IMO, if the user
specifies an unnecessary accidental, then the typesetter should show it
with parentheses around it. The following is my attempt at a revised
algorithm for accidentals.
let n = the current note
let p = the most recent note with the same letter and octave as n.
if (n has no accidental) {
if (p is in the measure just before n, and p is not in the key signature) {
n should be shown with a cautionary accidental
}
else {
n should not have any accidental
}
}
else if (n has an accidental that is already in the key signature)
{
if (p is in the same measure as n, and p has different accidental than n) {
n should show it's accidental
}
else {
n should be shown with a cautionary accidental
}
}
else if (n has an accidental that is not in the key signature)
{
if (p is in the same measure as n, and p has the same accidental as n) {
n should be shown with a cautionary accidental
}
else {
n should show it's accidental
}
}
To make everyone happy, this algorithm should have parameters to fine tune
it. For instance, the threshold in the number of measures between p and n,
and to turn off, or remove parens from any of the three "cautionary" cases
above.
John Henckel alt. mailto:[EMAIL PROTECTED]
Zumbro Falls, Minnesota, USA (507) 753-2216
http://geocities.com/jdhenckel/
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
Re: [abcusers] accidentals in ()
On Tue 14 Nov 2000 at 11:16PM -0600, John Henckel wrote: Also I recommend the ABC standard should clarify whether repeated accidentals are required or not. For instance, given K:C, is " ^c c | ^c " three c-sharps in a row? Or is the second c a natural? According to abcm2ps, the second c is SHARP (i.e. no natural sign is inserted). However, according to abc2midi, the second c is NATURAL (i.e. it sounds lower than the first note). IMO, the way abc2midi works is correct, and the ABC standard should say that the second c is natural. I think you've got the wrong program. abc2midi sharpens the second C, which is the correct behaviour according to standard musical interpretation. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accidentals in ()
At 09:33 AM 11/15/2000 +, Phil wrote: Seems reasonable, although just putting the accidental in a paren would be more intuitive: (^)C etc. Harder to code though, as you have to distinguish it from the other uses to which parens are put. You're right. I will try to do this. I think it will only require a two-character look-ahead. snipAccidentals affect only notes of the same pitch, and not the same note in a different octave (even in chords). I'm surprised that abc2midi doesn't work that way. MY MISTAKE! abc2midi does work that way, as James Allwright said. So I guess the consensus is clear, that an accidental only needs to be indicated on the first note per tone per measure. Thanks for the help! John Henckel alt. mailto:[EMAIL PROTECTED] Zumbro Falls, Minnesota, USA (507) 753-2216 http://geocities.com/jdhenckel/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accidentals in ()
John Henckel wrote: In abcm2ps there is a bug. If an accidental is used several times in the same measure, it draws all of them. Thus, K:F and " =B =B " will print two notes with naturals in front of them, but only the FIRST one should have a natural sign. I am going to fix jhabc2ps so that only the first occurrance of an accidental is printed in each measure. I recommend that all other ABC rendering programs should do likewise. This is a really bad idea. Such "advisory" accidentals are often there for a good reason. Suppressing them means that you're using cpu time to make the music less readable. Nobody will thank you for this. I wouldn't even consider using software that damages my music in such a fashion. Also, by doing this, you are explicitly excluding both the Early Music and Modern Music crowds from the set of ABC users. Both of these crowds often use the convention that accidentals apply to only the one note. They have good reason for this. Discarding their explicitly-coded accidentals will mean that they can't use your software. It should be noted that, for music formatters, the question of the scope of accidentals is irrelevant. It only matters when you're playing the music. Music formatters don't play the notes, they just produce staff notation. They don't need to know anything at all about a note's pitch, only how to represent it on a page. So a music formatter like abc2ps has no business trying to second-guess the transcriber. It should simply display accidentals as shown in the ABC, and not try to "improve" on them. Notation for parenthesized accidentals is a good idea. We've had a number of suggestions that (^)A or (=)B be legal. This is probably the most intuitive solution, and doesn't seem to conflict with the use of parens for slurs. There was a suggestion that ?^A be used, but I don't think there was any reaction to this. I have wondered whether this should be discussed again. There are a number of places where parens are used like this in printed music. The one case where parens won't work in ABC is for optional slurs. Writing something like (()ab cd) is probably not a good idea. It's confusing and tricky to parse. The notation ?(ab cd) would be a better way of saying that the slur is optional. Programs could interpret this as is appropriate. A formatter could generate little parens around the slur. A player could randomly choose whether to honor the slur. In most other cases that I can think of, parens in ABC would work. An optional chord can be written as "(Em)", for instance, and everyone will know what is meant. Similarly, (.)G and (H)G are obvious and intuitive, and easy to parse. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accidentals in ()
I recommend that when (if?) the ABC notation standard is updated, it should contain syntax for "helper" accidentals. I am going to hack my version of abcm2ps (called jhabc2ps) to support accidentals in parentheses. Does anyone have a recommendation for the syntax? I am thinking about using '=' to denote a helper accidental For instance, =^C will show a note with (#) in front and =_C will show (b) in front, and ==C will show a natural sign in parentheses in front of the note. I don't think this conflicts with any existing notation. Of course, it will be the users responsibility to use it correctly, for instance, if K:F then " =B | =_B " is correct, but " =B =_B " is not correct because there is no bar between the notes, so it isn't a helper accidental. (This kind of "user beware" is not new, for instance a user could also misuse accidentals, such as =C or _B when K:F). In abcm2ps there is a bug. If an accidental is used several times in the same measure, it draws all of them. Thus, K:F and " =B =B " will print two notes with naturals in front of them, but only the FIRST one should have a natural sign. I am going to fix jhabc2ps so that only the first occurrance of an accidental is printed in each measure. I recommend that all other ABC rendering programs should do likewise. Also I recommend the ABC standard should clarify whether repeated accidentals are required or not. For instance, given K:C, is " ^c c | ^c " three c-sharps in a row? Or is the second c a natural? According to abcm2ps, the second c is SHARP (i.e. no natural sign is inserted). However, according to abc2midi, the second c is NATURAL (i.e. it sounds lower than the first note). IMO, the way abc2midi works is correct, and the ABC standard should say that the second c is natural. What do others think about this? John Henckel At 07:19 AM 10/8/2000 -0400, you wrote: "Atte" == Jensen Atte writes: Atte Anyway; how do I get the brackets 'round the accidental in abc? We've discussed this; there's a similar problem in early music, where the notation didn't always include accidentals that "everybody" would know to play, and modern editors want to put them in, since "everybody" today doesn't necessarily know. And it would be useful to be able to have the MIDI play them. The best solution I know in the context of the current abc2ps is to put "(#)" above the note. This would be almost good enough for my purposes if abc2ps understood the TeX commands for entering \sharp, \flat, and \natural, but it doesn't. I have also proposed that there be an extension to the current syntax so that a ^, _, or = enclosed in parentheses would be printed that way. I don't remember anyone either disagreeing with this or rushing to implement it. If I were implementing this, I would also provide %% commands so that it was under the control of the editor whether these accidentals printed above, below, or on the staff, with or without parentheses, or didn't print at all but were just directions to player programs. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (801) 365-6574 233 Broadway, Cambridge, MA 02139 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html John Henckel tel. 507-753-2216 Zumbro Falls, Minnesota, USA alt. mailto:[EMAIL PROTECTED] Try it! http://www.SUBJEX.com The next generation search engine! Pagelab Networks, 43 Main Street SE, Suite 508, Minneapolis, Minnesota, USA Get AOL chat free at http://aim.aol.com and talk to me, "John Henckel" To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accidentals in ()
At 10:18 AM 10/8/2000 +0200, you wrote: Anyway; how do I get the brackets 'round the accidental in abc? I have the same question. Unfortunately, it appears to be not possible using any of the variants of abc2ps. We could allow syntax similar to that used for triplets, such as "v(^c", to be rendered as a sharp sign in parens. This is not ambiguous because this is not a legal notation for slurs. John Henckel alt. mailto:[EMAIL PROTECTED] Zumbro Falls, Minnesota, USA (507) 753-2216 http://geocities.com/jdhenckel/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] accidentals in ()
Hi Often you see "reminder accidentals", that are actually not neccesary. Since I don't know the exact term in english I give a quice example: At some point you have a Db (the tune is in Eb) and in the next bar you have a D natural. But to make sure it's actually played "D" and not "Db" you put this reminder natural sign before it. Since it's only an reminder it's often put in brackets - I guess you all know what I'm talking about, right? Anyway; how do I get the brackets 'round the accidental in abc? -- Atte André Jensen "I don't think Microsoft is evil in itself; I just think that they make really crappy operating systems." - Linus Torvalds To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accidentals in ()
"Atte" == Jensen Atte writes: Atte Anyway; how do I get the brackets 'round the accidental in abc? We've discussed this; there's a similar problem in early music, where the notation didn't always include accidentals that "everybody" would know to play, and modern editors want to put them in, since "everybody" today doesn't necessarily know. And it would be useful to be able to have the MIDI play them. The best solution I know in the context of the current abc2ps is to put "(#)" above the note. This would be almost good enough for my purposes if abc2ps understood the TeX commands for entering \sharp, \flat, and \natural, but it doesn't. I have also proposed that there be an extension to the current syntax so that a ^, _, or = enclosed in parentheses would be printed that way. I don't remember anyone either disagreeing with this or rushing to implement it. If I were implementing this, I would also provide %% commands so that it was under the control of the editor whether these accidentals printed above, below, or on the staff, with or without parentheses, or didn't print at all but were just directions to player programs. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (801) 365-6574 233 Broadway, Cambridge, MA 02139 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
