Re: Adding text to chord names or note names
Hi Koen, > I still think it could be nice to try to write a longer-term solution. There has been a lot of work done on chord naming over the last decade, mainly as part of a Google Summer of Code project a few years ago, but essentially none of it has yet navigated through the patch submission process. There are lots of people who think it would be nice to write a long-term solution — it just keeps getting stalled (for various reasons). > Do you think there would be any interest in specifying the chord suffixes > like that, directly from markup? Not sure if I can speak for anyone else, but my interest is (and has always been) in having a robust, unified system with a clean UI that handles most (if not all) of the main use cases. > in the specific use case of printing a harmonic background, the layer of > calculating chords from internal pitches is redundant anyway. There are many > ways to think about a chord, and I change the way I think about them all the > time: I just want to write it down and I don't need LilyPond to reason about > it. :) (Although a root and a bass note are still useful.) Make sure you’re up to speed on what’s been done in this area, since some of the groundwork may be complete. And of course there are good reasons that Lilypond has the calculating chords layer — the thing we all want (I think?) is to add functionality without losing what’s already there! Cheers, Kieren.
Re: Adding text to chord names or note names
Hi Kieren, Thanks for your reply; I hope my message didn't come off as rude or unsolicited. (To be sure: I did not mean to suggest removing any functionality that's there. I can easily see many use cases for calculating the actual pitches of a chord internally. I meant more of an alternative chordNameFunction or engraver of some sorts that could be swapped in, one that would display arbitrary extra information for a chord as a suffix.) As a new user, the message was mostly intended to ask around a bit for the state of the art or latest thoughts on this. So far, I found most of the code relating to the (new) chord engravers in scheme and I can see how that part works, but I'm not too clear yet on the input side. I saw there was talk of a unified chord/note input; I'll keep reading the discussion/source/issues to get up to speed. (Meanwhile Jean's solution puts me in business for what I wanted to do; thanks again Jean!) All the best, Koen --- Original Message --- On Monday, November 28th, 2022 at 3:37 PM, Kieren MacMillan wrote: > Hi Koen, > > > I still think it could be nice to try to write a longer-term solution. > > > There has been a lot of work done on chord naming over the last decade, > mainly as part of a Google Summer of Code project a few years ago, but > essentially none of it has yet navigated through the patch submission process. > > There are lots of people who think it would be nice to write a long-term > solution — it just keeps getting stalled (for various reasons). > > > Do you think there would be any interest in specifying the chord suffixes > > like that, directly from markup? > > > Not sure if I can speak for anyone else, but my interest is (and has always > been) in having a robust, unified system with a clean UI that handles most > (if not all) of the main use cases. > > > in the specific use case of printing a harmonic background, the layer of > > calculating chords from internal pitches is redundant anyway. There are > > many ways to think about a chord, and I change the way I think about them > > all the time: I just want to write it down and I don't need LilyPond to > > reason about it. :) (Although a root and a bass note are still useful.) > > > Make sure you’re up to speed on what’s been done in this area, since some of > the groundwork may be complete. And of course there are good reasons that > Lilypond has the calculating chords layer — the thing we all want (I think?) > is to add functionality without losing what’s already there! > > Cheers, > Kieren.
Re: Adding text to chord names or note names
> Le 28 nov. 2022 à 02:21, kbvw a écrit :
>
>
> Hi Jean,
>
> I just finished my reply when I saw your next message. :)
>
> Sorry, I was starting to forget about the "transposing" bit.
>
> Well, how about
>
> \version "2.22.2"
>
> t =
> #(define-music-function (text) (markup?)
>#{
> \once \set chordNameFunction =
>#(lambda (sorted-pitches bass inversion context)
> (let* ((root (first sorted-pitches))
> (root-namer
> (ly:context-property context 'chordRootNamer))
> (root-markup (root-namer root #f))
> (bass-markup
> (if (ly:pitch? bass)
> #{ \markup { / #(root-namer bass #f) } #}
> "")))
> #{ \markup { #root-markup \super #text #bass-markup } #}))
>#})
>
> bass = \withMusicProperty bass ##t \etc
>
> myChordNames =
> \relative {
> \t "6-9" c1
> \t "6-9" << c \bass g >>
> }
>
> <<
> \new ChordNames \myChordNames
> \new ChordNames \transpose c d \myChordNames
> >>
>
> Yeah, judging from some quick tests, that seems to do what I want. Thanks a
> lot! This is very useful.
>
> I still think it could be nice to try to write a longer-term solution. I saw
> it was you who wrote that newer Current_chord_text_engraver, with the goal of
> making a chord name grid. Do you think there would be any interest in
> specifying the chord suffixes like that, directly from markup? I'd be happy
> to contribute to some other kind of chord engraver or chord name function
> that behaves like that, if anyone else thinks it's useful. (I imagine jazz
> musicians might?)
>
> To clarify again: the immediate reason was that if I transpose all of the
> pitches in a chord and then naturalize double accidentals, it messes up the
> intervals and the symbol changes.
For this use case, there are solutions that let you keep the usual \chordmode
input, see
https://myrealbook.vintherine.org/le-principe-de-la-moindre-alteration.html (if
you don’t read French, just copy the code and try it).
Essentially, this is a chord naming function that naturalizes the root. Unlike
the naturalization functions found in snippets, it doesn’t naturalize all the
pitches, it lets the chord naming infrastructure do its job normally but only
acts on how the root is formatted.
> The longer-term reason is that to me, at least in the specific use case of
> printing a harmonic background, the layer of calculating chords from internal
> pitches is redundant anyway. There are many ways to think about a chord, and
> I change the way I think about them all the time: I just want to write it
> down and I don't need LilyPond to reason about it. :) (Although a root and a
> bass note are still useful.)
I’ll reply to this separately.
Beat,
Jean
Re: comparing crashes in 2.23.81 with 2.23.14 and 2.22.1
Le 28/11/2022 à 00:24, Jean Abou Samra a écrit : FYI, this is going to remain unfixed for 2.24.0, but probably going to be fixed in the followup bugfix release 2.24.1 (probably around February). See https://lists.gnu.org/archive/html/lilypond-devel/2022-11/msg00102.html if you are interested in the details. As Jonas rightfully pointed out off-list, "probably around February" should rather be "in February at the earliest", if the BDWGC maintainer makes a bugfix release in January and it works out for us and no unforeseen hiccup gets in the way. It could be much later if the BDWGC release doesn't come or if we find it causes problems. (Also, it could be 2.24.x with x > 1 if we have to make bugfix releases in the meantime.) Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Beaming question
I think this is what you are looking for:
\version "2.22.2"
\score {
\absolute {
\tuplet 3/2 { f ''16 [ c'' \once \set stemRightBeamCount = #1 f'' } \once \set
stemLeftBeamCount = #1 c'' f'' ) ] | %m67
}
}
---
James Correa
Composer - guitarist - sound designer
http://www.jamescorrea.net
http://wp.ufpel.edu.br/labcomp/
Sent with [Proton Mail](https://proton.me/) secure email.
--- Original Message ---
On Sunday, November 27th, 2022 at 13:44, Molly Preston
wrote:
> I am working with a texture of triplet 16ths that occasionally are duple
> 16ths. I am wondering if there is a way to turn the beam into a single beam
> between the second f'' in the triplet to the c'' in the below example. I'm
> not sure what that's called and couldn't find it in the notation manual. It
> is written that way in the original score. (This is an orchestration project
> for school.)
>
> \version "2.22.2"
>
> \score {
> \absolute {
>
> \tuplet 3/2 { f ''16 c'' f'' } c'' f'' ) | %m67
> }
> }
>
> Any help is appreciated!
>
> Thanks!
>
> Molly
Re: Adding text to chord names or note names
Le 28/11/2022 à 15:37, Kieren MacMillan a écrit : Hi Koen, I still think it could be nice to try to write a longer-term solution. There has been a lot of work done on chord naming over the last decade, mainly as part of a Google Summer of Code project a few years ago, but essentially none of it has yet navigated through the patch submission process. There are lots of people who think it would be nice to write a long-term solution — it just keeps getting stalled (for various reasons). Do you think there would be any interest in specifying the chord suffixes like that, directly from markup? Not sure if I can speak for anyone else, but my interest is (and has always been) in having a robust, unified system with a clean UI that handles most (if not all) of the main use cases. in the specific use case of printing a harmonic background, the layer of calculating chords from internal pitches is redundant anyway. There are many ways to think about a chord, and I change the way I think about them all the time: I just want to write it down and I don't need LilyPond to reason about it. :) (Although a root and a bass note are still useful.) Make sure you’re up to speed on what’s been done in this area, since some of the groundwork may be complete. And of course there are good reasons that Lilypond has the calculating chords layer — the thing we all want (I think?) is to add functionality without losing what’s already there! I am not up to speed myself on the various brainstormings that happened over the years. What I can at least tell is that the ideas floating around for a unified note/chords mode are relatively orthogonal to this discussion, as far as I understand them. The advantages of a unified mode would be a) less syntax to learn b) making it more convenient to enter, e.g., piano music, by making it easy to use \chordmode-like entry for a chord that appears in the middle of a melody (no chord names involved here). So it’s more about applying \chordmode syntax to non-chord-names use cases. The other piece of brainstorming I know about, although I didn’t chase all the discussions in the devel mailing list, is the GSoC patch. This has the same goal of making it easier to coerce LilyPond into formatting chord names the way you want, but does so with a different approach: remember the details of how the chord was entered in \chordmode, so that the chord formatting is closer to the input. Compared to just adding chord symbols with \markup, that has the advantage that LilyPond understands what the chords are actually made of, and the disadvantage that it can still be cumbersome to teach LilyPond how to format the chords the way you want. I don't typeset chord names myself, I don't really know how strong the arguments are for each side. Maybe there's a place for both, maybe not. At any rate, as opposed to the chord semantics GSoC approach, it would be rather straightforward implementation-wise to make LilyPond understand arbitrary chord symbols, as shown in the code from my original reply. Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Adding text to chord names or note names
Le 28/11/2022 à 20:27, Jean Abou Samra a écrit : The other piece of brainstorming I know about, although I didn’t chase all the discussions in the devel mailing list, is the GSoC patch. This has the same goal of making it easier to coerce LilyPond into formatting chord names the way you want, but does so with a different approach: remember the details of how the chord was entered in \chordmode, so that the chord formatting is closer to the input. Compared to just adding chord symbols with \markup, that has the advantage that LilyPond understands what the chords are actually made of, and the disadvantage that it can still be cumbersome to teach LilyPond how to format the chords the way you want. I don't typeset chord names myself, I don't really know how strong the arguments are for each side. Maybe there's a place for both, maybe not. At any rate, as opposed to the chord semantics GSoC approach, it would be rather straightforward implementation-wise to make LilyPond understand arbitrary chord symbols, as shown in the code from my original reply. Amusingly, I found this post from 2001: https://lists.gnu.org/archive/html/gnu-music-discuss/2001-03/msg00327.html (The thread continues here: https://lists.gnu.org/archive/html/gnu-music-discuss/2001-04/msg0.html) OpenPGP_signature Description: OpenPGP digital signature
