RFC: working on making chord naming/chordList more consistent

Innards
61

Hi all,
I apologise for a complete and utter lack of movement here - 2022 has been the wrong kind of exciting for me and I've simply had to let stuff slide, this included. @mrreason 's done some work in this area recently, so I figure an update is warranted.

I spent a bit of time discussing and working out how to recursively parse the chord modifiers, I came up with this code:

this is behaving as I would expect, you can pass it any combination of any number of chord modifiers, it will crash if you pass it an unknown option :

modsFunc :: [Float] -> [String] -> [Float]
modsFunc xs [] = xs
modsFunc xs ["o"] = if (length xs > 2)
                      then [ (xs !! 0 - 12), (xs !! 2 - 12), (xs !! 1) ] ++ reverse (take (length xs - 3) (reverse xs))
                    else xs
modsFunc xs ['i' : is] =  take (length xs) $ drop ((length is) + 1) $ concatMap (\x -> map (+ x) xs) [0,12..]
modsFunc xs [m] = if (length xs > (read m :: Int)
                    then take (read m :: Int) xs
                  else xs
modsFunc xs ms = modsFunc (modsFunc xs (init ms)) [(last ms)

you can call it as per: modsFunc [0,2,4,6] ["ii", "o", "12"] where the chord is the first list, and the modifiers sit in the second list, in any order

If you're interested in checking out the discussion that got to this point, please see:

@yaxu had some recommendations for parsing differently which I was planning to explore but have been unable to do so after more than a year :frowning:

If anyone would like to pick this up, be my guest!

2 Likes
62

yes i also think this would be a good way to do it.

i think we would have to follow these steps:

  • First introduce a good data structure representing chords data Chord = ..
  • write a parser for it (for a given string input like "c'maj7'ii" yields a Chord
  • implement the semantics (a function Chord -> [Double])
  • integrate the parser with the mini parser
  • integrate the semantics (TPat Chord -> Pattern Double)

imo the hardest part is to define a good date structure that is flexible enough to handle new modifiers in the future

1 Like
63

Just a quick my-two-bits drive-by: Parsec / AttoParsec / MegaParsec is almost surely the way to go.

TBH I wouldnā€™t be too worried about the data structure, as the grammar itself is rather more important in terms of design (though in this case largely already settled, unless thereā€™s some need/want of a change in grammar.) The code around the resulting data structure can easily-enough lean hard into the type system for confident maintenance and expansion.

1 Like
64

ok, I spent a bit of time to implement the following:

I first tried to do it via a data structure Chord but that wasn't really leading me anywhere, so I added a node to TPat, specifically for chords, made a simple sum type for Modifiers. Then i implemented parsers for the modifiers and lastly a function

chord :: (Num a, Enum a) => Pattern a -> Pattern String -> [Pattern [Modifier]] -> Pattern a

that can turn given patterns of notes/doubles, a pattern of chord names and a list of patterns of modifiers into a single combined pattern that represents the specified chord. An example:

chord "c" "<maj min>" ["i","10"] :: Pattern Note is equivalent to "c'<maj min>'i'10" :: Pattern Note.

what this means in summary is that all of the old features should still behave the same, but now you can also do most of the things that were collected in this thread (patterning everything, stacking modifiers, dropN notation, new inversion syntax).

my changes also seperated the syntax and semantics more clearly, at the expense of a more tricky TPat type, depended on some language extensions.

It would be great if some people could look at the code and let me know what they think.
Also some people testing the code would be perfect (clone the repo and cabal repl, then import Sound.Tidal.Context and :set -XOverloadedStrings when in the repl, then you can type expressions like note "c'maj'i" and try to generate some unexpected result)

3 Likes
65

I apologise for not replying back here (or doing adequate testing), this year blew up on me a bit.

I do just want to say thankyou though, this was a big feature I was interested in and I'm finally getting some time to do some experimentation and play, and they have opened a world of possibilities :pray:

I've spent some time documenting the changes too, which should end up on this page shortly:
https://tidalcycles.org/docs/reference/harmony_melody

The only quirk I came across is to do with the list ordering used in conjunction with arpeggiating functions -

For example:

c'min9 == [0,3,7,10,14]

Grow it to 8 notes:

c'min9'8 == [0,3,7,10,14,12,15,19]

you can see that the numbers are no longer ordered small to large - this doesn't matter for chord usage, but it does create an effect when arpeggiating the chord (no longer running low to high)

This is not specifically a bug, but it was a bit unexpected when I encountered it.

Should it be in numerical order? What do other people think?

3 Likes
66

I think there is no disadvantage in always ordering the chords since we're dealing with note values and not pitch-classes :slight_smile: could you please open an issue about it so we don't forget?

2 Likes
67

Done! Thanks again :slight_smile:

1 Like
68

I'm not sure about this. The ordering [0,3,7,10,14,12,15,19] is quite logical to me:

It first starts with the chord notes c'min9 = c,ef,g,bf,d on one octave, then it starts with the same chord on the next octave, c, ef, g. If I was arpeggiating this chord on the piano, I'd probably do it this way.

After reordering, the d is like the second note on the scale (like a sus2) rather than the ninth.

69

Wishing you all the best, @cleary!! Thanks a lot for even starting the conversation :slight_smile:
Makes me excited about the future of tidal

ps. +1 for ordering chords - it makes things like arp easier to reason about

1 Like