[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: polychords: what's the current state-of-the-art?

From: Valentin Petzel
Subject: Re: polychords: what's the current state-of-the-art?
Date: Tue, 09 Aug 2022 13:27:02 +0200

Hi Lukas,

This snippet basically works by defining an Exception for each single Polychord 
structure you’re going to use. This is not even done in a systematic way, so 
you could easily add other Exceptions along the way. 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 

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. Then ChordNames would simply have to take care of formatting. In the 
current design we have a huge function that is responsible for both 
interpreting the notes as well as formatting the chord. The other way we could 
have two functions, one that formats chords and another that interprets notes 
as chords.

This way we could have a transposable syntax to say e.g. des|c to specify Db 
major over C major or even g|dis:m|cis:m or something and would be able to 
quickly get the chord specification we actually want, instead of having to do 
something like c:3.5.9-.11.13- or even something like this 


Am Dienstag, 9. August 2022, 12:28:25 CEST schrieb Lukas-Fabian Moser:
> Hi Kieren,
> > What's the current best snippet for rendering polychords? I know the GSoC
> > chord stuff is still in air traffic control, but the snippet found
> > at<
> > .txt>  definitely doesn't work, and is likely far from optimal given the
> > decade-plus of advances in the codebase.
> I don't have much time at the moment, but as a first pointer:
> The snippet worked as late as 2.18.2. What broke it after that is that
> the meaning of c1:5.9-.11.13- in chordmode has changed:
> \version "2.18.2"
> \chordmode {
>    c1:5.9-.11.13-
> }
> yields
> in 2.18.2, whereas in 2.19.83, it yields
> The culprit seems to be the added support for power chords: In 2.18.2,
> c1:5 generated a c major chord; now it only generates a power chord
> fifth. My guess would be that Valentin V.'s chord name cleanup in
> 78225bc1b386e12dc was the point when this changed.
> Lukas

Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]