RFC: working on making chord naming/chordList more consistent

a couple more updates, I went back to the drawing board to redo my workflow so that I could separate breaking changes, dependent changes, etc so all the github links above don't really apply anymore (they still exist, but link to unattached forks).

I've made three PRs now,

  1. Adding domN and addN chords - merged
  2. Sorting and consistent naming changes - pending merged
  3. Add open voicing for chords 'o option - pending merged

None of these include any breaking changes, so I'm hoping they'll be acceptable to add to the next minor release (1.7.2).

...and with that, I think I've met the initial improvement targets. I've got a good idea of where I'll be heading from here, based on the comments, I think everyone is in agreement with that direction, namely:

  1. allow stacking of chord modifiers (ie 'maj7'ii'o'10 should work as expected) Issue #777
  2. add dropN notation (ie 'maj7'd2) @Raph
  3. update inversion notation in line with drop notation (ie 'maj7'i2 for second inversion) @RTylerMclaughlin
  4. allow patterning of the chord modifiers (eg 'maj7'i<2 3 4>) @kit-christopher Issue #620
  5. allow "exploding" chords ie spreading them over N octaves @Raph
  6. consider adding complementary functions for each of these modifiers (ie invert 2 "0'maj7" as a complement to "0'maj7'i2") @ghales
  7. define our own pitch collections on the fly, so that they can be manipulated/patterned in the same way as our predefined chords @Raph @wshbmusic

I would call these the intermediary steps, before we head into @jwaldmann's semantics territory -

If I get through this batch on my own, I will be in far better shape skill-wise to consider attacking the semantics application ... wish me luck! :slight_smile:

12 Likes