Kieren MacMillan <kieren_macmil...@sympatico.ca> writes: > Hi David, > >> Here's my take on how to do this more transparently: first have an >> engraver that does the basic chord analysis and writes one or several >> properties with the basic analysis results (like fundamental pitch and >> scale offsets). Those properties are made part of text-interface. >> >> Then have several markup commands producing output based on those >> properties. Like German chord names, or a markup list with >> modifications and stuff like that. And then you can basically create >> one fixed markup for each chord naming style and assign that to the >> "text" field of a ChordName. >> >> Also it then becomes easy to put chord names into a TextScript > > That all sounds great. If the engraver broke the chord components into > the smallest possible bits (e.g., root, quality, third stack, > alterations, bass or inversion), then the NameBuilder (or whatever) > could format those however one pleased. > > However, I’m also concerned that the current input syntax isn’t rich > enough. For example, one can’t tell Lilypond “at run time" if <c d f > bf> should be labelled as Bb/C or C7(sus2,sus4). [Note that, at this > point, I don’t care what anyone’s preference for display of this chord > is — I’m simply pointing out that I don’t know of a mechanism to force > Lilypond to label the same set of notes two or more different ways.]
The engraver would convert <c d f bf> into something akin to c c' d' f' bf' (somewhat opaque example since the first is the root pitch and the others are the relation to the root note, expressed as intervals from c'). There would be one or several markups for interpreting the c' d' f' bf' part of the list. And likely some exceptions mechanism. So yes, configurability would still be a hand-wavy thing. But it would be quite clear how to assemble one's own solution from scratch and what building blocks were available for it. The current situation also offers "from scratch" assembly, but there are basically no useful building blocks or recognizable mechanisms. > So we should attack the input mode as well, to support the widest and > most flexible possible usage. It's a feature rather than a bug that LilyPond tries to avoid passing information via anything but the chord pitches: that way you can get sensible labelling of chords not entered via chordmode. This is not complete: some special properties come into play in order to allow for inversions to be labelled relative to the purported root note rather than the nominally lowest note. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user