Hi Carl! Do you remember off-hand how polychords were handled in the GSoC code? What was the syntax? Could it handle more than two in the stack? etc.
Thanks, Kieren. > On Aug 9, 2022, at 11:14 AM, Kieren MacMillan <[email protected]> > wrote: > > Hi Valentin, > >> In my opinion the main issue here is that the chord naming strategy >> of first transforming theoretical respesentation of a chord into >> a bunch of notes to then have some function try to make sense >> of that and turn in again into a theoretical representation of a chord >> is absolute madness if we do actually already know how this chord should >> look. >> >> Suppose we had a different way of specifying chords not as a bunch of notes, >> but in a representation that preserves the theoretical meaning of such a >> chord. > > The GSoC chord work was moving in exactly that direction! > >> This way we could have a transposable syntax to say e.g. des|c > > Well, we wouldn't want to overload the bar-check feature, of course! ;) > > Maybe you're interested in picking up the GSoC chord ball and taking it > across the goal line? In mid-September, I might have a little more bandwidth > to sit down with Carl again and try it myself… but given my track record, I'd > be more optimistic about the outcome if there were multiple developers > working with me. > > Cheers, > Kieren.
