Hi Matthew (et al.),
> Request for "rootless slash chords”
> the user will enter something like
> \chordmode { c c/e c/g }
> to get the desired output of
> C /E /G
Definitely on my wish list.
> with LilyPond doing some kind of translation to not show roots when there's
> a slash, but what would make sense would be for the user to enter
> \chordtext { c /e /g }
> and get
> C /E /G
> That would be easy by directly printing the input with only formatting
> translations (I am counting the lowercase to uppercase conversion as
> formatting) and much harder with an attempt to go to notes and back in
> between.
Why, exactly?
input: c c/e c/g
throughput, step 1: <c e g> <e g c> <g c e>
throughput, step 2: “Oh! They’re the same chords consecutively, just in
different inversions! Let me check what the user prefers for output…”
throughput, step 3: “They’ve selected ‘rootless slash chords for two or more
consecutive rootless chords’ and ‘all caps’.”
output: C /E /G
Where precisely is the problem that arises in that translation to notes?
> it sure would be easier to just type
> \chordtext { G7alt }
Definitely on my wish list.
> We cannot expect to translate it to notes cleanly without
> more information about what it means
Agreed. But that’s easy to set up via preferences, settings, context
properties, etc.
> but we don't need to know what it means to engrave it.
More accurately/explicitly: we don’t need to know what the symbol “G7alt” means
in order to engrave *the symbol*.
But to engrave (or manipulate, etc.) *the chord*, we definitely *do* have to
know what it means.
> User wants to enter:
> \chordmode { e13 }
> and get
> E13
Same example as above.
> User wants to engrave a chord they describe as "Gm7(b5)/F" and is told to
> type
> g : m7.5- / f
> Note the desired output does not contain a colon or hyphen. Using that
> suggestion, as in
> \new ChordNames { \chordmode { g : m7.5- / f } }
> will actually engrave
> Gø/F
> (where the ø is superscript). User doesn't pursue it further, but this
> output does not closely resemble the requested
> Gm7(b5)/F
That’s merely a default/stylesheet issue.
(Note: I’ve long argued for a set of chord-exception stylesheets that go beyond
the one that’s included out of the box.)
> Counterpoint: "but MIDI!" is a common argument for
> why chords ought to always have translations to notes.
Although I don’t currently use MIDI much, I think this is a great argument for
chord translation.
> if we care so much about MIDI, why can't we have better MIDI support
“Patches are gratefully accepted.”
> if LilyPond is not about MIDI, chord names should not be about MIDI either.
That’s a logical fallacy. (Actually, a combination of at least two.)
Cheers,
Kieren.
________________________________
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
