Le 28/11/2022 à 15:37, Kieren MacMillan a écrit :
Hi Koen,I still think it could be nice to try to write a longer-term solution.There has been a lot of work done on chord naming over the last decade, mainly as part of a Google Summer of Code project a few years ago, but essentially none of it has yet navigated through the patch submission process. There are lots of people who think it would be nice to write a long-term solution — it just keeps getting stalled (for various reasons). <sigh>Do you think there would be any interest in specifying the chord suffixes like that, directly from markup?Not sure if I can speak for anyone else, but my interest is (and has always been) in having a robust, unified system with a clean UI that handles most (if not all) of the main use cases.in the specific use case of printing a harmonic background, the layer of calculating chords from internal pitches is redundant anyway. There are many ways to think about a chord, and I change the way I think about them all the time: I just want to write it down and I don't need LilyPond to reason about it. :) (Although a root and a bass note are still useful.)Make sure you’re up to speed on what’s been done in this area, since some of the groundwork may be complete. And of course there are good reasons that Lilypond has the calculating chords layer — the thing we all want (I think?) is to add functionality without losing what’s already there!
I am not up to speed myself on the various brainstormings that happened over the years. What I can at least tell is that the ideas floating around for a unified note/chords mode are relatively orthogonal to this discussion, as far as I understand them. The advantages of a unified mode would be a) less syntax to learn b) making it more convenient to enter, e.g., piano music, by making it easy to use \chordmode-like entry for a chord that appears in the middle of a melody (no chord names involved here). So it’s more about applying \chordmode syntax to non-chord-names use cases. The other piece of brainstorming I know about, although I didn’t chase all the discussions in the devel mailing list, is the GSoC patch. This has the same goal of making it easier to coerce LilyPond into formatting chord namesthe way you want, but does so with a different approach: remember the details
of how the chord was entered in \chordmode, so that the chord formatting is closer to the input. Compared to just adding chord symbols with \markup, that has the advantage that LilyPond understands what the chords are actually made of, and the disadvantage that it can still be cumbersome to teach LilyPond how to format the chords the way you want. I don't typeset chord names myself, I don't really know how strong the arguments are for each side. Maybe there's a place for both, maybe not. At any rate, as opposed to the chord semantics GSoC approach, it would be rather straightforward implementation-wise to make LilyPond understand arbitrary chord symbols, as shown in the code from my original reply. Jean
OpenPGP_signature
Description: OpenPGP digital signature
