lilypond-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Ligature brackets


From: Robin Davies
Subject: Re: [PATCH] Ligature brackets
Date: Fri, 17 May 2002 21:17:30 -0400

> > 6) Stacked 2xN (Jazz) or "/" sepearated alterations.
>
> What do you mean by this?

I suspect this is what the Jazz style is supposed to do, but doesn't.

C-7(+5+9) (hmmm. That's another way of setting exceptions -- in brackets --
makes a note) would be set as

    C-7 in full-sized type, followed by +9 in half-sized type in a column on
top of +5.

If there is a 3rd alteration, it seems to be conventionally set in a new
column, and I suppose, if there were a fourth it would be set in the same
column. e.g. (as best as I can render it in ascii.

               -11  +5
      C13
              +9
             ^^^^^ ^^^^^^^^^^^ little type.

The baseline of +9 and the ascender of -11 roughly align with the basline
and ascender of C13. This seems to be common practice in many of the texts I
have that use pure jazz notation, and I also came across an example of this
style of setting of alterations in a book that used american base chords
(m/Maj style).

> I'm not sure about this.  I seem to remember a request to never show
> noX (Amelie, you're still around?).
>
k. i guess it's not too hard to implement never showing noX, but I do think
that if someone were to provide a chord with a noX, even in Jazz or
American, that they lily should show what they actually input. I can't see
much harm in requiring all notes in the chord.


> > 9) The inversion/root ('/' vs '/+') functionality doesn't seem entirely
> > sensible to me, but I'll support it as given.  e.g.   a:m7/g   produces
> > Am/G in the current system instead of Am7/G, although a:m7/+g does
produce
> > Am7/G.   a:m7/e produces Am7(no5)/E.
>
> What would you suggest?  I do think we need both, ie, a chord with an
> extra added base note (/+), and an inversion (/)?
>
I think what disturbs me about the function as implemented is that the
inversion notation drops tones from the chord. If inversion and base note
were the same with the sole exception that inversion gave a warning if the
note were not in the chord, then it would make a little sense to me, but I
still wouldn't use it myself. ;-)   Perhaps I'm missing the intended
application for the inversion notation scheme. The fact that the more useful
of the two (the base note notation) is the oddball case rather than the
default case disturbs me a little, as well.

This was my user experience with the features. When I first used base notes
in a typeset chart there were three or four chords that had base notes
(interestingly, I made it through about 5 charts before I first noticed
this). When I  requested a:m7/g and got A-/G, and I was so horrified at the
the chord-name stupidity that I was on the verge of swearing off lilypond
forever. It wasn't until a couple of hours later that I came back to it,
convinced that base notes couldn't possibly be that messed up that I found
the documentation on /+ .

The real trouble is that I can't really imagine why anyone would want to use
the / inversion style of chord notation. Is this an international practice
issue? If so, I'll happily concede the point.

Suggestion for discussion:     support /+ as given for backward
compatibility, change "/" to work the same as "/+" and provide "/-" for
people who *really* want to do that. I suppose that will break a chart or
two, but ... but... I just can't imagine anyone used "/". I think this would
be better, but, truthfully, I lean toward not breaking whatever is out there
already that uses "/".

<shudders> The "/" inversion feature does remind me a little of figured bass
notation, but I don't remember figured bass notation well enough to think
about it right now.

> [banter examples]
> Do these make sense?  I'm always in doubt about the 7 issue.

Yes. That makes perfect sense. Thanks.







reply via email to

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