> > I thought about using a chord exceptions file with \include, but it would > have to include every permutation of tensions and extensions being used.
Reading Carl's first email, I've thought of the same... but writing this file and configuring it would be a seven headed beast on its own. It's possible to develop this, but it would take some additional Scheme > programming. And there would ideally be some input on a few "standard" > display modes that are commonly used. > > Perhaps in April or May I will have some time to do work on this request. > That would be wonderful! Em qui., 25 de dez. de 2025 às 17:30, Carl Sorensen < [email protected]> escreveu: > > > On Thu, Dec 25, 2025, 1:22 PM Tim's Bitstream <[email protected]> > wrote: > >> I thought about using a chord exceptions file with \include, but it would >> have to include every permutation of tensions and extensions being used. It >> would sure be slick if it could be written like >> >> c1:7.(5+.9-.11.13) to be rendered as C7(#5 13 b9) >> > > Yes, it would be cool if that could be done. But that would require major > changes to the parser, as ( and ) would now have a new meaning. > > And it would require a special syntax for defining an output, rather than > an input, which is contrary to the way lilypond works. The chord is the > same as the one without the parentheses; only the display would be > different. > > The lilypond way would be to do something like: > > \override ChordName.alterationDisplayMode = #'parenthesize > > or > > \override ChordName.displayMode = #'parenthesizeAlterations > > And then the chord entry would be the same, but the displaed chord name > would be different. > > It's possible to develop this, but it would take some additional Scheme > programming. And there would ideally be some input on a few "standard" > display modes that are commonly used. > > Perhaps in April or May I will have some time to do work on this request. > Carl >
