> you should have read more carefully what David wrote (and thought about it):
In my first message I wrote that "If I change "e,:1.7.10^3" to "e,:1.7.10-^3" I get the desired output." So this isn't *exactly* the issue, but David's solution isn't exactly right too, as "e,:m1.7.10^3" =/= "e,:1.7.10-^3". (At least my impression was that he tells me that the two definition should be "equal".) David said, that "Chord specifications are completely independent from the current key", which doesn't mean that it also completely independent of the specification *itself*. If I specify that I'm building a minor chord with "e:m<whatever>", then in the "<whatever>" part if I insert a third note (into a minor chord) that note should be a minor third. If I'm totally wrong, then what's the point of the "m" specifier? Also "e:m3" and "e:m1.3" should result in the same output, but in the latter case a major third will be used (independent of the key). So its behaviour is inconsistent in my book. I've also observed, that the following definitions generate a chord with a natural G (or Gs): e:m3, e:m5, e:m7, e:m9, e:m11, while e:m10 doesn't: the first G on the second line is natural, but the G on the fifth is sharp. The tenth note is the octave of the third, is it not? So why it sharp if the third isn't? I'm an amateur in music theory, but this seems off to me. If this is totally planned and intentional then this behaviour should be mentioned in the manual. Thanks for all the responses. On Sun, Dec 18, 2011 at 10:34 PM, Thomas Morley < [email protected]> wrote: > Hi, > > 2011/12/18 Róbert Kohányi <[email protected]>: > > On my end, modifying "e,:1.7.10^3" to "e,:m1.7.10^3" in the supplied > example > > has no effect on the output. :/ At least one of the two variation should > > produce a natural G above the fifth line, or am I overlooking something > > here? (/me amateur-self-taught-hobbyist guitar player.) > > > > Moreover, replacing the chord definition in the example code with one of > the > > two snippets below, should produce the same results (but it does not): > > > > e,:m3 — G on the second line. > > e,:m1.3 — G# on the second line. > > > > Specifying "m" in the definition should indicate to LilyPond that I'm > trying > > to create a minor chord, with a minor third. Is this a bug? Is this > known? > > Should I create an issue for it? > > > > On Sun, Dec 18, 2011 at 9:13 PM, David Kastrup <[email protected]> wrote: > >> > >> Róbert Kohányi <[email protected]> writes: > >> > >> > I'm trying to typeset an E minor seventh chord where the third is an > >> > octave higher and the fifth is omitted in the key of E minor > >> > > >> > Given the example below, I would expect that three notes are printed > >> > on the staff: E–first line, D–fourth line, G–above the fifth line. > >> > However instead of a G a G# is printed above the fifth line. > >> > > >> > If I change "e,:1.7.10^3" to "e,:1.7.10-^3" I get the desired output. > >> > > >> > Can I tell LilyPond somehow to "figure out" that I'm in E minor and > >> > the tenth of the chord is actually a G and not a G#? It seems to me > >> > that it builds the chord like the key was E major. > >> > > >> > \version "2.14.1" > >> > \relative c { > >> > \clef "treble_8" > >> > \key e \minor > >> > \chordmode { > >> > e,:1.7.10^3 > >> > } > >> > } > > you should have read more carefully what David wrote (and thought about > it): > > "Chord specifications are completely independent from the current key"!! > > >> (except, of course, that the written accidentals depend on the key). If > >> you want a minor chord, write e,:m1.7.10^3 or so. > >> > >> -- > >> David Kastrup > > try: > > \relative c { > \clef "treble_8" > \key e \minor > \chordmode { > e,:1.7.10- > } > } > > HTH, > Harm >
_______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
