Issue 365840043: New feature: automatically invert chords or drop/raise chord notes (Closed)
|
Created:
5 years, 11 months ago by Valentin Villenave Modified:
5 years, 10 months ago CC:
lilypond-devel_gnu.org Visibility:
Public. |
DescriptionNew feature: automatically invert chords or drop/rise chord notes
This feature was suggested and improved upon by
Davide Bonetti, with some help from David K:
https://lists.gnu.org/archive/html/lilypond-user/2019-01/msg00360.html
Included here are three new commands: \dropNote, \riseNote and
\invertChords, and a new Scheme function, move-chord-note.
The first two commands take an integer that selects which
note will be transposed one octave lower or higher within
every chord in the music expression that follows, thus allowing
for more sophisticated voicings (e.g. `drop 2’ and the like).
If the argument is out of range (if there aren’t enough notes
in the chord), it’s silently ignored and the chord’s left unchanged.
\invertChords accepts both positive and negative integers, and
inverts all chords accordingly (as in switching the root note’s
position, not as in reversing intervals like \inversion does).
These commands work with both explicitely-written chords and
\chordmode-entered chords (only when printed on a staff though;
ChordNames are not to be affected).
Patch Set 1 #Patch Set 2 : Ugh. Should be "raise" rather than "rise". #Patch Set 3 : Fix `make check’. #Patch Set 4 : Rebase; thanks James :-) #
Total comments: 2
Patch Set 5 : Also set 'octavation so that voicings don’t modify the chord’s name #
Total comments: 3
Patch Set 6 : Address David’s comments. (Well, most.) #Patch Set 7 : Rebase, and use rewritten function #Patch Set 8 : Use sorted note list to select the correct note. #
Total comments: 1
Patch Set 9 : Handle chords larger than one octave. #
MessagesTotal messages: 36
Ugh. Should be "raise" rather than "rise".
Sign in to reply to this message.
Fix `make check’.
Sign in to reply to this message.
Rebase; thanks James :-)
Sign in to reply to this message.
https://codereview.appspot.com/365840043/diff/60001/scm/modal-transforms.scm File scm/modal-transforms.scm (right): https://codereview.appspot.com/365840043/diff/60001/scm/modal-transforms.scm#... scm/modal-transforms.scm:335: (ly:music-transpose Shouldn't this also set/adjust the octavation property so that ChordNames context and similar still recognize the original \chordmode chord in spite of the revoicing?
Sign in to reply to this message.
Also set 'octavation so that voicings don’t modify the chord’s name
Sign in to reply to this message.
That’s a great idea; I hadn’t considered it. I ought to add it to the regtest then… Oh. I’ve just noticed that although it does works with simple \dropNote and \raiseNote commands, it makes a mess of nested commands (and therefore \invertChords). I was careful not to overwrite a possibly already-set 'octavation for that exact reason, but it looks like my math was off. https://codereview.appspot.com/365840043/diff/60001/scm/modal-transforms.scm File scm/modal-transforms.scm (right): https://codereview.appspot.com/365840043/diff/60001/scm/modal-transforms.scm#... scm/modal-transforms.scm:335: (ly:music-transpose On 2019/01/23 21:14:56, dak wrote: > Shouldn't this also set/adjust the octavation property so that ChordNames > context and similar still recognize the original \chordmode chord in spite of > the revoicing? Done.
Sign in to reply to this message.
https://codereview.appspot.com/365840043/diff/80001/scm/modal-transforms.scm File scm/modal-transforms.scm (right): https://codereview.appspot.com/365840043/diff/80001/scm/modal-transforms.scm#... scm/modal-transforms.scm:324: (sorted (sort pitches ly:pitch<?))) Shouldn't you consider preexisting octavation for sorting the pitches? https://codereview.appspot.com/365840043/diff/80001/scm/modal-transforms.scm#... scm/modal-transforms.scm:331: (ly:music-set-property! e 'pitch p)) That looks like a mess. You juggle the pitches of the notes without changing the notes themselves. Won't this break the assignment of articulations and octavation to the notes/pitches? Don't you rather intend to sort the _notes_? https://codereview.appspot.com/365840043/diff/80001/scm/modal-transforms.scm#... scm/modal-transforms.scm:337: (list-set! elts count-from list-set! here is unnecessary since ly:music-transpose modifies its argument.
Sign in to reply to this message.
Address David’s comments. (Well, most.)
Sign in to reply to this message.
On 2019/01/23 22:30:25, dak wrote: > Shouldn't you consider preexisting octavation for sorting the pitches? Duh. > That looks like a mess. > Don't you rather intend to sort the _notes_? Sure. I figured in a chord, notes wouldn’t carry individual properties… but they do, of course. > list-set! here is unnecessary since ly:music-transpose modifies its argument. I can’t figure out how to make it work without resetting the EventChord’s elements list. How would you proceed? Thanks for the review! V.
Sign in to reply to this message.
On 2019/01/28 20:02:53, Valentin Villenave wrote:
> I can’t figure out how to make it work without resetting the EventChord’s
> elements list. How would you proceed?
Without any pointer to what you are having problems with, this is essentially
"do it yourself". Sigh. I don't even understand what those interfaces are
supposed to be good for so I at least changed the internals to stop chaotically
mixing directions and counts. The user-level commands remain as chaotic as I
find them to be.
Try this patched-up variant of code posted in the mailing list.
%%%%%%%%%%%%%%%%%%%%%%%%%
\version "2.21.0"
#(define-public (move-chord-note n octs)
(_i "Transpose a note (numbered as @var{n}) by @var{octs} octaves.
@var{n} is zero-based and can be negative to count from the end.")
(lambda (music)
(define (proper-pitch note)
(let* ((oct (ly:music-property note 'octavation))
(pitch (ly:music-property note 'pitch)))
(if (number? oct)
(ly:pitch-transpose pitch (ly:make-pitch oct 0))
pitch)))
(if (music-is-of-type? music 'event-chord)
(let* ((elts (extract-typed-music music 'note-event))
(l (length elts))
;; if direction is up, count from the bottom note upward,
;; if direction is down, count from the top note downward.
(count-from (if (negative? n) (+ l n) n))
;; Notes may not have been entered from bottom to top;
;; extract the pitches and put them in order.
(notes (sort-list elts
(lambda (a b)
(ly:pitch<? (proper-pitch a) (proper-pitch b))))))
(if (< -1 count-from l)
(let* ((note (list-ref elts count-from))
(oct (ly:music-property note 'octavation 0)))
(ly:music-transpose note (ly:make-pitch octs 0))
(set! (ly:music-property note 'octavation) (+ oct octs))))))
music))
dropNote =
#(define-music-function (num music) (integer? ly:music?)
(_i "Drop a note of any chords in @var{music}, in @var{num}
position from above.")
(music-map (move-chord-note (- num) -1) music))
raiseNote =
#(define-music-function (parser location num music) (integer? ly:music?)
(_i "Raise a note of any chords in @var{music}, in @var{num}
position from below.")
(music-map (move-chord-note (1- num) 1) music))
invertChords =
#(define-music-function (num music) (integer? ly:music?)
(_i "Invert any chords in @var{music} into their @var{num}-th position.
(Chord inversions may be directed downwards using negative integers.)")
(let loop ((num num) (music music))
(cond ((zero? num) music)
((negative? num) (loop (1+ num) (dropNote 1 music)))
(else (loop (1- num) (raiseNote 1 music))))))
ac =
\chordmode {
\dropNote 2 c:maj
\raiseNote 1 d:m7
\invertChords 2 e:m7
}
<<
\chords { \ac }
{
<>^\markup \sans "(should be: C△, Dm7 and Em7)"
\ac \bar "||"
}
>>
%%%%%%%%%%%%%%%%%
Sign in to reply to this message.
On 2019/01/28 21:53:04, dak wrote:
> On 2019/01/28 20:02:53, Valentin Villenave wrote:
>
> > I can’t figure out how to make it work without resetting the EventChord’s
> > elements list. How would you proceed?
>
> Without any pointer to what you are having problems with, this is essentially
> "do it yourself". Sigh. I don't even understand what those interfaces are
> supposed to be good for so I at least changed the internals to stop
chaotically
> mixing directions and counts. The user-level commands remain as chaotic as I
> find them to be.
>
> Try this patched-up variant of code posted in the mailing list.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%
>
> \version "2.21.0"
>
> #(define-public (move-chord-note n octs)
> (_i "Transpose a note (numbered as @var{n}) by @var{octs} octaves.
> @var{n} is zero-based and can be negative to count from the end.")
> (lambda (music)
> (define (proper-pitch note)
> (let* ((oct (ly:music-property note 'octavation))
> (pitch (ly:music-property note 'pitch)))
> (if (number? oct)
> (ly:pitch-transpose pitch (ly:make-pitch oct 0))
> pitch)))
Well, considering the way invertChords is written, this should likely just be
(define (proper-pitch note) (ly:music-property note 'pitch))
since "octavation" is only informational without affecting the pitch. Thinko,
sorry.
By the way, I find it somewhat strange that the code discussion on the user list
as well as the patch progress here completely ignore this contribution. After
all, it was solicited.
Sign in to reply to this message.
On 2019/01/20 11:29:01, Valentin Villenave wrote: > Ugh. Should be "raise" rather than "rise".
Sign in to reply to this message.
On 2019/01/30 08:20:43, japaipy wrote: > On 2019/01/20 11:29:01, Valentin Villenave wrote: > > Ugh. Should be "raise" rather than "rise".
Sign in to reply to this message.
Rebase, and use rewritten function
Sign in to reply to this message.
On 2019/01/28 21:53:04, dak wrote: > Without any pointer to what you are having problems with, this is essentially > "do it yourself". David, there seems to be some misunderstanding here (aside from your usual snark :-) My question was only addressing your comment with regard to (list-set! ) being unnecessary; prior to that, I had addressed all of your remarks and uploaded an updated function that was entirely working, without any need for additional work on your part. So, you could hardly blame me for letting you do all the work where I did, precisely, produce working (if inelegant) code. > Sigh. I don't even understand what those interfaces are > supposed to be good for I’m not exactly sure myself (I wasn’t the OP). But I do know that I sometimes use chordmode to produce basic accompaniment written on staves, and there’s little doubt that enabling additional voicings will be occasionally useful to me. Since we’ve always supported chordmode as a shorthand for writing chords on staves (and not only chord names), it’s a rather nice additional feature to offer. > so I at least changed the internals to stop chaotically > mixing directions and counts. The user-level commands remain as chaotic as I > find them to be. Well, now I have to use your code (how could I not, since it has the same feature set than what I laboriously came up with, but with only half the LOC count). However, again, please note that from the user-exposed side, you didn’t have to do that (even though I am thankful for it). > Well, considering the way invertChords is written, this should likely just be > (define (proper-pitch note) (ly:music-property note 'pitch)) > since "octavation" is only informational without affecting the pitch. Thinko, > sorry. Oh, indeed. (I shall refrain myself from noticing out loud that _my_ last version didn’t have that bug -- of course then again, it probably took me more time to write it than what you’d need to rewrite half our codebase :-) > By the way, I find it somewhat strange that the code discussion on the user list > as well as the patch progress here completely ignore this contribution. After > all, it was solicited. It is strange, through no fault of my own. I did post a link to both Allura and Rietveld: https://lists.gnu.org/archive/html/lilypond-user/2019-01/msg00407.html and I even asked on the list when my first draft produced unwanted behavior. V.
Sign in to reply to this message.
Use sorted note list to select the correct note.
Sign in to reply to this message.
https://codereview.appspot.com/365840043/diff/130001/ly/music-functions-init.ly File ly/music-functions-init.ly (right): https://codereview.appspot.com/365840043/diff/130001/ly/music-functions-init.... ly/music-functions-init.ly:609: (let loop ((num num) (music music)) Come to think of it, using a loop here is a bad idea. Instead an additional count should likely be passed to the worker function in music-functions.scm and that one called directly. The reason is that raising or lowering one chord note by an octave does not guarantee that it ends up at the far end of the chord, like when using invertChords on a c:11 chord for the fifth inversion.
Sign in to reply to this message.
On 2019/02/01 16:18:10, dak wrote: > raising or lowering one chord note > by an octave does not guarantee that it ends up at the far end of the chord, > like when using invertChords on a c:11 chord for the fifth inversion. Oh. Then this becomes a whole other can of worms; what should be the correct inversion of an 11th chord? Should <c' e' g' b' d'' f''> become <e' g' b' d'' f'' c'''> (as you seem to suggest) or <e' g' b' c'' d'' f''> (as the current code produces)? I’ll ask on the list as well. V.
Sign in to reply to this message.
On Feb 2, 2019, at 14:36, v.villenave@gmail.com wrote: > Oh. Then this becomes a whole other can of worms; what should be the > correct inversion of an 11th chord? > > Should > <c' e' g' b' d'' f''> > become > <e' g' b' d'' f'' c'''> (as you seem to suggest) > or > <e' g' b' c'' d'' f''> (as the current code produces)? Isn’t the salient property of an inversion simply which note is lowest in pitch? (It has been a long time since I studied music theory.) If so, both of those fit, as does the chord resulting from lowering the e' by an octave. Does it help to ask how a music theoretician describes the expected result of inverting a chord a number of times equal to the number of notes in the chord? Your examples would differ by an octave after that. Speaking as a software designer, if you have implemented a useful function that is more limited than the conventional musical concept of inversion, consider giving it a different name—one that is descriptive without being misleading. Regards, — Dan
Sign in to reply to this message.
On 2/2/19, Dan Eble <dan@faithful.be> wrote: > Isn’t the salient property of an inversion simply which note is lowest in > pitch? (It has been a long time since I studied music theory.) If so, both > of those fit, as does the chord resulting from lowering the e' by an octave. David was more specifically referring to the 5th inversion of an 11th chord, and I *think* I’m starting to get his point: even if <e' g' b' c'' d'' f''> is acceptable, then you get to <g' b' c'' d'' e'' f''> and <b' c'' d'' e'' f'' g''> and this is where things start to get weird: <c'' e'' e'' f'' g'' b''> If the algorithm continues blindly by only taking into account the previous state rather than the initial state, you then find yourself with a so-called inversion where the bass note is actually the root note again, i.e. not an inversion, and you’ll never get to a point where either d'' or f'' can become the bass note. Instead we should be aiming for something aikin to <d'' e'' f'' g'' b'' c'''> which means that the c'' has to be moved again. (IIUC, again.) > Speaking as a software designer, if you have implemented a useful function > that is more limited than the conventional musical concept of inversion, > consider giving it a different name Sure, but that’s not the point at all. We certainly do want proper inversions here. Thanks for the input, that was helpful! And I think I get David’s point after all… Cheers, V.
Sign in to reply to this message.
> On 2 Feb 2019, at 20:36, v.villenave@gmail.com wrote: > > On 2019/02/01 16:18:10, dak wrote: >> raising or lowering one chord note >> by an octave does not guarantee that it ends up at the far end of the > chord, >> like when using invertChords on a c:11 chord for the fifth inversion. > > Oh. Then this becomes a whole other can of worms; what should be the > correct inversion of an 11th chord? > > Should > <c' e' g' b' d'' f''> > become > <e' g' b' d'' f'' c'''> (as you seem to suggest) > or > <e' g' b' c'' d'' f''> (as the current code produces)? > > I’ll ask on the list as well. A music dictionary says an inversion of a chord is done by raising the lowest note to a higher octave. Thus, the chord has as many inversions as pitch classes, excluding the root.
Sign in to reply to this message.
Hans Åberg <haberg-1@telia.com> writes: >> On 2 Feb 2019, at 20:36, v.villenave@gmail.com wrote: >> >> On 2019/02/01 16:18:10, dak wrote: >>> raising or lowering one chord note >>> by an octave does not guarantee that it ends up at the far end of the >> chord, >>> like when using invertChords on a c:11 chord for the fifth inversion. >> >> Oh. Then this becomes a whole other can of worms; what should be the >> correct inversion of an 11th chord? >> >> Should >> <c' e' g' b' d'' f''> >> become >> <e' g' b' d'' f'' c'''> (as you seem to suggest) >> or >> <e' g' b' c'' d'' f''> (as the current code produces)? >> >> I’ll ask on the list as well. > > A music dictionary says an inversion of a chord is done by raising the > lowest note to a higher octave. The question was _which_ higher octave. > Thus, the chord has as many inversions as pitch classes, excluding the > root. The cases discussed concerned were exactly those where raising to _some_ higher octave did not retain circular pitch order and thus the number of inversions turned out _different_. Thus "Thus" is a non sequitur. -- David Kastrup
Sign in to reply to this message.
> On 2 Feb 2019, at 22:44, David Kastrup <dak@gnu.org> wrote: > > Hans Åberg <haberg-1@telia.com> writes: > >>> On 2 Feb 2019, at 20:36, v.villenave@gmail.com wrote: >>> >>> On 2019/02/01 16:18:10, dak wrote: >>>> raising or lowering one chord note >>>> by an octave does not guarantee that it ends up at the far end of the >>> chord, >>>> like when using invertChords on a c:11 chord for the fifth inversion. >>> >>> Oh. Then this becomes a whole other can of worms; what should be the >>> correct inversion of an 11th chord? >>> >>> Should >>> <c' e' g' b' d'' f''> >>> become >>> <e' g' b' d'' f'' c'''> (as you seem to suggest) >>> or >>> <e' g' b' c'' d'' f''> (as the current code produces)? >>> >>> I’ll ask on the list as well. >> >> A music dictionary says an inversion of a chord is done by raising the >> lowest note to a higher octave. > > The question was _which_ higher octave. The one of your choice. >> Thus, the chord has as many inversions as pitch classes, excluding the >> root. > > The cases discussed concerned were exactly those where raising to _some_ > higher octave did not retain circular pitch order and thus the number of > inversions turned out _different_. Thus "Thus" is a non sequitur. Apparently, one does not distinguish between those in classical harmony, only the pitch classes, thus.
Sign in to reply to this message.
>> like when using invertChords on a c:11 chord for the fifth inversion.
>
> Oh. Then this becomes a whole other can of worms; what should be the
> correct inversion of an 11th chord?
>
> Should
> <c' e' g' b' d'' f''>
> become
> <e' g' b' d'' f'' c'''> (as you seem to suggest)
> or
> <e' g' b' c'' d'' f''> (as the current code produces)?
If I understand correctly, the same problem already arises with c:9,
that is, as soon as the given chord voicing spans more than an octave.
But the problem is much more general: "inversion", when only applied to
chords given as stacks of thirds, is as artificial a concept as the
stacks-of-thirds themselves, for as you know, real chords (sets of
pitches) have an arbitrary distribution of their pitch classes to actual
pitches, including doublings of pitch classes (maybe even doublings of
actual pitches).
You might argue that this is not about real chords but about "idealized"
chord representations, but then it's not at all obvious *what* the
precise class of chord representations should be that a chord-inversion
function should operate on. ({Stacks-of-thirds}, {chords with range < 1
octave} etc. all do not work.)
Tbh, I'm not quite sure what the useful applications of a function
\invertChord might be, anyway, but I would expect that the two obvious
interpretations:
a) raising the lowest sounding pitch by one or more octaves in order to
become the new highest sounding pitch,
b) raising the lowest sounding pitch by exactly one octave
both might be sensible and should be supported - ideally using two
different functions (e.g. \invertChord, \invertChordII). (And this still
does not take into account the possibility of <c' c' e'> which is a
perfectly valid chord e.g. in a 3-part setting in homophonic notation.)
(Ceterum censeo: The whole concept of chord positions arising by
"inverting" a chord is not as useful as it is widespread, anyway,
because it leads to the frequent mis-conception that different chord
positions can't have the same upper voice. In my theory classes, chord
positions are always written either in a two-staff-piano system with a
clearly distinguished bass note, or in an abstract reduction "all pitch
classes mapped into the octave above the bass pitch" - for want of a
better term, I call it "compact voicing" with the convention that it
always be written in bass clef - that lends itself easily to being
encoded as bass figures[1]. And of course the same philippika might be
repeated from the point of view of melody notes instead of bass notes...)
Best
Lukas
[1] With the exception of bass figures > 8, of which only "9" is used
regularly.
Sign in to reply to this message.
> On 3 Feb 2019, at 00:04, Lukas-Fabian Moser <lfm@gmx.de> wrote: > > If I understand correctly, the same problem already arises with c:9, that is, as soon as the given chord voicing spans more than an octave. > > But the problem is much more general: "inversion", when only applied to chords given as stacks of thirds, is as artificial a concept as the stacks-of-thirds themselves, for as you know, real chords (sets of pitches) have an arbitrary distribution of their pitch classes to actual pitches, including doublings of pitch classes (maybe even doublings of actual pitches). I think the concept originally comes from the Just major triad 4:5:6, which has the property that the lowest difference tone in root position and inversions is the root of the chord, so the ear still hears a major chord in root position in the inversions, though the root is weak. It is not true for the minor chord. But then the concept has been extended to any chord because it is useful when assigning the pitches, even though it clearly changes the character depending on choice.
Sign in to reply to this message.
Handle chords larger than one octave.
Sign in to reply to this message.
On 2019/02/02 20:37:16, dan_faithful.be wrote: > Isn’t the salient property of an inversion simply which note is lowest in pitch? I think the point of inversions is not to rearrange pitches inside a chord, but to change the limits of the chord by changing *both* the highest and the lowest note. (I’m siding with Lukas’s #1 definition.) Which could also be said of so-called `voicings’, in a way: the point of \dropNote 2 <c' e' g' b' d'' fis''> would hardly be to get <c' d' e' g' b' fis''> in return, but rather <d c' e' g' b' fis''> much like a suspended chord (the whole point of `drop n’ transformations being to change the bass note). Hence my latest proposal, that does exactly that (and therefore comes back to the UP/DOWN direction arg that David wanted to do away with). Cheers, V.
Sign in to reply to this message.
> much like a suspended chord (the whole point of `drop n’ transformations > being to change the bass note). This statement surprises me. I always thought of 'drop n' (with 'drop 2' being the most common one) as a means to transform closed-harmony _upper_ voices into open harmony _upper_ voices, without changing the bass at all. (Which is consistent with the notion that the differentiation between closed vs. open harmony only is concerned with the upper voices, so <c e' g' c''> is a closed harmony voicing with drop-2 variant <c g e' c''>.) But it might be that it's just different stylistic 'homelands' showing up here, in my case, a mostly classical basso continuo-background. Lukas
Sign in to reply to this message.
> On 2 Feb 2019, at 21:37, Dan Eble <dan@faithful.be> wrote: > > Isn’t the salient property of an inversion simply which note is lowest in pitch? A formal description might be: A chord is a set of pitch classes numbered 0, 1, 2, …, for the root 0 and inversions 1, 2, …. A realization of an inversion in pitches selects as representative the lowest note; there might preferences for the others pitch classes in the chord, but in principle, they could be put in any octave if only above the inversion pitch. So the chord <C> <D> <E> <G> might be numbered 0 3 1 2 and then it is C9 with the 7th removed, or 0 1 2 3 which is C with the 2nd added. An inversion might renumbered and then becomes another chord.
Sign in to reply to this message.
On 2/3/19, Lukas-Fabian Moser <lfm@gmx.de> wrote: > This statement surprises me. I always thought of 'drop n' (with 'drop 2' > being the most common one) as a means to transform closed-harmony > _upper_ voices into open harmony _upper_ voices, without changing the > bass at all. I see what you mean (and I did share your surprise when, also coming from a classical/baroque background, I first started hanging out with jazzmen: for example referring to `drop n’ voicings by counting notes from the _uppermost_ remains absolutely baffling to me). Much like continued bass, what we’re dealing with here is the "right hand" positions, which most certainly does not affect the bass line, except in jazz music it will typically be played by the _left_ hand (or with both hands) whilst the actual bass line (often heavily anchored in root notes, much more so than in baroque music) is left to the bass player. In this regard, what I referred to as "changing the bass note" would actually be better phrased as "changing the lowest note played by the guy in charge of chords, regardless of what the global bass note will be". At least, that’s my understanding of how jazz music is conceptualized, which YMMV with. BTW, there’s no proper notion of inversions as such in jazz music (AFAICT); so the purpose of an \invertChords function here is left to our appreciation, with the minimal requirement being that the lowest note of the chord changes each time -- but traditionally, I think the lowest note of the previous inversion *should* become the highest note of the next inversion (and reciprocally when proceeding in reverse). If that means moving said note by two octaves instead of just one, then so be it (IMO). (And yes, I need to stop using acronyms in every sentence :-) Regards, V.
Sign in to reply to this message.
>> This statement surprises me. I always thought of 'drop n' (with 'drop 2' >> being the most common one) as a means to transform closed-harmony >> _upper_ voices into open harmony _upper_ voices, without changing the >> bass at all. > [...] > > Much like continued bass, what we’re dealing with here is the "right > hand" positions, which most certainly does not affect the bass line, > except in jazz music it will typically be played by the _left_ hand > (or with both hands) whilst the actual bass line (often heavily > anchored in root notes, much more so than in baroque music) is left to > the bass player. In this regard, what I referred to as "changing the > bass note" would actually be better phrased as "changing the lowest > note played by the guy in charge of chords, regardless of what the > global bass note will be". At least, that’s my understanding of how > jazz music is conceptualized, which YMMV with. Yep, I think we can absolutely agree on that. (This reminds me of the famous virtual sing-post that some teachers like to attach to everything below c on the piano: "Keep off here - there's a bass player around!") I just wanted to point out that IMO it's not helpful to call the lowest sounding pitch played by one specific non-bass instrument (i.e. the piano) the "bass" note. > BTW, there’s no proper notion of inversions as such in jazz music > (AFAICT); so the purpose of an \invertChords function here is left to > our appreciation, with the minimal requirement being that the lowest > note of the chord changes each time -- but traditionally, I think the > lowest note of the previous inversion *should* become the highest note > of the next inversion (and reciprocally when proceeding in reverse). > If that means moving said note by two octaves instead of just one, > then so be it (IMO). Agreed - I just might add that, IMHO, as I tried to point out, the concept of chord positions arising "by inversion" is not that helpful in a classical context, either. By this, I do not mean that a 6-chord shouldn't be derived from a root-position chord containing the same pitch classes (even if that notion came up comparatively late in the history of music theory - probably as late as Rameau). Rather, even if one considers <e, c g c'> as being derived from an abstract c major chord, which of course is absolutely adequate in most situations[1] at least for everything from Baroque and later ages, I do not think that one should think of it as having arisen from some actual chord voicing by a procedure like "inversion". Lukas [1] More specifically, situations where chords do not arise by contrapuntal voice-leading patterns.
Sign in to reply to this message.
On Feb 3, 2019, at 05:36, Valentin Villenave <v.villenave@gmail.com> wrote: > > BTW, there’s no proper notion of inversions as such in jazz music > (AFAICT); so the purpose of an \invertChords function here is left to > our appreciation, with the minimal requirement being that the lowest > note of the chord changes each time -- but traditionally, I think the > lowest note of the previous inversion *should* become the highest note > of the next inversion (and reciprocally when proceeding in reverse). > If that means moving said note by two octaves instead of just one, > then so be it (IMO). As a LilyPond function, are there disadvantages to calling this “rotation” rather than “inversion”? While it is true that this algorithm yields chords that people call inversions, it does not yield every chord that might be so called. You could have an index entry for “inversion” which refers to the rotation command, and you will avoid questions from users assuming that an inversion command ought to do more it does. Regards, — Dan
Sign in to reply to this message.
On 2019/02/03 14:59:03, dan_faithful.be wrote: > While it is true that this algorithm yields chords that people call inversions, > it does not yield every chord that might be so called. Huh. Not having learned music theory in an English-speaking environment, I must say I’m at a bit of a loss when I see these referred to as "inversions" anyway (which they’re really not). However, it’s my understanding that this is their sort-of-official name; whereas "chord rotations", whilst making sense in a way, doesn’t seem to register as usual musical lingo (a cursory DuckDuckGo search mainly returns engineering and seismology results). Also, please note that the command we’re discussing here isn’t \inversion (that’s an already-existing, and aptly-named, LilyPond command), but \invertChords. And somehow, \rotateChords would sound a bit like a misnomer to me (I’d expect it to change the order of the intervals *inside* the chord, whilst preserving the same lowest and highest note -- perhaps it’s because I’m used to literally "rotating" chords in a 2D-plane when representing pitches in a Tonnetz). That being said, no problem for adding index entries no matter what we end up choosing. Would anyone else have thoughts on the subject of \invertChords vs \rotateChords? Thanks! V.
Sign in to reply to this message.
On Feb 7, 2019, at 14:49, v.villenave@gmail.com wrote: > > That being said, no problem for adding index entries no matter what we > end up choosing. Would anyone else have thoughts on the subject of > \invertChords vs \rotateChords? So that it’s clear: I have no firm objection to \invertChords. I just wanted to make sure that the names were well explored. Regards, — Dan
Sign in to reply to this message.
On 2019/02/08 03:48:31, dan_faithful.be wrote: > So that it’s clear: I have no firm objection to \invertChords. I just wanted to > make sure that the names were well explored. OK then, pushed as https://git.savannah.gnu.org/cgit/lilypond.git/commit/?id=0f5c0468117ae099164... Thanks to everybody! V.
Sign in to reply to this message.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
