---------- Forwarded message ----------
From: kbvw <kbvw@pm.me>
To: Lilypond-User Mailing List <lilypond-user@gnu.org>
Cc:
Bcc:
Date: Thu, 01 Dec 2022 18:10:03 +0000
Subject: Re: Adding text to chord names or note names (replies to discussion)
Hello Jean, Elaine,
Regarding the different use cases of input modes, chord symbols, etc., I guess one would have to disentangle two underlying concepts commonly addressed by the word "chord", like Elaine mentioned as well. One would be a collection of simultaneous (concrete/instantiated) pitches; let's call it a "voicing". The other would be a sort of specified "harmonic background" (I would say "context" but this might be confused with a LilyPond context), somewhat more related to (abstract) pitch classes. Either for analysis or as a specification of what to play.
In the former view, it makes total sense to have the pitches internally, and I can see many use cases, for automatic analysis, easier input of voicings, etc. In the latter view, if the harmonic background is something that you are specifying and reasoning from (as it often is in improvised music), and if that's what you want on the page, a calculating layer seems more redundant. Maybe it doesn't get in the way now or you can solve it, but it might get in the way with something new you come up with tomorrow?
I would not counterpose the purposes of calculation and specification.
In a way, we already have both. For example, the chordmode input allows for c:min7, which is a musical concept.
However, in terms of how lilypond maps that to a chord symbol, it still has to calculate that out to <c ees g bes>, and then map that to the appropriate markup template.
The second point, and I think this is what is missed in the concept of the GSOC project, is that although differing musical interpretations of the same group of notes is one use case for using different chord symbols for the same set of notes, that is not the only use case.
You might want the same notes and identical musical concept, printed in two different ways.
One example I have is that sometimes I want to be more explicit and verbose, and other times I am looking for more minimal notation. Since I use the "symbols" form of notation, (triangle for Major7, dash for minor, plus for augmented, circle for diminished, and null symbol for half diminished) when I want to write half diminished I sometimes just use the null symbol, since it is complete and implies a 4-note chord, and sometimes I want both the null symbol and the 7, for example to blend in within a sequence of other 7th chords.
These two cases cannot be distinguished using musical categorization, since they are musically the same thing. To distinguish these two formattings, we would need something additional. Which is why the concept of allowing ways to identify custom markup becomes necessary.
Custom markup is also necessary for the various "harmonic context" instructions that require notation beyond the standard symbols.
So, I also agree that, for arbitrary markup, there should be a direct way to use it, and you should not need to jump through hoops to construct a unique musical interpretation that will then be converted back into the thing you wanted to say in the first place.
However, once you've supported an arbitrary way to identify custom markup, you can use that as the mechanism to address the "omit root" case(s), and that leaves no obvious reason why you would need to to introduce more complication in modeling chords beyond what we have already.
@Jean:
Thanks for the alternative function for "enharmonicizing" the chords.
@Elaine:
I found it quite interesting reading your replies, as it seems to me that we agree on almost all of the premises: "we only need to transpose root and slash bass", "chords are often enharmonically ambiguous and one could argue for a sharp or a flat", "theoretical concepts are of lesser importance when specifying a chord to an improviser, and simple spellings are easier to read". Yet, we seem to reason from there in opposite directions somehow.
If your only issue is
"specifying the pitches every time" then it seems that you are not aware of
the chord input syntax, and are instead using pitches.
Perhaps you should invest in learning the chordmode syntax?
I did learn the chord mode syntax; it's quite intuitive. And I found your list of chord exceptions (posted to this list in the past) helpful, so thanks for that! I should clarify that the "mode" was just some example, as was the "6-9". These things are rather well defined. It was more of an argument of being limited unnecessarily.
Silly new example: suppose I'd want to specify to "tonicize F" for a few measures by McCoy-Tyner-style smashing it as a pedal and playing very freely over it: f^"tyner"? Or I'd want to specify a tonal feeling of D but I'd rather say which pitches not to play. I'm not saying I would actually write those things, but if the specified harmony "is" the composition, why limit yourself?
In broader sense, from an engraving style point of view, I would ask whether "tonicize F" belongs within chord changes, or should be more of a style/tempo type of indication like "rootless chords", "block chords", "open voicings", "Stride", etc.
Although, I agree that there is no need to limit yourself, and that arbitrary markup should be possible.
But I do think that it is useful to figure out how best to use the various conventions to get the point across. The literal of "Tonicize F" is somewhat indistinguishable from "F". If you mean pedal F, then just writing "/F" or "F ped." might be clearer.
And of course, for pedal F, I would suggest that it finds a home within the existing mechanism, which would be identifying it in chordmode as the single-note chord f:1
And then add the entry in chord exceptions would be <c>1-\markup \small " Ped."
Seems to me that it is difficult to simplify f:1 any further.
Besides that, your example of writing out the modes doesn't solve my initial (quite concrete) problem of transposition: if I take your C phrygian and transpose to A-flat, I get a bunch of double flats. (I know you could transpose to G-sharp in that case, but I have many chords in a piece and instruments in several keys: I'd rather just transpose the piece once as a whole.)
I agree that my suggestions do not address the transposition problem.
Fortunately, others have provided solutions to that.
My point is that these are two different things. No solution for custom markup will automatically solve the transposition problem, and the lack of addressing transposition is not an argument for or against any particular approach to custom markup.
The workarounds you present afterwards seem like quite a bit of effort to me. Don't get me wrong: whatever works, and I thank you for the carefully worked-out suggestions! I'd just rather not find individual solutions for individual chords/parts.
All the best,
Koen
If you are talking about the transposition approach, I agree with you.
I will likely try out Jean's functions the next time it comes up.
---------- Forwarded message ----------
From: Koen van Walstijn <koen.vanwalstijn@protonmail.ch>
To: Lilypond-User Mailing List <lilypond-user@gnu.org>
Cc:
Bcc:
Date: Thu, 01 Dec 2022 18:04:03 +0000
Subject: Re: Adding text to chord names or note names (solution)
Hello,
(Separately reply follows to some of the specific things that we
re written.)
In case there is interest, what I did now was tweaking the Current_chord_text_engraver from scheme_engravers.scm. It simply takes the first pitch specified in a chord as the root, takes the first one with property "bass" as the bass, and it additionally listens to text-script-events from which it takes the first specified one as the suffix. I use that in a custom context called "HarmonicBackground" for lack of something better, same as ChordNames but with this engraver instead of the original one. For the input I just use relative mode.
An example of how I specify the chord symbols now:
chords = \relative {
<f \over ees>^"7"
des^"lyd"
}
\new HarmonicBackground { \chords
}
It's probably not foolproof; I'm a novice with both LilyPond and Scheme. Currently the text-script is hard-coded to go in the superscript of the chord, before the slash separator. Perhaps it would be nicer to look if the text-script is entered with ^ or _, and even nicer would be to use shorthands in an input mode such as the chord mode, but I didn't look at any of the input/parser code yet.
For myself that suffices for now; it looks good to me on the page and it's easy/flexible to enter.
If anyone more knowledgeable thinks it's worth continuing with, I'd be happy to discuss/help! (I can see several advantages and disadvantages.)
All the best, and thanks for the help,
Koen
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
I'm glad you were able to get the results you want. Writing scheme is not a trivial endeavor! Well done.
My comment on this is that, since it does not support any calculation, you have to enter text markup for every chord symbol (other than major chords or major slash chords), not just the ones that need custom markup.
I guess depending on what your chords are, this might mean more or less work.
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-