> ---------- Forwarded message ----------
> From: kbvw <k...@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.vanwalst...@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
> }
>
> Code can be found here:
> https://gitlab.com/kbvw/lilypond-tweaks/-/blob/master/harmonic-background.ly
> 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.
Elaine Alt
415 . 341 .4954 "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
