I would like to second Raph's suggestion about including some new syntactic sugar for defining our own pitch collections on the fly. I think the strength of Tidal is in how it does things differently and is fun and responsive sandbox environment. It would be great to be able to quickly define these pitch collections and then be able to transform them with inversions and drop or open voicings as well. Currently the discussion on harmony has been tertiary focused but implementing something like what Raph describes would make working in quartal, quintal, and secundal harmonies far easier and more flexible.
Edit: Also on a related note has anybody had experience with Euterpea and/or reading the Haskell School of Music? http://euterpea.com/haskell-school-of-music/. I have been slowing going through this book and it is actually quite awesome how it takes you step by step through the process of creating Euterpea and is a decent (if fast paced) intro to Haskell programming. Anyway I'm reading it currently while trying to learn Haskell with "Learn You a Haskell", so I'll report back about anything interesting I find that might give us some insight into how to proceed.
Some great stuff in here! I've skimmed quickly, and plan to revisit in detail but I'll just call out a couple of highlights:
This is cool! I think this could be a good next step on my learning journey
The concept of arbitrary pitch collections is something that is very present in my head when I'm thinking about this stuff - a set of common use chord shortcuts, and then the ability to quickly define and modify arbitrary note collections as though they were a standard chord, is an endpoint I'm hoping to get to
This looks from the outside like something I will need to work through too - thanks a lot!
as a side note, I have a selfish interest in using this project to advance my haskell skills in order to contribute more, but I am interested in seeing what others are coming up with too and my time is extremely limited, so please feel free to work on and share stuff that will move us along
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).
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:
allow stacking of chord modifiers (ie 'maj7'ii'o'10 should work as expected) Issue #777
Nice one @cleary! I've merged the PRs. What could be really nice is having a list of expected mini-notation chords together with expected outputs. Then we can add that to the automated tests to catch regressions.
A quick update, I've procrastinated long enough and am looking at this again, beginning with the unit tests. I have a steep curve ahead, and it's slow going but if you're interested there's a branch here where I'm working:
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 :
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.
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)
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.