On Sat, 12 Aug 2006 00:25:58 +0200, Eyolf Ostrem wrote: > On Fri 11 August 2006 16:47, David Raleigh Arnold wrote: >> On Sat, 05 Aug 2006 00:59:10 +0200, eyolf ostrem wrote: > >> > I read though your old posts on this matter, and I agree on many of >> > your points. Your syntax scheme for chord naming is admirably precise: >> > >> > root [m] [farthest unaltered extension] [(list alterations in >> > ascending order)] [add|omitNoteOrNumber] (quoted from >> > http://lists.gnu.org/archive/html/lilypond-user/2004-03/msg00361.html) >> > >> > and could well be used as a basis for a new chord naming standard in >> > LP as well. >> >> *Not mine*, not new. Just what I learned in the Jurassic. > > OK, if you don't want the praise... I wasn't referring to the system - > which is familiar - but the concise description of it, which would save > lots of budding guitar players a lot of pain and scratching, and probably > put a theory teacher or two out of their jobs if it was enclosed with > every guitar sold. :-) > >> > dim and aug - these are special in that they to some extent fall >> > outside the system of chords above a keynote, and deserve special >> > treatment. > > [snip] > >> I think many people do dim for the triad only, although it is not a >> standard and never has been one. I already proposed that too. It does >> no harm. > > Exactly - as long as all the symbols are available. Both "dim" and "dim7" > should be available for output. > >> > sus2 and sus4 - > > [snip] > >> "well established?" Not really. It's always too late for indications >> of what is to follow. > > Well, disregard my rambling about resolution - the symbols sus4 and sus2 > are well established (you can hardly argue against that), and they serve > their purpose well. > >> The specific problem is the use of "-" for both minor and flat. The >> general problem is that lead sheets become illegible when quickly >> written by hand. Usages which rule out scribbling are bad IMO. > > Agreed, in principle. Although a Lilypond file can hardly be counted as > 'scribbling'... But one should be able to use the same system without > having to take lettering classes.
That's putting it very well. I think it is the most compelling possible argument, but unfortunately it fails to persuade very many people. >> > As for "add2", I agree that it's an unnecessary redundancy, even >> > though there is the technical subtlety of indicating a cluster >> > c-d-e-g rather than a stack c-e-g-d. >> >> Chord names ought not to be specific to a particular instrument. Leave >> 'clusters' in the sense that you mean to the players. The developers >> mean something entirely else by 'clusters'. > > As I said, I agree that it's an unnecessary redundancy, but I would also > have to agree that the sound of c-d-e-g - regardless of instrument; that > has nothing to do with it - is different enough from c-e-g-d to ALMOST > merit at least the option to notate it. I'd never use it, though. > >> >> Academics poison the well when they use the system for analysis, >> >> which is a purpose for which it was never intended. >> > >> > ... but one for which it can perfectly well be used, within >> > reasonable limits. They(/we) should not be excluded because some of >> > their(/our) needs are different from those of the jazz musician at a >> > jam session. >> >> You really should. Go nuts with colons and minuses and all that stuff >> and do your own thing but keep the standard system simple. It's for >> playing at sight, not analysis. > > Scuse me - where did I say anything to advocate colons and minuses? All > I wish is a clear and consise system which is able to quickly set down > some aspects of the music (not all of them - hence my attitude towards > add2), and in that, I'm not really different when I sight read and when > I analyse. KISS indeed, that's what I'm after. Which is exactly where I > think your argument against B# in favor of C fails. It does not simplify > things, especially not for the system, and not either for the player, > who, e.g. is accustomed to see some kind of relationship between E and B > and hence also between E# and B#. E# and C would confuse that player. > > But rather than bicker about what is the ultimately, objectively best > system for chord notation and why, I'd like to discuss what might be > desired from the chord notation part of LP. How about: > > - Ditch the current 'alternative' system, which nobody has and nor is > likely to ever use. > - Replace it with one or more predefined sets, e.g. one with the > overload of geometrical symbols that is Ignatzek, another which is > 'brief but verbose', ascii-based, scribble-friendly, like dim, aug, > sus4, add9, etc. - Expand the set of programmed-in exceptions from > today's option to choose between "maj7" or <triangle>, to include > specifyable rules about e.g. -/+ or b/#, dim/aug or o/+, strict or lax > use of 'add' (e.g. 69 or 6add9), i.e. the broad dialects in graphical > preferences. - with the final aim of getting a system which (a) has > usable defaults, and (b) has options for all/most of the symbols in > current use in jazz, in rock, and in tin pan alley arrangements alike, > and without the user having to dig into the source files and boldly > change defaults there or whatever. If I want to display Fdim or B#7, I > should be able to do so, and not be forced to write Fo or C. (Of course, > if I want to write F%& or B@, I accept to have to work for it.) > > Is this something we can agree upon? Absolutely. But all of this was before the developers from the beginning. How can you expect a different result from the same input? daveA _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
