Re: Adding text to chord names or note names

2022-11-28 Thread Kieren MacMillan
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

2022-11-28 Thread kbvw
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

2022-11-28 Thread Jean Abou Samra


> 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

2022-11-28 Thread Jean Abou Samra

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

2022-11-28 Thread James.Correa
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

2022-11-28 Thread Jean Abou Samra

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

2022-11-28 Thread Jean Abou Samra

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