lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: triangle chord notation


From: Eyolf Ostrem
Subject: Re: triangle chord notation
Date: Sat, 12 Aug 2006 00:25:58 +0200
User-agent: KMail/1.9.4

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.

> >  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?

Eyolf


-- 
This fortune intentionally not included.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]