lilypond-user
[Top][All Lists]
Advanced

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

Re: Lilypond and Jazz chords


From: Carl D. Sorensen
Subject: Re: Lilypond and Jazz chords
Date: Sat, 13 Jun 2009 07:38:23 -0600



On 6/12/09 9:10 AM, "Tim McNamara" <address@hidden> wrote:

> 
> 
> On Jun 12, 2009, at 1:28 AM, Tao Cumplido wrote:
> 
>>> I think it's great that you did this.  Have you put this on LSR?
>> 
>> Thanks. I haven't put this on LSR yet because the function hasn't
>> been much tested yet. Maybe I should have done anyway.
>> When the function is updated I will upload it there.
>> 
>>> Perhaps we should consider adding this to the distribution.
>> 
>> What exactly do you mean? To which part yould you add it?
> 
> Ummm.  Here is a question of software philosophy.  Should there, like
> some computers languages, be many ways to do something or should
> there only be one?  In my opinion, in the long run it makes it harder
> to learn to use something like LilyPond if there are six ways to do
> the same thing.  The documentation becomes more difficult to write
> and to maintain, it becomes harder for new users to learn how to use
> the software, and as the software accretes ways to do things the
> package gets bigger and easier to break.  LilyPond .ly syntax is a
> programming language itself and the clearer and more specific the
> rules are for its operation, the simpler and more reliable its use.
> 
> I think that there should be only two ways to enter chords (at least
> in Western music notation systems):  by putting in the notes to be
> placed on the staff or by entering the text name of the chord in a
> single standardized, sensible way.  Once we start adding ways to
> engrave chords using the markup or lyric functions we are heading
> towards chaos IMHO.

I agree with you, if what is wanted is chord entry.  But Tao doesn't care
about chords, he only cares about chord names.  And so a new type of entity
can be created, which isn't a chord, but instead a lyricChordName.

lyricChordNames can be treated in a separate section of the documentation.
They are displayed in a Lyrics context, not a ChordNames context.  And they
give the user tremendous flexibility to display whatever the user wants to
display for chord names.

Personally, I would never use lyricChordNames.  I agree with you that chords
are groups of notes, and we should not lose sight of that.  And with your
help, we should be able to rewrite the chordmode and ChordNames
functionality to support that usage.

But there is a (to me) surprisingly large contingent of users who claim that
there is no well-defined connection between chord names and chord notes, and
that they want total control over the symbols to be displayed.  And the
lyricChordNames functionality is a way to get transposable chord names for
people who are in that camp.

I don't think it's a problem to have multiple clearly-defined modes.  That's
why I think it may be feasible to implement Tao's suggestion.

Thanks,

Carl

> 
> 
> 





reply via email to

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