Re: Parenthesizing multiple events

[Luca Fascione]

Lovely, thank you Knute
L

On Mon, 20 Nov 2023, 16:11 Knute Snortum,  wrote:

> On Mon, Nov 20, 2023 at 6:34 AM Luca Fascione 
> wrote:
>
>> Did this change between 22 and 24?
>> Is there somewhere I can go to see the implementation for the LSR that
>> used 2.22?
>>
>> L
>>
>> On Mon, 20 Nov 2023, 15:07 Knute Snortum,  wrote:
>>
>>> On Mon, Nov 20, 2023 at 4:35 AM Luca Fascione 
>>> wrote:
>>>
>>>> Also,
>>>> it doesn't seem to actually work on 2.22 (see below)
>>>>
>>>> How does this even compile on the LSR?
>>>>
>>>
>>> The LSR uses LilyPond 2.24.2, which compiles the source without error.
>>>
>>
> I searched for the original post for the LSR and upgraded it only to
> 2.22.  If you're not going to upgrade LilyPond to 2.24.3, then try this:
>
> \version "2.22.0"
>
> startParenthesis = {
> \once \override ParenthesesItem.stencils = #(lambda (grob)
> (let ((par-list (parentheses-item::calc-parenthesis-stencils grob))
> (right-par (grob-interpret-markup grob (markup #:null
> (list (car par-list)right-par )))
> }
>
> endParenthesis = {
> \once \override ParenthesesItem.stencils = #(lambda (grob)
> (let ((par-list (parentheses-item::calc-parenthesis-stencils grob))
> (left-par (grob-interpret-markup grob (markup #:null
> (list left-par (cadr par-list
> }
>
> {
>   \new ChordNames {
> \chordmode {
>   \startParenthesis \parenthesize a:m7 \endParenthesis \parenthesize
> d:7
> }
>   }
> }
>
> --
> Knute Snortum
>
>

Re: Parenthesizing multiple events

[Luca Fascione]

It's for a chord symbol in ChordName mode (Ab7, say)

I didn't think those supported arpeggio brackets

L

On Mon, 20 Nov 2023, 15:39 Ben Bradshaw,  wrote:

> As an alternate approach could you use the \arrpegioBracket ? It's a
> little more square, but I think there's a way to override that. I used it
> once to put a bracket around a cord. You just have to override one of the
> properties to move the endpoints in the negative direction as well as an x
> offset for the closing side.
>
> On Mon, Nov 20, 2023, 7:35 AM Luca Fascione  wrote:
>
>> Did this change between 22 and 24?
>> Is there somewhere I can go to see the implementation for the LSR that
>> used 2.22?
>>
>> L
>>
>> On Mon, 20 Nov 2023, 15:07 Knute Snortum,  wrote:
>>
>>> On Mon, Nov 20, 2023 at 4:35 AM Luca Fascione 
>>> wrote:
>>>
>>>> Also,
>>>> it doesn't seem to actually work on 2.22 (see below)
>>>>
>>>> How does this even compile on the LSR?
>>>>
>>>
>>> The LSR uses LilyPond 2.24.2, which compiles the source without error.
>>>
>>> --
>>> Knute Snortum
>>>
>>

Re: Parenthesizing multiple events

[Luca Fascione]

Did this change between 22 and 24?
Is there somewhere I can go to see the implementation for the LSR that used
2.22?

L

On Mon, 20 Nov 2023, 15:07 Knute Snortum,  wrote:

> On Mon, Nov 20, 2023 at 4:35 AM Luca Fascione 
> wrote:
>
>> Also,
>> it doesn't seem to actually work on 2.22 (see below)
>>
>> How does this even compile on the LSR?
>>
>
> The LSR uses LilyPond 2.24.2, which compiles the source without error.
>
> --
> Knute Snortum
>

Re: Parenthesizing multiple events

[Luca Fascione]

Also,
it doesn't seem to actually work on 2.22 (see below)

How does this even compile on the LSR?

https://lsr.di.unimi.it/LSR/Snippet?id=902

L

===
\version "2.22.2"

startParenthesis = {
  \once \override Parentheses.stencils = #(lambda (grob)
(let ((par-list (parentheses-interface::calc-parenthesis-stencils
grob)))
  (list (car par-list) point-stencil )))
}

endParenthesis = {
  \once \override Parentheses.stencils = #(lambda (grob)
(let ((par-list (parentheses-interface::calc-parenthesis-stencils
grob)))
  (list point-stencil (cadr par-list
}

\score {

\new StaffGroup <<
\new Staff { \new Voice { \override Parentheses.font-size = #5
\startParenthesis \parenthesize c d e f \endParenthesis \parenthesize g } }
\new Staff { \new Voice { \relative f' { c, } c } }
>>
}
===

paren_tests.ly:4:19: error: bad grob property path

\once \override

Parentheses.stencils = #(lambda (grob)

paren_tests.ly:10:19: error: bad grob property path

\once \override

Parentheses.stencils = #(lambda (grob)

On Fri, Nov 17, 2023 at 12:29 PM Luca Fascione  wrote:

> Yes, I was thinking more about parenthesizing say a chord or a scale,
> rather than a head vs a flat/sharp sign.
> I think that next to a chord (say 8) I'd want parentheses around
> the heads, but not the stem, because it feels like an ascender like in your
> "flat" example
>
> Thanks Jean,
> L
>
> On Fri, Nov 17, 2023 at 11:58 AM Jean Abou Samra 
> wrote:
>
>> Le vendredi 17 novembre 2023 à 11:44 +0100, Luca Fascione a écrit :
>>
>> Nice. Thanks Jean. This solves it for my current score
>>
>> In general, what's the background for this not working though?
>> You seem to imply it's intended behaviour that it would only work on a
>> single event, or am I misreading?
>>
>>
>>
>> The restriction is not parenthesizing a single event but parenthesizing a
>> single grob, because the parenthesis grob needs something to attach to.
>> Making a Parentheses spanner between two points of the score would be
>> theoretically possible to implement, it's just not implemented right now.
>>
>> Also, can't lilypond support a mechanism like TeX's \left \right system
>> to gauge delimiter sizes?
>>
>>
>>
>> It can — in fact, it has the \markup \parenthesize command. The issue
>> with (non-\markup) \parenthesize is that it is implemented by looking up
>> font glyphs according to font size, which works better in some contexts
>> like accidentals, because you want the parentheses on a flat to look like
>>
>>
>>
>>
>> and not
>>
>>
>>
>> Again, there's no theoretical limitation preventing auto-scaling, but it
>> might need a heuristic to decide when it's appropriate.
>>
>>
>
> --
> Luca Fascione
>
>

-- 
Luca Fascione

Re: Parenthesizing multiple events

[Luca Fascione]

Yes, I was thinking more about parenthesizing say a chord or a scale,
rather than a head vs a flat/sharp sign.
I think that next to a chord (say 8) I'd want parentheses around the
heads, but not the stem, because it feels like an ascender like in your
"flat" example

Thanks Jean,
L

On Fri, Nov 17, 2023 at 11:58 AM Jean Abou Samra  wrote:

> Le vendredi 17 novembre 2023 à 11:44 +0100, Luca Fascione a écrit :
>
> Nice. Thanks Jean. This solves it for my current score
>
> In general, what's the background for this not working though?
> You seem to imply it's intended behaviour that it would only work on a
> single event, or am I misreading?
>
>
>
> The restriction is not parenthesizing a single event but parenthesizing a
> single grob, because the parenthesis grob needs something to attach to.
> Making a Parentheses spanner between two points of the score would be
> theoretically possible to implement, it's just not implemented right now.
>
> Also, can't lilypond support a mechanism like TeX's \left \right system to
> gauge delimiter sizes?
>
>
>
> It can — in fact, it has the \markup \parenthesize command. The issue with
> (non-\markup) \parenthesize is that it is implemented by looking up font
> glyphs according to font size, which works better in some contexts like
> accidentals, because you want the parentheses on a flat to look like
>
>
>
>
> and not
>
>
>
> Again, there's no theoretical limitation preventing auto-scaling, but it
> might need a heuristic to decide when it's appropriate.
>
>

-- 
Luca Fascione

Re: Parenthesizing multiple events

[Luca Fascione]

Nice. Thanks Jean. This solves it for my current score

In general, what's the background for this not working though?
You seem to imply it's intended behaviour that it would only work on a
single event, or am I misreading?

Also, can't lilypond support a mechanism like TeX's \left \right system to
gauge delimiter sizes?

Cheers
L

On Fri, Nov 17, 2023 at 11:18 AM Jean Abou Samra  wrote:

> Le vendredi 17 novembre 2023 à 10:58 +0100, Luca Fascione a écrit :
>
> Hi all,
>
>
>
> Try
>
> https://lsr.di.unimi.it/LSR/Item?id=902
>
>

-- 
Luca Fascione

Re: MIDI Drums to lilypond

[Luca Fascione]

Yes, sorry. I did find that after typing the email...

It is the GM mapping, it's just that I didn't want to retype it all by
hand, if I could parse it from somewhere, you see

Thanks!

L

On Fri, Nov 17, 2023 at 11:05 AM Mark Knoop  wrote:

> You'll find it in drumpitch-init.ly, I believe it's just the
> standard General MIDI percussion keymap.
>
> At 10:52 on 17 Nov 2023, Luca Fascione wrote:
> > Hi,
> > I'm converting a MIDI file to lilypond with a drumset track.
>
> > My process goes through MusicXML, but the `musicxml2ly` script I have
> > (2.22.2) emits pitches instead of percussion notes.
>
> > I can write a script to map those, but if anyone had a starting point,
> > that'd be grand.
>
> > In my mind, the mapping lilypond uses to go from the percussion notes to
> > its MIDI output is all I need (and then I can reverse that). If someone
> > could get me a breadcrumb to that, that'd be grand.
>
> > Thanks
> > Luca
>
> --
> Mark Knoop
>


-- 
Luca Fascione

Parenthesizing multiple events

[Luca Fascione]

Hi all,
I noticed that in \chordmode the \parenthesize command only seems to word
with one chord

If I use

\new ChordNames { \chordmode { \parenthesize a:m7 } }

I get a chord in parentheses.
If I use

\new ChordNames { \chordmode { \parenthesize { a:m7 d:7}  } }

I do not get two chords in parentheses (chords are there but parens are not)

Also,

\new ChordNames { \chordmode { \parenthesize { a:m7 } } }

produces the chord symbol and no parentheses

\parenthesisOpenSymbol also is rejected inside \chordmode

Cheers
L

-- 
Luca Fascione

MIDI Drums to lilypond

[Luca Fascione]

Hi,
I'm converting a MIDI file to lilypond with a drumset track.

My process goes through MusicXML, but the `musicxml2ly` script I have
(2.22.2) emits pitches instead of percussion notes.

I can write a script to map those, but if anyone had a starting point,
that'd be grand.

In my mind, the mapping lilypond uses to go from the percussion notes to
its MIDI output is all I need (and then I can reverse that). If someone
could get me a breadcrumb to that, that'd be grand.

Thanks
Luca

-- 
Luca Fascione

Re: Collision between accidentals and start-of-line brackets

[Luca Fascione]

On Tue, Nov 22, 2022 at 3:37 PM Leo Correia de Verdier <
leo.correia.de.verd...@gmail.com> wrote:

> That is not another bug, that is because I only redefined the regular
> barline
>

D'Oh. Of course. Thanks...



> Another curious thing is that bar six prints right for me, even without
> barlines in the beginning.
>

'msorry what's that? Could you show me?
What version of lilypond are you using?

Thanks again,
L

-- 
Luca Fascione

Re: Collision between accidentals and start-of-line brackets

[Luca Fascione]

Ha.
So it works. but also reveals another bug

Note small change in bar 5: now the bar 6 line is gone again, and so it's
the correctly accounted accidental spacing...

L

\version "2.22.1"

\layout {
\override Score.Clef.break-visibility = #'#(#f #f #f)  % make only the
first clef visible
}

\defineBarLine "|" #'("|" "|" "|")


m =  \relative c'' {
c4 c c c | \break
4 cis cis cis |
4 cis cis cis |
\repeat unfold 2 { c c c c } \bar "||"  \break
4 c c c |
4 cis cis cis |
\repeat unfold 2 { c c c c } \break
\repeat unfold 4 { c c c c }
}

\score {
\m
}

On Tue, Nov 22, 2022 at 3:17 PM Luca Fascione  wrote:

> Noice, thanks Leo, this is enough of a workaround for my current state,
> thanks for figuring that out
>
> Cheers,
> Luca
>
> On Tue, 22 Nov 2022, 14:04 Leo Correia de Verdier, <
> leo.correia.de.verd...@gmail.com> wrote:
>
>> Hi Luca!
>>
>> This could well be a bug. In the context you have shown you can work
>> around it by printing the barlines at the beginning of staves too, by adding
>> \defineBarLine "|" #'("|" "|" "|”)
>> to the layout block.
>>
>> HTH
>> /Leo
>>
>> 22 nov. 2022 kl. 13:30 skrev Luca Fascione :
>>
>> Ok, so, small source at the bottom
>>
>> [image: image.png]
>>
>> See how the stems of the first columns in bars 2, 6, 10 all line up,
>> whereas on bars 3, 7, 11 they don't...
>>
>> L
>>
>> \version "2.22.1"
>>
>> \layout {
>> \override Score.Clef.break-visibility = #'#(#f #f #f)  % make only
>> the first clef visible
>> }
>>
>> m =  \relative c'' {
>>     c4 c c c | \break
>> 4 cis cis cis |
>> 4 cis cis cis |
>> \repeat unfold 2 { c c c c } \break
>> 4 c c c |
>> 4 cis cis cis |
>> \repeat unfold 2 { c c c c } \break
>> \repeat unfold 4 { c c c c }
>> }
>>
>> \score {
>> \m
>> }
>>
>>
>> On Tue, Nov 22, 2022 at 1:15 PM Luca Fascione 
>> wrote:
>> It seems to have something to do with this:
>>
>> \override Clef.break-visibility = #'#(#f #f #f)
>>
>> I'm working on shortening the source
>>
>> L
>>
>> On Tue, Nov 22, 2022 at 12:25 PM Luca Fascione 
>> wrote:
>> Ha. Ok, I'll whittle it down to something small that repros it then.
>> Thanks Leo!
>> L
>>
>> On Tue, 22 Nov 2022, 12:00 Leo Correia de Verdier, <
>> leo.correia.de.verd...@gmail.com> wrote:
>> Hi Luca!
>>
>> This works quite well when I try to replicate it, so the code producing
>> the error is probably needed to solve this. Try to make a minimal example.
>> That said, one could guess that it could have something to do with
>> break-alignments.
>>
>> Best
>> /Leo
>>
>> 22 nov. 2022 kl. 11:27 skrev Luca Fascione :
>>
>> Hi all,
>> In a sheet I'm working on I'm observing that the accidentals on the first
>> bar of a line aren't handling collisions with the start-of-line bracket and
>> bar, while inbetween bars this works just fine (see attached image).
>>
>> Where do I look for hints on how to fix this?
>>
>> Many thanks,
>> Luca
>>
>>
>> --
>> Luca Fascione
>>
>>
>>
>>
>> --
>> Luca Fascione
>>
>>
>>
>> --
>> Luca Fascione
>>
>>
>>

-- 
Luca Fascione

Re: Collision between accidentals and start-of-line brackets

[Luca Fascione]

Noice, thanks Leo, this is enough of a workaround for my current state,
thanks for figuring that out

Cheers,
Luca

On Tue, 22 Nov 2022, 14:04 Leo Correia de Verdier, <
leo.correia.de.verd...@gmail.com> wrote:

> Hi Luca!
>
> This could well be a bug. In the context you have shown you can work
> around it by printing the barlines at the beginning of staves too, by adding
> \defineBarLine "|" #'("|" "|" "|”)
> to the layout block.
>
> HTH
> /Leo
>
> 22 nov. 2022 kl. 13:30 skrev Luca Fascione :
>
> Ok, so, small source at the bottom
>
> [image: image.png]
>
> See how the stems of the first columns in bars 2, 6, 10 all line up,
> whereas on bars 3, 7, 11 they don't...
>
> L
>
> \version "2.22.1"
>
> \layout {
> \override Score.Clef.break-visibility = #'#(#f #f #f)  % make only the
> first clef visible
> }
>
> m =  \relative c'' {
> c4 c c c | \break
> 4 cis cis cis |
> 4 cis cis cis |
> \repeat unfold 2 { c c c c } \break
> 4 c c c |
> 4 cis cis cis |
> \repeat unfold 2 { c c c c } \break
> \repeat unfold 4 { c c c c }
> }
>
> \score {
> \m
> }
>
>
> On Tue, Nov 22, 2022 at 1:15 PM Luca Fascione 
> wrote:
> It seems to have something to do with this:
>
> \override Clef.break-visibility = #'#(#f #f #f)
>
> I'm working on shortening the source
>
> L
>
> On Tue, Nov 22, 2022 at 12:25 PM Luca Fascione 
> wrote:
> Ha. Ok, I'll whittle it down to something small that repros it then.
> Thanks Leo!
> L
>
> On Tue, 22 Nov 2022, 12:00 Leo Correia de Verdier, <
> leo.correia.de.verd...@gmail.com> wrote:
> Hi Luca!
>
> This works quite well when I try to replicate it, so the code producing
> the error is probably needed to solve this. Try to make a minimal example.
> That said, one could guess that it could have something to do with
> break-alignments.
>
> Best
> /Leo
>
> 22 nov. 2022 kl. 11:27 skrev Luca Fascione :
>
> Hi all,
> In a sheet I'm working on I'm observing that the accidentals on the first
> bar of a line aren't handling collisions with the start-of-line bracket and
> bar, while inbetween bars this works just fine (see attached image).
>
> Where do I look for hints on how to fix this?
>
> Many thanks,
> Luca
>
>
> --
> Luca Fascione
>
>
>
>
> --
> Luca Fascione
>
>
>
> --
> Luca Fascione
>
>
>

Re: Collision between accidentals and start-of-line brackets

[Luca Fascione]

Ok, so, small source at the bottom

[image: image.png]

See how the stems of the first columns in bars 2, 6, 10 all line up,
whereas on bars 3, 7, 11 they don't...

L

\version "2.22.1"

\layout {
\override Score.Clef.break-visibility = #'#(#f #f #f)  % make only the
first clef visible
}

m =  \relative c'' {
c4 c c c | \break
4 cis cis cis |
4 cis cis cis |
\repeat unfold 2 { c c c c } \break
4 c c c |
4 cis cis cis |
\repeat unfold 2 { c c c c } \break
\repeat unfold 4 { c c c c }
}

\score {
\m
}


On Tue, Nov 22, 2022 at 1:15 PM Luca Fascione  wrote:

> It seems to have something to do with this:
>
> \override Clef.break-visibility = #'#(#f #f #f)
>
> I'm working on shortening the source
>
> L
>
> On Tue, Nov 22, 2022 at 12:25 PM Luca Fascione 
> wrote:
>
>> Ha. Ok, I'll whittle it down to something small that repros it then.
>> Thanks Leo!
>> L
>>
>> On Tue, 22 Nov 2022, 12:00 Leo Correia de Verdier, <
>> leo.correia.de.verd...@gmail.com> wrote:
>>
>>> Hi Luca!
>>>
>>> This works quite well when I try to replicate it, so the code producing
>>> the error is probably needed to solve this. Try to make a minimal example.
>>> That said, one could guess that it could have something to do with
>>> break-alignments.
>>>
>>> Best
>>> /Leo
>>>
>>> 22 nov. 2022 kl. 11:27 skrev Luca Fascione :
>>>
>>> Hi all,
>>> In a sheet I'm working on I'm observing that the accidentals on the
>>> first bar of a line aren't handling collisions with the start-of-line
>>> bracket and bar, while inbetween bars this works just fine (see
>>> attached image).
>>>
>>> Where do I look for hints on how to fix this?
>>>
>>> Many thanks,
>>> Luca
>>>
>>> [image: image.png]
>>> --
>>> Luca Fascione
>>>
>>>
>>>
>
> --
> Luca Fascione
>
>

-- 
Luca Fascione

Re: Collision between accidentals and start-of-line brackets

[Luca Fascione]

It seems to have something to do with this:

\override Clef.break-visibility = #'#(#f #f #f)

I'm working on shortening the source

L

On Tue, Nov 22, 2022 at 12:25 PM Luca Fascione  wrote:

> Ha. Ok, I'll whittle it down to something small that repros it then.
> Thanks Leo!
> L
>
> On Tue, 22 Nov 2022, 12:00 Leo Correia de Verdier, <
> leo.correia.de.verd...@gmail.com> wrote:
>
>> Hi Luca!
>>
>> This works quite well when I try to replicate it, so the code producing
>> the error is probably needed to solve this. Try to make a minimal example.
>> That said, one could guess that it could have something to do with
>> break-alignments.
>>
>> Best
>> /Leo
>>
>> 22 nov. 2022 kl. 11:27 skrev Luca Fascione :
>>
>> Hi all,
>> In a sheet I'm working on I'm observing that the accidentals on the first
>> bar of a line aren't handling collisions with the start-of-line bracket and
>> bar, while inbetween bars this works just fine (see attached image).
>>
>> Where do I look for hints on how to fix this?
>>
>> Many thanks,
>> Luca
>>
>> [image: image.png]
>> --
>> Luca Fascione
>>
>>
>>

-- 
Luca Fascione

Re: Collision between accidentals and start-of-line brackets

[Luca Fascione]

Ha. Ok, I'll whittle it down to something small that repros it then.
Thanks Leo!
L

On Tue, 22 Nov 2022, 12:00 Leo Correia de Verdier, <
leo.correia.de.verd...@gmail.com> wrote:

> Hi Luca!
>
> This works quite well when I try to replicate it, so the code producing
> the error is probably needed to solve this. Try to make a minimal example.
> That said, one could guess that it could have something to do with
> break-alignments.
>
> Best
> /Leo
>
> 22 nov. 2022 kl. 11:27 skrev Luca Fascione :
>
> Hi all,
> In a sheet I'm working on I'm observing that the accidentals on the first
> bar of a line aren't handling collisions with the start-of-line bracket and
> bar, while inbetween bars this works just fine (see attached image).
>
> Where do I look for hints on how to fix this?
>
> Many thanks,
> Luca
>
> [image: image.png]
> --
> Luca Fascione
>
>
>

Collision between accidentals and start-of-line brackets

[Luca Fascione]

Hi all,
In a sheet I'm working on I'm observing that the accidentals on the first
bar of a line aren't handling collisions with the start-of-line bracket and
bar, while inbetween bars this works just fine (see attached image).

Where do I look for hints on how to fix this?

Many thanks,
Luca

[image: image.png]
-- 
Luca Fascione

Re: Splitting voices

[Luca Fascione]

Awesome, thanks Jean!
L

On Sun, 20 Nov 2022, 00:30 Jean Abou Samra,  wrote:

> Le 20/11/2022 à 00:02, Luca Fascione a écrit :
> > Hi all,
> > I have some 2 voice music coming from musicxml like this
> >
> > 4 8. 16 ~ ~ 2.
> >
> > and I'd like to split it into 2 voices instead:
> >
> > <<
> > \new Voice ... { ... a4 g8. d16~ d2. ... }
> > \new Voice ... { ... c4 b8. g16~ g2. ... }
> > >>
> >
> > is there any software / trick that I could use?
> > (I use Frescobaldi, but I couldn't find a transformation for this
> purpose)
>
>
> There are a number of snippets floating around for that IIRC, basically
> variations on the theme
>
> \version "2.22.2"
>
> #(use-modules (ice-9 receive))
>
> selectNote =
> #(define-music-function (index music) (index? ly:music?)
> (music-map
>  (lambda (m)
>(if (music-is-of-type? m 'event-chord)
>(let ((elts (ly:music-property m 'elements)))
>  (receive (rhythmic arts)
>(partition (music-type-predicate 'rhythmic-event)
>   elts)
>(if (< (1- index)
>   (length rhythmic))
>(let* ((elt (list-ref elts (1- index)))
>   (elt-arts (ly:music-property elt
> 'articulations)))
>  (set! (ly:music-property elt 'articulations)
>(append elt-arts (map ly:music-deep-copy arts)))
>  elt)
>#{ #})))
>m))
>  music))
>
> mus = \relative {
>4 8. 16~ 2.
> }
>
> \new Staff <<
>\new Voice {
>  \voiceOne
>  \selectNote 2 \mus
>}
>\new Voice {
>  \voiceTwo
>  \selectNote 1 \mus
>}
>  >>
>
>
> Best,
> Jean
>
>

Splitting voices

[Luca Fascione]

Hi all,
I have some 2 voice music coming from musicxml like this

4 8. 16 ~ ~ 2.

and I'd like to split it into 2 voices instead:

<<
\new Voice ... { ... a4 g8. d16~ d2. ... }
\new Voice ... { ... c4 b8. g16~ g2. ... }
>>

is there any software / trick that I could use?
(I use Frescobaldi, but I couldn't find a transformation for this purpose)

Cheers,
Luca
-- 
Luca Fascione

Re: Chord names from two voices

[Luca Fascione]

Yes! Thanks Jean, I don't know why I didn't see this myself.

Cheers!
L

On Thu, 17 Nov 2022, 00:27 Jean Abou Samra,  wrote:

> Le 16/11/2022 à 23:44, Luca Fascione a écrit :
> > Hi all,
> > is there a way to run the chord naming logic from two voices (in my
> > case bass and guitar comping part) together?
> >
> > I have written-out guitar parts with rootless chords, and the roots
> > are in the double bass parts, and was hoping I could quickly recover a
> > starting point of a progression from that source
>
>
> You need to combine the parts in simultaneous music << >>.
>
>
> \version "2.22.2"
>
> musI = {
>c'
> }
>
> musII = {
>
> }
>
> <<
>\new ChordNames << \musI \musII >>
>\new Staff \musI
>\new Staff \musII
>  >>
>
>
>
> And it's as simple as that.
>
> Best,
> Jean
>
>

Chord names from two voices

[Luca Fascione]

Hi all,
is there a way to run the chord naming logic from two voices (in my case
bass and guitar comping part) together?

I have written-out guitar parts with rootless chords, and the roots are in
the double bass parts, and was hoping I could quickly recover a starting
point of a progression from that source

Cheers
Luca

-- 
Luca Fascione

Re: Should \partial accept music instead of duration?

[Luca Fascione]

What if instead of `\upbeat` (which is weirdly named when used in the
end-of-music/phrase/hymn/passage scenario) this new thing is just called
`\partialMusic`?
It's backward compatible, does something easy to use in some simple
scenarios, leaves everything else in place for more refined use cases,
and it's not weird either end of the music

L

Re: Should \partial accept music instead of duration?

[Luca Fascione]

What if you rotate them instead?
Rename the current \partial \partialDuration,
convert.ly now is just s/partial/partialDuration/
and \partial always takes music from now on

It's the same as Werner said, but keeps the good name

L

On Sun, 20 Mar 2022, 08:24 Werner LEMBERG,  wrote:

>
> > A convert-ly rule would probably not be possible given the
> > limited power of regular expressions.  As such, \partial might
> > need to support both duration and music arguments.  Initially I
> > thought this might not be possible, given that a naked duration
> > can be treated as music; but the following does seem to work:
> >>
> >> ...
> >> I wouldn't want to have to explain to users why these turn out
> >> different.
> >> \score {
> >>   \fixed c' {
> >> \partial 4. 4.
> >>   }
> >> }
> >> \score {
> >>   \fixed c' {
> >> \partial c4. c4.
> >>   }
> >> }
> >>
> >
> > Fair point, though the intention here would be that backwards
> > compatibility would only need to exist for a time.  A warning could
> > be issued whenever a user applies the older syntax; this would
> > inform the user of the impending breaking change while still
> > allowing existing code to compile.  When it is convenient, a future
> > release would only support music as the argument.
>
> What about providing a new command `\upbeat` and moving `\partial`
> into oblivion?  Compare this to `\tuplet` vs. `\times`.
>
>
> Werner
>
>

Re: Setting up classical guitar fingerings

[Luca Fascione]

Hi Valentin,
thanks for the super prompt reply!

On Sun, Mar 6, 2022 at 5:34 PM Valentin Petzel  wrote:

> So instead of doing the assoc-set! you might want to do something like
>
> (ly:grob-set-property! grob 'details `((beamed-lengths . ,stem-bmlgths)
>   . ,detls))
>

For my edification, I'll talk for a moment about the differences between
your code and this other attempt
(which also seems to work, I had gotten myself mixed up with what copy-list
does, and I had copy-list here, which isn't deep enough):

(ly:grob-set-property! grob 'details (assoc-set! (copy-tree detls)
'beamed-lengths stem-bmlgths))

could you set me straight, if needed?

 - Your code "just prepends" a new cell with a key we're interested in
right in front of the old content (with which shares structure)
 - It relies on lists being ordered, and all access to alists being a
straight linear scan front-to-back (point being: 'beamed-lengths appears
twice and we use "first one wins" to deal with the repeated key)
 - Your way is probably more economical than mine in that mine copies all
entries in the list, while yours just prepends one onto a list that is
otherwise shared
 - Your quasiquote segment produces exactly the same output as (append
'(('beamed-lengths . stem-bmlgths)) detls)

This solution of yours does not do any collision checking, which will make
> all
> Stems longer as long as there is a Fingering on the Stem. You might want
> to
> try something similar to what I did before to get some sort of collision
> checking in.
>

Yes definitely, I was just illustrating the problem. I'll definitely need
much more careful code than this in the final solution.
However, just so I don't overlook some aspect, could you give me a sense of
what collisions worry you?
One of the things I had found attractive in messing with beamed-lengths is
that the rest of the layout engine stays in place and operative.
So that line-to-line and beams-to-spanner things are handled by the rest of
lilypond as it stands today now?
(This was my reasoning also in trying to avoid xxx-offset stuff, because if
I understand right it happens post conflict-resolution
which seems not what I need). Am I not thinking this right?

Many thanks
Luca

Re: Setting up classical guitar fingerings

[Luca Fascione]

Thanks Valentin, this is useful.

Sounds like I'll be back with questions :-)

L

On Sat, Mar 5, 2022 at 5:46 PM Valentin Petzel  wrote:

> Hello Luca,
>
> the design of Lilypond inherently implies that there is no clear border
> between users and developers. Lilypond has an user interface, which is
> covered
> more or less in the docs, an extended interface in scheme, which is not
> documented that extensively, and the C++ code that works behind this,
> which
> barely documented. This means that in the Lilypond-verse it is useful to
> speak
> Lilypond, Scheme, C++ (and maybe Python), with basic users sitting at the
> Lilypond end and developers sitting at the C++ side, with the scheme stuff
> hanging in between.
>
> This means that you as a user can turn into a developer of some sort and
> write
> code into you Lilypond score that drastically changes how Lilypond does
> things
> (which is kind of cool). But if you are trying to do this you will often
> find
> yourself in the situation that you do not know how certain things are
> handled
> and the docs offer very little support.
>
> Thus I find it easier to look directly into the code. Lilypond has three
> directories of relevant code in it’s source directory:
>
> → Ly: Which contains code in Lilypond-Language, mostly setting up the
> defaults
> and music functions and such
> → scm: Which contains code in Scheme and contains a decent bit of
> Lilypond’s
> functionality, at least that part which does not matter that much
> performance-
> wise
> → lily: Which contains the c++-Code, which is the major part of the core
> functionality.
>
> If I’m looking for things I usually grep for these things in these
> directories. Eventually you’ll have a good idea where what is sitting. For
> example a scheme function like  ly:somethingA::somethingB is usually a
> callback to the c++ class somethingA, method somethingB.
>
> In scm you also have the definitions of the default grobs, so if you want
> to
> know what exact properties a grob has, you can look in define-grobs.scm.
> And
> similar stuff.
>
> And if you encounter something you really do not understand, ask the list.
> We’ve got some really marvellous people here who appear to know about
> everything you might want to know about Lilypond.
>
> Cheers,
> Valentin
>
> Am Samstag, 5. März 2022, 17:05:22 CET schrieb Luca Fascione:
> > I took a "brief" detour where I went and learned a bit about scheme
> >  Interlude
> > FWIW, I don't recall seeing this reference in your resources about
> learning
> > Scheme, so I'll leave a comment here:
> >
> > Paul Wilson (professor at UTexas, Austin) wrote some notes on Scheme
> approx
> > in 1996,
> > which I thought were extremely well conceived and clear. Certainly more
> to
> > the point that sicp
> > (which is a very interesting approach if you're learning Lisp and sw
> > engineering at the same time,
> > but I found did not make good use of my pre-acquired understanding of the
> > field, and just slowed me down).
> > I found the book very easy to follow and I loved that he teaches Scheme
> by
> > showing a series of gradually
> > more accurate implementations of scheme, partially in scheme. Also it
> > teaches Scheme in a way that is
> > very compatible with other programming languages, that makes it really
> easy
> > to keep it straight in one's head
> > what is new information or different vs what is just the same.
> > Unfortunately the several available copies online were never completed,
> so
> > there are several little bugs,
> > missing cross-references and other polish-grade features missing. But I
> > thought the juice of the book is certainly excellent.
> >
> > It seems Prof Wilson has since retired, and various threads on the
> internet
> > indicate folks are unable to reach him.
> > He seems to have done work in the 90's about garbage collection in
> > languages.
> > 
> >
> > Now that I can follow Scheme source with a certain level of confidence, I
> > went back to work on the fingering task,
> > and re-read Valentin's code. And thanks again kind sir.
> >
> > I was thinking again about the idea of instead of pushing the fingering
> > "down" (say we're doing \stemsUp) because the beams are too low,
> > to push the beams "up" to leave space for the fingering. And I played
> for a
> > second with Stem.details.beamed-lengths
> > (using an override in the .ly file, inbetween the notes) which seems to
> > achieve what we need.
> > So in order to automate that, I'd like to understand better

Re: Setting up classical guitar fingerings

[Luca Fascione]

I took a "brief" detour where I went and learned a bit about scheme
 Interlude
FWIW, I don't recall seeing this reference in your resources about learning
Scheme, so I'll leave a comment here:

Paul Wilson (professor at UTexas, Austin) wrote some notes on Scheme approx
in 1996,
which I thought were extremely well conceived and clear. Certainly more to
the point that sicp
(which is a very interesting approach if you're learning Lisp and sw
engineering at the same time,
but I found did not make good use of my pre-acquired understanding of the
field, and just slowed me down).
I found the book very easy to follow and I loved that he teaches Scheme by
showing a series of gradually
more accurate implementations of scheme, partially in scheme. Also it
teaches Scheme in a way that is
very compatible with other programming languages, that makes it really easy
to keep it straight in one's head
what is new information or different vs what is just the same.
Unfortunately the several available copies online were never completed, so
there are several little bugs,
missing cross-references and other polish-grade features missing. But I
thought the juice of the book is certainly excellent.

It seems Prof Wilson has since retired, and various threads on the internet
indicate folks are unable to reach him.
He seems to have done work in the 90's about garbage collection in
languages.


Now that I can follow Scheme source with a certain level of confidence, I
went back to work on the fingering task,
and re-read Valentin's code. And thanks again kind sir.

I was thinking again about the idea of instead of pushing the fingering
"down" (say we're doing \stemsUp) because the beams are too low,
to push the beams "up" to leave space for the fingering. And I played for a
second with Stem.details.beamed-lengths
(using an override in the .ly file, inbetween the notes) which seems to
achieve what we need.
So in order to automate that, I'd like to understand better the execution
of before-line-break and after-line-break callbacks.
I'm thinking that I could set up the fingering position in
Fingering.before-line-break and alter the stem length
(details.beamed-lengths, being my current thinking) in
Stem.before-line-break.

Really the question is a meta-question: I can certainly hack at this and
see what happens, but also how I do help myself learn this better:
where is the code that handles this stuff and how do I trace the sequence
of events around this stuff?

I'm looking for a couple one-liner breadcrumbs such as "this section of the
docs" (which I tried to read without much success),
"grep  and  in the source", it's all in "scm/". Vague pointers like that are hopefully all I'll need.

Many thanks,
Luca



On Mon, Feb 21, 2022 at 6:49 PM Luca Fascione  wrote:

> Yes exactly, because of how our finger to note relation works, the
> enhancement in readability with the indication right at the head is
> enormous.
>
> L
>
> On Mon, 21 Feb 2022, 18:16 Valentin Petzel,  wrote:
>
>> Sure. I suppose for a guitar person having stacked fingerings on top
>> would be
>> rather confusing, as there is no monotonic relating between finger and
>> pitch.
>> As such I suppose guitar people would want to use fingerings with left or
>> right
>> orientations in chords anyway.
>>
>> Cheers,
>> Valentin
>>
>> Am Montag, 21. Februar 2022, 17:47:58 CET schrieb Luca Fascione:
>> > I suspect we might be saying the same thing, Valentin?
>> >
>> > I was saying infix can be a bit awkward if you want 'pianist' chord
>> > fingering (just a stack of numbers above or below), and that your
>> original
>> > -1-2-3 reads quite nicely (as in: it's easy to see in your head
>> what
>> > you will get in the engraving just by looking at the source). So a
>> keyboard
>> > person wouldn't want to use infix, I don't think
>> >
>> > Whereas a guitar person might find it more attractive to use > g-3>
>> > because it's easier to keep it straight in your head what fingers you
>> use
>> > on what note that way
>> >
>> > L
>> >
>> > On Mon, Feb 21, 2022 at 5:42 PM Valentin Petzel 
>> wrote:
>> > > No, not nescessarily. If we want all Fingerings on top or below there
>> is
>> > > no real benefit of doing the chord thing. In fact doing that leads to
>> the
>> > > exact same issue of the fingering for d being next to the other ones.
>> > >
>> > > Cheers,
>> > > Valentin
>> > >
>> > > 21.02.2022 12:38:40 Luca Fascione :
>> > >
>> > > But wouldn't you finger that as ? (Didn't check the
>> number,
>> > > I'm jus

Re: Setting up classical guitar fingerings

[Luca Fascione]

Yes exactly, because of how our finger to note relation works, the
enhancement in readability with the indication right at the head is
enormous.

L

On Mon, 21 Feb 2022, 18:16 Valentin Petzel,  wrote:

> Sure. I suppose for a guitar person having stacked fingerings on top would
> be
> rather confusing, as there is no monotonic relating between finger and
> pitch.
> As such I suppose guitar people would want to use fingerings with left or
> right
> orientations in chords anyway.
>
> Cheers,
> Valentin
>
> Am Montag, 21. Februar 2022, 17:47:58 CET schrieb Luca Fascione:
> > I suspect we might be saying the same thing, Valentin?
> >
> > I was saying infix can be a bit awkward if you want 'pianist' chord
> > fingering (just a stack of numbers above or below), and that your
> original
> > -1-2-3 reads quite nicely (as in: it's easy to see in your head
> what
> > you will get in the engraving just by looking at the source). So a
> keyboard
> > person wouldn't want to use infix, I don't think
> >
> > Whereas a guitar person might find it more attractive to use  g-3>
> > because it's easier to keep it straight in your head what fingers you use
> > on what note that way
> >
> > L
> >
> > On Mon, Feb 21, 2022 at 5:42 PM Valentin Petzel 
> wrote:
> > > No, not nescessarily. If we want all Fingerings on top or below there
> is
> > > no real benefit of doing the chord thing. In fact doing that leads to
> the
> > > exact same issue of the fingering for d being next to the other ones.
> > >
> > > Cheers,
> > > Valentin
> > >
> > > 21.02.2022 12:38:40 Luca Fascione :
> > >
> > > But wouldn't you finger that as ? (Didn't check the
> number,
> > > I'm just meaning going infix vs postfix)
> > >
> > > I can see that this idea of mine does have issues for fingering your
> way
> > > around (which seems to me it's more of a fingering atop thing, like you
> > > would have in a keyboard score)
> > >
> > > L
> > >
> > > On Mon, 21 Feb 2022, 12:32 Valentin Petzel, 
> wrote:
> > >> Hello Luca,
> > >>
> > >> changing the X-parent to the NoteHead would mean that we are aligning
> the
> > >> Fingering horizontally wrt. the NoteHead instead of the whole
> NoteColumn.
> > >> This
> > >> would then mean that if for example due to some chord some note heads
> are
> > >> on
> > >> the other side of the Stem the alignment of something like  g>-1-2-3
> > >> would
> > >> change (disregarding that it wouldn’t even be clear what note head to
> > >> use).
> > >>
> > >> Cheers,
> > >> Valentin
> > >>
> > >> Am Montag, 21. Februar 2022, 09:19:30 CET schrieb Luca Fascione:
> > >> > Hi Thomas,
> > >> > thanks for your comment, this helps me refine my understanding of
> > >>
> > >> what's
> > >>
> > >> > going on.
> > >> >
> > >> > At the same time, while I do see that for other articulations
> (fermata,
> > >> > appoggiato) this parenting scheme works very well,
> > >> > I remain wondering whether for the style of layout of the fingering
> > >> > indications that I am after, the appropriate thing to do could be to
> > >>
> > >> change
> > >>
> > >> > the parenting altogether.
> > >> >
> > >> > If we look at chord for a second, I see the  thing
> as a
> > >> > trick because to me even for proper chords the whole FingeringColumn
> > >>
> > >> idea
> > >>
> > >> > is also a weird concept: imagine you're in say C major, and you're
> > >>
> > >> laying
> > >>
> > >> > out fingering on the left of a chord like Fm : I'm very
> > >>
> > >> unclear
> > >>
> > >> > whether the most readable solution is to have the fingerings stacked
> > >>
> > >> one
> > >>
> > >> > atop each other in a column (thereby more distant from f and c
> because
> > >>
> > >> of
> > >>
> > >> > the intervening flat on the aes) or if instead the fingerings on f
> and
> > >>
> > >> c
> > >>
> > >> > should be set tighter to their corresponding note heads and just the
> > >>
> 

Re: Setting up classical guitar fingerings

[Luca Fascione]

I suspect we might be saying the same thing, Valentin?

I was saying infix can be a bit awkward if you want 'pianist' chord
fingering (just a stack of numbers above or below), and that your original
-1-2-3 reads quite nicely (as in: it's easy to see in your head what
you will get in the engraving just by looking at the source). So a keyboard
person wouldn't want to use infix, I don't think

Whereas a guitar person might find it more attractive to use 
because it's easier to keep it straight in your head what fingers you use
on what note that way

L

On Mon, Feb 21, 2022 at 5:42 PM Valentin Petzel  wrote:

> No, not nescessarily. If we want all Fingerings on top or below there is
> no real benefit of doing the chord thing. In fact doing that leads to the
> exact same issue of the fingering for d being next to the other ones.
>
> Cheers,
> Valentin
>
> 21.02.2022 12:38:40 Luca Fascione :
>
> But wouldn't you finger that as ? (Didn't check the number,
> I'm just meaning going infix vs postfix)
>
> I can see that this idea of mine does have issues for fingering your way
> around (which seems to me it's more of a fingering atop thing, like you
> would have in a keyboard score)
>
> L
>
> On Mon, 21 Feb 2022, 12:32 Valentin Petzel,  wrote:
>
>> Hello Luca,
>>
>> changing the X-parent to the NoteHead would mean that we are aligning the
>> Fingering horizontally wrt. the NoteHead instead of the whole NoteColumn.
>> This
>> would then mean that if for example due to some chord some note heads are
>> on
>> the other side of the Stem the alignment of something like -1-2-3
>> would
>> change (disregarding that it wouldn’t even be clear what note head to
>> use).
>>
>> Cheers,
>> Valentin
>>
>> Am Montag, 21. Februar 2022, 09:19:30 CET schrieb Luca Fascione:
>> > Hi Thomas,
>> > thanks for your comment, this helps me refine my understanding of
>> what's
>> > going on.
>> >
>> > At the same time, while I do see that for other articulations (fermata,
>> > appoggiato) this parenting scheme works very well,
>> > I remain wondering whether for the style of layout of the fingering
>> > indications that I am after, the appropriate thing to do could be to
>> change
>> > the parenting altogether.
>> >
>> > If we look at chord for a second, I see the  thing as a
>> > trick because to me even for proper chords the whole FingeringColumn
>> idea
>> > is also a weird concept: imagine you're in say C major, and you're
>> laying
>> > out fingering on the left of a chord like Fm : I'm very
>> unclear
>> > whether the most readable solution is to have the fingerings stacked
>> one
>> > atop each other in a column (thereby more distant from f and c because
>> of
>> > the intervening flat on the aes) or if instead the fingerings on f and
>> c
>> > should be set tighter to their corresponding note heads and just the
>> aes
>> > fingering be displaced left horizontally, to allow for the flat. I
>> would
>> > like to experiment with various possibilities there, visually. I
>> suppose
>> > you could still displace horizontally inside the column, and then push
>> it
>> > all inwards closer to the chord even if the bboxes will overlap a
>> bit... I
>> > anticipate issues such as making sure the fingering for c' doesn't
>> > interfer with the ascender on the flat glyph, also.
>> >
>> > Which brings me to a question: what consequence would it have to
>> replace
>> > the X-parent and Y-parent of the fingering to be the NoteHead instead?
>> > (I guess there will be a need to deal with the accidentals at a
>> minimum)
>> > And also: how would I go at discovering these consequences without
>> using
>> > too much of you guys' time?
>> >
>> > Thanks again,
>> > Luca
>> >
>> > On Mon, Feb 21, 2022 at 1:22 AM Thomas Morley 
>>
>> >
>> > wrote:
>> > > Am So., 20. Feb. 2022 um 22:41 Uhr schrieb Luca Fascione <
>> > >
>> > > l.fasci...@gmail.com>:
>> > > >  a) I'm looking for a way to get the fingerings where I want them
>> > > >  without
>> > > >
>> > > > using one-note-chord tricks
>> > >
>> > > Well, for Fingerings not in chord, like b-1 or -2-1 X-parent
>> > > is NoteColumn _not_ NoteHead, Y-parent  is VerticalAxisGroup.
>> > > There is no direct way from NoteHead to Fingering and vice versa.
>> > >
>> > > Thus putting Fingering in-chord is unavoidable, imho, even for single
>> > > notes.
>> > > It is _not_ a trick, but a requirement.
>> > >
>> > > Furthermore, you say you set music for classical guitar, then chords
>> > > will happen anyway, although not in your example.
>> > > Please note, as soon as more than one in-chord Fingering is present a
>> > > FingeringColumn is created. Which will make things even more
>> > > complicated.
>> > > See
>> > > https://gitlab.com/lilypond/lilypond/-/issues/6125
>> > > https://gitlab.com/lilypond/lilypond/-/merge_requests/732
>> > >
>> > > Sorry to be of not more help,
>> > >
>> > >   Harm
>>
>>

Re: Setting up classical guitar fingerings

[Luca Fascione]

This is neat!
Thansk Valentin your explanation is very clear.

Question: I would have thought it should be the fingering mark to push the
beams away, not the other way around, I'm expecting it's uncool to go
rummage in the setup of the beams/stems in before-line-break? Or is this
how that handshake happens?

Another concept that in thus second seems related is the skyline: am I
right that this is the running Y direction minmax of the
NoteHead+accidentals? If I "just" made the skyline include the fingering
marks, would this push the beams up? Or am I just way off my rocker?

L

On Mon, 21 Feb 2022, 12:27 Valentin Petzel,  wrote:

> Hello Luca,
>
> A scheme engraver follows the concept of a closure, so it is some sort of
> function that returns different values on different arguments. This is
> somewhat
> the functional approach to OOP. So an engraver can be seen as an object
> that
> has some methods, which (as some sort of callback) need to be passed a
> reference to the actual engraver. So for example an acknowledger is  a
> function that takes as argument the engraver itself, the acknowledged grob
> and
> the original engraver producing the grob.
>
> About after-line-breaking: Spacing is a kind of problematic thing. Spacing
> might rely on line breaking, but line breaking might rely on spacing. Thus
> Lilypond first creates some sort of spacing approximation, it then
> calculates
> the line breaking, and then finalizes the spacing.
>
> Our problem is that something like Beaming and thus stem length (on which
> we
> want depend our spacing) are only really fixed after line breaking.
>
> For such things each grob as two callbacks before-line-breaking and after-
> line-breaking that are called on the grob before calculating the line
> breaking
> and after calculating the line breaking. Using this we can tweak the grobs
> after the line breaking is calculated to do what we want.
>
> In this case I’m using a custom engraver to store Stems and Note Heads
> inside
> the properties of the Fingering grob (so that we can access them) and then
> in
> after-line-breaking we take the length of the stem, we check if there is
> Beaming on the left side, if there is we get the lowest beam position and
> use
> it to estimate the height of the Beam (this does still get messed up by
> very
> slanted Beams, it might be useful to also get a reference to the Beam grob
> to
> factor in the angle of the Beam). With this we can estimate the free space
> between NoteHead and Beam, and depending on this space, shift the
> Fingering
> grob.
>
> Cheers,
> Valentin
>
> Am Montag, 21. Februar 2022, 08:58:36 CET schrieb Luca Fascione:
> > Hi Valentin, thank you this is super interesting. There's a lot of
> > information in there I want to read more carefully,
> > but for the moment I have one question: when is after-line-breaking
> invoke?
> > Or actually, better question: where do I go to discover when (and I guess
> > by what) after-line-breaking is invoked?
> >
> > Another thing at the moment I don't follow is the 'engraver' variable in
> > the scheme engraver you wrote:
> > where does that come from? (I suspect it's some kind of name available
> > where the engraver is invoked, but again: how would I go at discovering
> > this?)
> >
> > Many thanks, this is very helpful
> > Luca
> >
> > On Sun, Feb 20, 2022 at 11:07 PM Valentin Petzel 
> wrote:
> > > Hello,
> > >
> > > our problem here is that such things like the positioning of beams are
> not
> > > known for quite some time. But we could use something like
> > > after-line-breaking
> > > to adjust the results. Somewhat like here.
> > >
> > > Valentin
> > >
> > > Am Sonntag, 20. Februar 2022, 21:17:31 CET schrieb Luca Fascione:
> > > > So... would anybody be able to lend a hand here please?
> > > >
> > > > Many thanks
> > > > Luca
> > > >
> > > > On Sat, Feb 12, 2022 at 7:49 PM Luca Fascione 
> > >
> > > wrote:
> > > > > Hello,
> > > > > sorry for the double-post, I'm unsure whether this should go to
> -user
> > >
> > > or
> > >
> > > > > -devel.
> > > > >
> > > > > I'm looking for some guidance to set up fingering on classical
> guitar
> > > > > sheets.
> > > > >
> > > > > I am attaching a simple piece of music, with two engraving sets
> > >
> > > (measures
> > >
> > > > > 1-5 and 6-10), one "as-is" from lilypond, the other using some
> >

Re: Setting up classical guitar fingerings

[Luca Fascione]

But wouldn't you finger that as ? (Didn't check the number,
I'm just meaning going infix vs postfix)

I can see that this idea of mine does have issues for fingering your way
around (which seems to me it's more of a fingering atop thing, like you
would have in a keyboard score)

L

On Mon, 21 Feb 2022, 12:32 Valentin Petzel,  wrote:

> Hello Luca,
>
> changing the X-parent to the NoteHead would mean that we are aligning the
> Fingering horizontally wrt. the NoteHead instead of the whole NoteColumn.
> This
> would then mean that if for example due to some chord some note heads are
> on
> the other side of the Stem the alignment of something like -1-2-3
> would
> change (disregarding that it wouldn’t even be clear what note head to use).
>
> Cheers,
> Valentin
>
> Am Montag, 21. Februar 2022, 09:19:30 CET schrieb Luca Fascione:
> > Hi Thomas,
> > thanks for your comment, this helps me refine my understanding of what's
> > going on.
> >
> > At the same time, while I do see that for other articulations (fermata,
> > appoggiato) this parenting scheme works very well,
> > I remain wondering whether for the style of layout of the fingering
> > indications that I am after, the appropriate thing to do could be to
> change
> > the parenting altogether.
> >
> > If we look at chord for a second, I see the  thing as a
> > trick because to me even for proper chords the whole FingeringColumn idea
> > is also a weird concept: imagine you're in say C major, and you're laying
> > out fingering on the left of a chord like Fm : I'm very unclear
> > whether the most readable solution is to have the fingerings stacked one
> > atop each other in a column (thereby more distant from f and c because of
> > the intervening flat on the aes) or if instead the fingerings on f and c
> > should be set tighter to their corresponding note heads and just the aes
> > fingering be displaced left horizontally, to allow for the flat. I would
> > like to experiment with various possibilities there, visually. I suppose
> > you could still displace horizontally inside the column, and then push it
> > all inwards closer to the chord even if the bboxes will overlap a bit...
> I
> > anticipate issues such as making sure the fingering for c' doesn't
> > interfer with the ascender on the flat glyph, also.
> >
> > Which brings me to a question: what consequence would it have to replace
> > the X-parent and Y-parent of the fingering to be the NoteHead instead?
> > (I guess there will be a need to deal with the accidentals at a minimum)
> > And also: how would I go at discovering these consequences without using
> > too much of you guys' time?
> >
> > Thanks again,
> > Luca
> >
> > On Mon, Feb 21, 2022 at 1:22 AM Thomas Morley 
> >
> > wrote:
> > > Am So., 20. Feb. 2022 um 22:41 Uhr schrieb Luca Fascione <
> > >
> > > l.fasci...@gmail.com>:
> > > >  a) I'm looking for a way to get the fingerings where I want them
> > > >  without
> > > >
> > > > using one-note-chord tricks
> > >
> > > Well, for Fingerings not in chord, like b-1 or -2-1 X-parent
> > > is NoteColumn _not_ NoteHead, Y-parent  is VerticalAxisGroup.
> > > There is no direct way from NoteHead to Fingering and vice versa.
> > >
> > > Thus putting Fingering in-chord is unavoidable, imho, even for single
> > > notes.
> > > It is _not_ a trick, but a requirement.
> > >
> > > Furthermore, you say you set music for classical guitar, then chords
> > > will happen anyway, although not in your example.
> > > Please note, as soon as more than one in-chord Fingering is present a
> > > FingeringColumn is created. Which will make things even more
> > > complicated.
> > > See
> > > https://gitlab.com/lilypond/lilypond/-/issues/6125
> > > https://gitlab.com/lilypond/lilypond/-/merge_requests/732
> > >
> > > Sorry to be of not more help,
> > >
> > >   Harm
>
>

Re: Setting up classical guitar fingerings

[Luca Fascione]

Hi Thomas,
thanks for your comment, this helps me refine my understanding of what's
going on.

At the same time, while I do see that for other articulations (fermata,
appoggiato) this parenting scheme works very well,
I remain wondering whether for the style of layout of the fingering
indications that I am after, the appropriate thing to do could be to change
the parenting altogether.

If we look at chord for a second, I see the  thing as a
trick because to me even for proper chords the whole FingeringColumn idea
is also a weird concept: imagine you're in say C major, and you're laying
out fingering on the left of a chord like Fm : I'm very unclear
whether the most readable solution is to have the fingerings stacked one
atop each other in a column (thereby more distant from f and c because of
the intervening flat on the aes) or if instead the fingerings on f and c
should be set tighter to their corresponding note heads and just the aes
fingering be displaced left horizontally, to allow for the flat. I would
like to experiment with various possibilities there, visually. I suppose
you could still displace horizontally inside the column, and then push it
all inwards closer to the chord even if the bboxes will overlap a bit... I
anticipate issues such as making sure the fingering for c' doesn't
interfer with the ascender on the flat glyph, also.

Which brings me to a question: what consequence would it have to replace
the X-parent and Y-parent of the fingering to be the NoteHead instead?
(I guess there will be a need to deal with the accidentals at a minimum)
And also: how would I go at discovering these consequences without using
too much of you guys' time?

Thanks again,
Luca

On Mon, Feb 21, 2022 at 1:22 AM Thomas Morley 
wrote:

> Am So., 20. Feb. 2022 um 22:41 Uhr schrieb Luca Fascione <
> l.fasci...@gmail.com>:
>
> >  a) I'm looking for a way to get the fingerings where I want them without
> > using one-note-chord tricks
>
> Well, for Fingerings not in chord, like b-1 or -2-1 X-parent
> is NoteColumn _not_ NoteHead, Y-parent  is VerticalAxisGroup.
> There is no direct way from NoteHead to Fingering and vice versa.
>
> Thus putting Fingering in-chord is unavoidable, imho, even for single
> notes.
> It is _not_ a trick, but a requirement.
>
> Furthermore, you say you set music for classical guitar, then chords
> will happen anyway, although not in your example.
> Please note, as soon as more than one in-chord Fingering is present a
> FingeringColumn is created. Which will make things even more
> complicated.
> See
> https://gitlab.com/lilypond/lilypond/-/issues/6125
> https://gitlab.com/lilypond/lilypond/-/merge_requests/732
>
> Sorry to be of not more help,
>   Harm
>

Re: Setting up classical guitar fingerings

[Luca Fascione]

Hi Valentin, thank you this is super interesting. There's a lot of
information in there I want to read more carefully,
but for the moment I have one question: when is after-line-breaking invoke?
Or actually, better question: where do I go to discover when (and I guess
by what) after-line-breaking is invoked?

Another thing at the moment I don't follow is the 'engraver' variable in
the scheme engraver you wrote:
where does that come from? (I suspect it's some kind of name available
where the engraver is invoked, but again: how would I go at discovering
this?)

Many thanks, this is very helpful
Luca

On Sun, Feb 20, 2022 at 11:07 PM Valentin Petzel  wrote:

> Hello,
>
> our problem here is that such things like the positioning of beams are not
> known for quite some time. But we could use something like
> after-line-breaking
> to adjust the results. Somewhat like here.
>
> Valentin
>
> Am Sonntag, 20. Februar 2022, 21:17:31 CET schrieb Luca Fascione:
> > So... would anybody be able to lend a hand here please?
> >
> > Many thanks
> > Luca
> >
> > On Sat, Feb 12, 2022 at 7:49 PM Luca Fascione 
> wrote:
> > > Hello,
> > > sorry for the double-post, I'm unsure whether this should go to -user
> or
> > > -devel.
> > >
> > > I'm looking for some guidance to set up fingering on classical guitar
> > > sheets.
> > >
> > > I am attaching a simple piece of music, with two engraving sets
> (measures
> > > 1-5 and 6-10), one "as-is" from lilypond, the other using some trickery
> > > involving one-note chords, purely to show a sample of what the result
> I'm
> > > after (and it's an approximation), vs what I get at the moment.
> > >
> > > Measures 1-5 in the source look like what I am intending to type, but
> it
> > > has a number of engraving defects I don't understand (you can see the
> > > beams
> > > don't  avoid the fingerings, nor they are located correctly wrt the
> > > accidentals, the second beat of measure 5 illustrates this well. I'm
> not
> > > super in love with measure 10 either, but if I understand the docs
> > > correctly, the issue there is that the 'offset' correction is applied
> > > post-layout, and so naturally it won't back-affect the placement of the
> > > beams.
> > >
> > > I have made several other experiments, I'm just not wanting to waste
> > > people's time. But setting Fingering.side-axis = #X seems somewhat
> > > promising, but it seems unable to find any usable Y data about the
> > > parents,
> > > and smashes all numbers on the B line, as well as not dealing with
> > > accidentals.
> > >
> > > I have an engraving project in front of me, for which I'm more than
> happy
> > > to put in the time to contribute the code to a proper solution myself,
> and
> > > I really don't want to make poor use of time from folks busy with other
> > > work, but I feel I'll need some level of guidance as to what to do. For
> > > context I can do C++ and I can manage guile ok (I'm a software engineer
> > > for
> > > work, I'm mostly working in the field of computer graphics).
> > >
> > > I was looking into this problem several years ago also, and Han-Wen
> > > Nienhuys at the time suggested I should use a positioning callback
> > > attached
> > > to the Fingering grobs, but I couldn't find a way to do such a thing
> (in
> > > particular I can't find what property to use for this). So far I've
> traced
> > > the Fingering system to be an instance of the Articulations/Scripts
> > > system,
> > > but that's as far as I got.
> > >
> > > It seems to me what's needed would be to decide where the heads go,
> then
> > > the accidentals, at this stage deal with the fingering and only then
> there
> > > would be enough bboxes to reason about the beaming (this is the skyline
> > > concept I think). In reasoning about how Articulations are engraved,
> it's
> > > possible the order of events for fingering would be different from the
> > > order of events in other articulations (which I think are laid out
> after
> > > beams are in place, if I am not mistaken), warranting a bigger change,
> but
> > > I have no idea where that is located/managed.
> > >
> > > Many thanks for your time,
> > > Luca
>
>

Re: Setting up classical guitar fingerings

[Luca Fascione]

Thanks Jean,
I thought a somewhat more complete example of the configurations I'm
looking at would help get a sense of the scope of the problem,
and also that the solution would be an easy "do this" or "look here" kind
of answer.
My concern with a tiny example is that it risks to create a rather longer
chain of emails about "what about this case, and that case" which can then
turn into a "why didn't you tell me before you needed all these things"
kind of discussion. I'd have thought that is also poor use of people's
time, you see.

That being said, I really appreciate you spending the time to do this,
I'll try to keep my examples shorter in my future questions.
And please, just tell me and I'll do the legwork of trimming things down,
I completely agree with you that your time can and should be put to better
use than deleting my source.

Going back to the example itself, there are two questions in flight here:
 a) I'm looking for a way to get the fingerings where I want them without
using one-note-chord tricks
 b) I'm also looking to position fingering a bit more finely than what the
second piece shows (as you can see, while some fingerings look passable,
others are not in a well placed location, for various reasons): referring
to the longer example in the pdf, in general it's clear that the beaming
layout is not taking into account the fingerings, say bar 6, the high e-0
or the slur in bar 9: the beams should automatically set a bit looser than
they are to make it all breathe more openly, at least to my taste. Another
example of a different kind is the eis-3 in bar 10: the 3 sits awkwardly in
the f-space which makes it hard to read, I feel nudging it elsewhere would
make it easier to see (in this case I'd probably pick a half-space up).

I feel there's some overlap in the two answers though (fingerings need to
deal with accidentals, for example).
For a) I've reworked your example into what below

\version "2.22.1"

\layout {
   \context {
 \Voice
 \override Fingering.X-offset = #0.5
 \override Fingering.parent-alignment-X = #-1
 %%\override Fingering.self-alignment-X = #1
 %%\override Fingering.self-alignment-Y = #-1
 %%\override Fingering.side-axis = #X
 \override Fingering.staff-padding = #'()
 \override Fingering.add-stem-support = ##f
   }
}

% this is what I want to type
target = \relative {
   c'16-3 d-3 e-3 g-3
   <<
 { c,16 e'32 g-4 g16 b }
 \\
 { d,,,8.-0 dis''16-3 }
   >>
}

% this is something that currently gets some of the way there
reference = \relative {
   16   
   <<
 { c,16 e'32  g16 b }
 \\
 { 8. 16 }
   >>
}

{
   \target
   \set fingeringOrientations = #'(left)
   \override Staff.Fingering.extra-offset = #'(0.125 . 0.5)
   \reference
}

As I said, I'm more than happy to write code, I'm not necessarily looking
for a "simple" solution.
If the answer is: "it's a big change involving steps a to f", I'm happy to
have at it, under somebody's guidance.
Given that solving this problem is a need of mine, I feel it's completely
fine that it ends up being my cost to fix it,
all I'm looking for is a few breadcrumbs.

Thanks again,
L

On Sun, Feb 20, 2022 at 9:54 PM Jean Abou Samra  wrote:

> Le 20/02/2022 à 21:17, Luca Fascione a écrit :
> > So... would anybody be able to lend a hand here please?
> >
> > Many thanks
> > Luca
>
>
>
> It would be helpful if you provided smaller examples.
> I'm not saying this as a reprimand, but as friendly
> advice on how to get people to help you. Personally,
> I had started experimenting with the problem when you
> first asked, but since understanding all the code already
> took me too much of the limited time I can spend for
> answering questions on -user, I stopped at that point.
> Here is what I would give as an example:
>
>
> \version "2.22.1"
>
> \layout {
>\context {
>  \Voice
>  \override Fingering.X-offset = #0.5
>  \override Fingering.parent-alignment-X = #-1
>  %%\override Fingering.self-alignment-X = #1
>  %%\override Fingering.self-alignment-Y = #-1
>  %%\override Fingering.side-axis = #X
>  \override Fingering.staff-padding = #'()
>  \override Fingering.add-stem-support = ##f
>}
> }
>
>
> music = \relative {
>16   
><<
>  {
>c,16
>e'32 
>g16 b
>  }
>  \\
>  {
>8.
>16
>  }
>>>
> }
>
> {
>\music
>\set fingeringOrientations = #'(left)
>\override Staff.Fingering.extra-offset = #'(0.125 . 0.5)
>\music
> }
>
>
> That's longer than most examples posted on this list, but
> much shorter than the original. It probably doesn't make
> any sense musically, but that is not the point. It encompasses
> (I think) all of the problems raised by the original,
> and can be grasped much quicker.
>
> Doing that enough time has passed that I already need to
> be doing something else, so I will look into solutions
> later :-)
>
> All the best,
> Jean
>
>
>

Re: Setting up classical guitar fingerings

[Luca Fascione]

So... would anybody be able to lend a hand here please?

Many thanks
Luca

On Sat, Feb 12, 2022 at 7:49 PM Luca Fascione  wrote:

> Hello,
> sorry for the double-post, I'm unsure whether this should go to -user or
> -devel.
>
> I'm looking for some guidance to set up fingering on classical guitar
> sheets.
>
> I am attaching a simple piece of music, with two engraving sets (measures
> 1-5 and 6-10), one "as-is" from lilypond, the other using some trickery
> involving one-note chords, purely to show a sample of what the result I'm
> after (and it's an approximation), vs what I get at the moment.
>
> Measures 1-5 in the source look like what I am intending to type, but it
> has a number of engraving defects I don't understand (you can see the beams
> don't  avoid the fingerings, nor they are located correctly wrt the
> accidentals, the second beat of measure 5 illustrates this well. I'm not
> super in love with measure 10 either, but if I understand the docs
> correctly, the issue there is that the 'offset' correction is applied
> post-layout, and so naturally it won't back-affect the placement of the
> beams.
>
> I have made several other experiments, I'm just not wanting to waste
> people's time. But setting Fingering.side-axis = #X seems somewhat
> promising, but it seems unable to find any usable Y data about the parents,
> and smashes all numbers on the B line, as well as not dealing with
> accidentals.
>
> I have an engraving project in front of me, for which I'm more than happy
> to put in the time to contribute the code to a proper solution myself, and
> I really don't want to make poor use of time from folks busy with other
> work, but I feel I'll need some level of guidance as to what to do. For
> context I can do C++ and I can manage guile ok (I'm a software engineer for
> work, I'm mostly working in the field of computer graphics).
>
> I was looking into this problem several years ago also, and Han-Wen
> Nienhuys at the time suggested I should use a positioning callback attached
> to the Fingering grobs, but I couldn't find a way to do such a thing (in
> particular I can't find what property to use for this). So far I've traced
> the Fingering system to be an instance of the Articulations/Scripts system,
> but that's as far as I got.
>
> It seems to me what's needed would be to decide where the heads go, then
> the accidentals, at this stage deal with the fingering and only then there
> would be enough bboxes to reason about the beaming (this is the skyline
> concept I think). In reasoning about how Articulations are engraved, it's
> possible the order of events for fingering would be different from the
> order of events in other articulations (which I think are laid out after
> beams are in place, if I am not mistaken), warranting a bigger change, but
> I have no idea where that is located/managed.
>
> Many thanks for your time,
> Luca
>

Re: LilyPond 2.23.6 released

[Luca Fascione]

Hi Thomas,
maybe this can be handy: the `moreutils` package has a utility called `ts`,
that will prepend a timestamp to each line of output.
If you pipe the output of your compilation into it, you can get timing
information quite easily, here's an example:

% ls | ts -s "%H:%M:%.S"
00:00:00.13 _config
00:00:00.000546 myfavoritethings_ob-cm.pdf
00:00:00.000567 myfavoritethings_ob-em.pdf
00:00:00.000580 openbook_v1-1.pdf
00:00:00.000591 openbook_v1.ly
00:00:00.000602 openbook_v1.pdf
00:00:00.000613 src

Here I'm using "-s" to mean "time relative to the start time", and "%.S" in
the format to mean "print out subsecond timestamps".
(As your runs are sub-minute, you can probably use "%M:%.S" if you feel
like saving some 0's on the left)
You can capture stderr also adding `2>&1` before the pipe, like this:
" 2>&1 | ts ..."

The moreutils package is installed in Linux distributions but doesn't
appear to be there by default on MacOS,
our friends on stackexchange indicate that on brew you'd use `brew install
moreutils` to get the package (I just tried this, it worked fine for me),
on macports I think it's something like `sudo port install moreutils` (but
I don't use macports, so I haven't tested this one).

HTH,
Luca

On Sun, Feb 20, 2022 at 9:26 AM Thomas Scharkowski <
t.scharkow...@t-online.de> wrote:

> Quick answer: I can notice the speed difference in the terminal output
> from the very start.
> I will try the diff later.
> Thomas
>
> > Am 19.02.2022 um 20:12 schrieb Jean Abou Samra :
> >
> > Le 19/02/2022 à 16:41, Thomas Scharkowski a écrit :
> >> One more test:
> >> I installed both versions on a 2013 iMac intel Core i5.
> >>
> >> 24,3“ MacPorts version
> >> 51,4“ gitab version
> >
> >
> > OK, bear with me. Can you please take the following steps
> > and report results? It is really important for us to identify
> > what is causing this slowdown.
> >
> > First, does it look like one step of the compilation in particular
> > is slow (for example, it takes time during "Preprocessing graphical
> > objects"), or do all steps take more time? Pro tip: run lilypond with
> > --verbose to have a more fine-grained view of the process.
> >
> > Second, edit the file lily.scm (should be under
> > /path/to/lilypond-2.23.6/share/lilypond/2.23.6/scm/lily)
> > to apply the following diff:
> >
> >
> > @@ -844,8 +844,11 @@ PIDs or the number of the process."
> >
> >  
> >
> > +(use-modules (statprof))
> > +
> >  (define-public (lilypond-main files)
> >"Entry point for LilyPond."
> > +  (statprof (lambda ()
> >(eval-string (ly:command-line-code))
> >(if (ly:get-option 'help)
> >(begin (ly:option-usage)
> > @@ -927,7 +930,7 @@ PIDs or the number of the process."
> > (ly:exit 1 #f))
> >  (begin
> >(ly:exit 0 #f)
> > -
> > +))
> >  (define-public (session-start-record)
> >(for-each (lambda (v)
> > ;; import all public session variables natively into parser
> >
> >
> >
> > Namely, add "(use-modules (statprof))" before the definition of
> > lilypond-main, "(statprof (lambda ()" after the line "Entry point
> > for LilyPond", and "))" after the function. This makes LilyPond
> > run under a profiling tool and report output at the end of the
> > compilation. Now run once with GUILE_AUTO_COMPILE=1, to recompile
> > lily.scm. The second run will be clean (all files byte-compiled);
> > can you report the big list of timings that is printed at the end?
> >
> > Thanks in advance,
> > Jean
> >
>
>
>

Re: Fwd: Slash chords

[Luca Fascione]

Actually, sorry for not thinking about this before, but writing it in LaTeX
gave me an idea to illustrate what I'd like to achieve (roughly).

%%
\version "2.18.2"
% test for setting slash chords with realbookchords font

chExceptionMusic = {
  1-\markup { "7" }
  1-\markup { "<7/" \raise #-2.5 "B" } % for illustration purposes
only
  1-\markup { ">" }
}

chExceptions = #( append
  ( sequential-music-to-chord-exceptions chExceptionMusic #t)
  ignatzekExceptions)

\score {
  \new StaffGroup <<
\chords {
\override Score.ChordName #'font-name = #"New Real Book Chords"
\set chordNameExceptions = #chExceptions
\set slashChordSeparator = "/"
f2.:m c4:7/e c2:maj7
}
\new Staff { \key aes \major \time 3/4 c'4 aes'2 c'4 bes'2 }
  >>
  \layout {}
}
%%

You can see I have hardcoded the form of Cmaj7 to render as Cmaj7/B, but
the spacing feels like a step in the right direction (admittedly the
kerning could use work, but it feels like a reasonable compromise)

I have attached the corresponding pdf I get, so you can see what I mean

Thanks,
Luca

On Sat, Nov 21, 2015 at 9:27 AM, Luca Fascione <l.fasci...@gmail.com> wrote:

> Thanks Simon!
> I'm also attaching the small GIF from the other website for reference,
> and the result I presently get from 2.18.2.
>
> It seems this question has come up a long time ago but I couldn't find a
> definitive resolution to it.
>
> As I was saying, I am happy to contribute time to the coding if it helps,
> but I could certainly use a bit of guidance as to where to start.
>
> Things are never this simple, but in LaTeX-speak it seems to me all it's
> needed is to wrap the bass note in something more or less like 
> \raisebox{-1ex}{E}
> (and maybe mess a bit with the kerning of the slash, hard to say without
> trying it out).
>
> I've tried to look in the source (for 2.18.2) and I found that in
> chord-ignatzek-names.scm, around line 210, it calls a routine names
> make-line-markup, which might be near where the modification needs to
> happen. But I have no idea how to override the behaviour of that piece of
> code from my source file.
>
> Thanks for your help
> Luca
>
> On Fri, Nov 20, 2015 at 11:36 PM, Simon Albrecht <simon.albre...@mail.de>
> wrote:
>
>> On 20.11.2015 10:56, Urs Liska wrote:
>>
>>> Dear Luca,
>>>
>>> this is a question you should ask on the lilypond-user mailing list.
>>> I have forwarded it there but I strongly suggest you subscribe at
>>> https://lists.gnu.org/mailman/listinfo/lilypond-user to automatically
>>> receive any replies.
>>>
>>> Best
>>> Urs
>>>
>>> Am 20.11.2015 um 10:46 schrieb LilyPond blog contact form:
>>>
>>>>
>>>> /From:/ Luca Fascione
>>>>
>>>> /Message:/
>>>>
>>>> Hello,
>>>> I've been using lilypond for a little while now and I rather like it.
>>>>
>>>> I've been able to achieve most of what I want for my engraving needs,
>>>> but I think I need some help to set up slash chords like in this example
>>>>
>>>> http://www.apianotuner.com/img/RealBookSample.gif
>>>>
>>>> I'm using the font New Real Book Chords distributed here
>>>> https://musescore.org/node/7785, and I have setup exceptions to the
>>>> Ignatzek rules to drive the font correctly, but I can't find a way to tell
>>>> lilypond that the bass note should be set lowered (like in the gif above).
>>>>
>>>> I have put a small repro case at the bottom of this message
>>>>
>>>> Any help or indication you could spare would be greatly appreciated (I
>>>> am a fairly accomplished software engineer and I'm not afraid of writing
>>>> code to achieve this, although I have to confess I am a C++ guy, not a
>>>> Guile/Scheme guy).
>>>>
>>>> Thanks very much
>>>> Luca Fascione
>>>>
>>>> 
>>>> example.ly
>>>>
>>>>
>> Too bad the code got messed up. Here is a (hopefully) clean version:
>> %%
>> \version "2.18.2"
>> % test for setting slash chords with realbookchords font
>>
>> chExceptionMusic = {
>>   1-\markup { "7" }
>>   1-\markup { ">" }
>> }
>>
>> chExceptions = #(append
>>   (sequential-music-to-chord-exceptions chExceptionMusic
>> #t)
>>   ignatzekExceptions)
>>
>> \score {
>>   \new StaffGroup <<
>> \chords {
>>   \override Score.ChordName.font-name = #"New Real Book Chords"
>>   \set chordNameExceptions = #chExceptions
>>   \set slashChordSeparator = "/"
>>   f2.:m c:7/e
>> }
>> \new Staff { \key aes \major \time 3/4 c'4 aes'2 c'4 bes'2 }
>>   >>
>>   \layout {}
>> }
>> %
>> and once attached, just in case.
>>
>> Yours, Simon
>>
>
>


slashchordtest.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fwd: Slash chords

[Luca Fascione]

Thanks Simon!
I'm also attaching the small GIF from the other website for reference,
and the result I presently get from 2.18.2.

It seems this question has come up a long time ago but I couldn't find a
definitive resolution to it.

As I was saying, I am happy to contribute time to the coding if it helps,
but I could certainly use a bit of guidance as to where to start.

Things are never this simple, but in LaTeX-speak it seems to me all it's
needed is to wrap the bass note in something more or less like
\raisebox{-1ex}{E}
(and maybe mess a bit with the kerning of the slash, hard to say without
trying it out).

I've tried to look in the source (for 2.18.2) and I found that in
chord-ignatzek-names.scm, around line 210, it calls a routine names
make-line-markup, which might be near where the modification needs to
happen. But I have no idea how to override the behaviour of that piece of
code from my source file.

Thanks for your help
Luca

On Fri, Nov 20, 2015 at 11:36 PM, Simon Albrecht <simon.albre...@mail.de>
wrote:

> On 20.11.2015 10:56, Urs Liska wrote:
>
>> Dear Luca,
>>
>> this is a question you should ask on the lilypond-user mailing list.
>> I have forwarded it there but I strongly suggest you subscribe at
>> https://lists.gnu.org/mailman/listinfo/lilypond-user to automatically
>> receive any replies.
>>
>> Best
>> Urs
>>
>> Am 20.11.2015 um 10:46 schrieb LilyPond blog contact form:
>>
>>>
>>> /From:/ Luca Fascione
>>>
>>> /Message:/
>>>
>>> Hello,
>>> I've been using lilypond for a little while now and I rather like it.
>>>
>>> I've been able to achieve most of what I want for my engraving needs,
>>> but I think I need some help to set up slash chords like in this example
>>>
>>> http://www.apianotuner.com/img/RealBookSample.gif
>>>
>>> I'm using the font New Real Book Chords distributed here
>>> https://musescore.org/node/7785, and I have setup exceptions to the
>>> Ignatzek rules to drive the font correctly, but I can't find a way to tell
>>> lilypond that the bass note should be set lowered (like in the gif above).
>>>
>>> I have put a small repro case at the bottom of this message
>>>
>>> Any help or indication you could spare would be greatly appreciated (I
>>> am a fairly accomplished software engineer and I'm not afraid of writing
>>> code to achieve this, although I have to confess I am a C++ guy, not a
>>> Guile/Scheme guy).
>>>
>>> Thanks very much
>>> Luca Fascione
>>>
>>> 
>>> example.ly
>>>
>>>
> Too bad the code got messed up. Here is a (hopefully) clean version:
> %%
> \version "2.18.2"
> % test for setting slash chords with realbookchords font
>
> chExceptionMusic = {
>   1-\markup { "7" }
>   1-\markup { ">" }
> }
>
> chExceptions = #(append
>   (sequential-music-to-chord-exceptions chExceptionMusic
> #t)
>   ignatzekExceptions)
>
> \score {
>   \new StaffGroup <<
> \chords {
>   \override Score.ChordName.font-name = #"New Real Book Chords"
>   \set chordNameExceptions = #chExceptions
>   \set slashChordSeparator = "/"
>   f2.:m c:7/e
> }
> \new Staff { \key aes \major \time 3/4 c'4 aes'2 c'4 bes'2 }
>   >>
>   \layout {}
> }
> %
> and once attached, just in case.
>
> Yours, Simon
>


slashchordtest.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fwd: Slash chords

[Luca Fascione]

Wow looks brilliant! I'm away from my computer at the moment but I'll test
later in the day and report, I think it's great!  Thanks a lot Simon!
Luca
On 21 Nov 2015 10:36, "Simon Albrecht" <simon.albre...@mail.de> wrote:

> Hello Luca,
>
> with the help of the french blog post jmechmech linked in his reply, I
> cooked up the following from your code:
>
> 
> \version "2.18.2"
>
> #(define (lower-extension pitch chbass)
>"Return lowered markup for pitch note name."
>#{
>  \markup \raise #-1.9 \halign #0.2
>  #(note-name->markup pitch chbass)
>#})
>
> chExceptionMusic = {
>   1-\markup { "7" }
>   %1-\markup { "<7/" \raise #-2.5 "B" } % for illustration
> purposes only
>   1-\markup { ">" }
> }
>
> chExceptions = #(append
>  (sequential-music-to-chord-exceptions chExceptionMusic #t)
>  ignatzekExceptions)
>
> \layout {
>   \context {
> \ChordNames
> \override ChordName.font-name = #"New Real Book Chords"
> chordNameExceptions = \chExceptions
> slashChordSeparator = \markup {
>   % the \hspace commands simulate kerning
>   \hspace #-.7
>   \fontsize #1 \lower #1.2 \rotate #-10 "/"
>   \hspace #-.1
> }
> chordNoteNamer = #lower-extension
>   }
> }
>
> \score {
>   \new StaffGroup <<
> \chords {
>   f2.:m c4:7/e c2:maj7
> }
> \new Staff { \key aes \major \time 3/4 c'4 aes'2 c'4 bes'2 }
>   >>
>   \layout { }
> }
> %%
>
> Does that do what you want? I couldn’t test it with the actual font, of
> course, only with LilyPond’s default Sans font. So you’ll likely have to
> adjust the numerical values in lines 6 and 27–29 to taste. See <
> http://lilypond.org/doc/v2.18/Documentation/notation/text-markup-commands>
> for documentation on the markup commands (you can also look them up in the
> index, section D of the Notation Reference).
> You can fitfully use the \layout {} block in a stylesheet (i.e., a
> separate .ily file to \include everywhere you want this kind of chord names
> display).
>
> HTH, Simon
>
> On 20.11.2015 22:04, Luca Fascione wrote:
>
>> Actually, sorry for not thinking about this before, but writing it in
>> LaTeX gave me an idea to illustrate what I'd like to achieve (roughly).
>>
>> %%
>> \version "2.18.2"
>> % test for setting slash chords with realbookchords font
>>
>> chExceptionMusic = {
>>   1-\markup { "7" }
>>   1-\markup { "<7/" \raise #-2.5 "B" } % for illustration
>> purposes only
>>   1-\markup { ">" }
>> }
>>
>> chExceptions = #( append
>>   ( sequential-music-to-chord-exceptions chExceptionMusic #t)
>>   ignatzekExceptions)
>>
>> \score {
>>   \new StaffGroup <<
>> \chords {
>> \override Score.ChordName #'font-name = #"New Real Book Chords"
>> \set chordNameExceptions = #chExceptions
>> \set slashChordSeparator = "/"
>> f2.:m c4:7/e c2:maj7
>> }
>> \new Staff { \key aes \major \time 3/4 c'4 aes'2 c'4 bes'2 }
>>   >>
>>   \layout {}
>> }
>> %%
>>
>> You can see I have hardcoded the form of Cmaj7 to render as Cmaj7/B, but
>> the spacing feels like a step in the right direction (admittedly the
>> kerning could use work, but it feels like a reasonable compromise)
>>
>> I have attached the corresponding pdf I get, so you can see what I mean
>>
>> Thanks,
>> Luca
>>
>> On Sat, Nov 21, 2015 at 9:27 AM, Luca Fascione <l.fasci...@gmail.com
>> <mailto:l.fasci...@gmail.com>> wrote:
>>
>> Thanks Simon!
>> I'm also attaching the small GIF from the other website for reference,
>> and the result I presently get from 2.18.2.
>>
>> It seems this question has come up a long time ago but I couldn't
>> find a definitive resolution to it.
>>
>> As I was saying, I am happy to contribute time to the coding if it
>> helps, but I could certainly use a bit of guidance as to where to
>> start.
>>
>> Things are never this simple, but in LaTeX-speak it seems to me
>> all it's needed is to wrap the bass note in something more or less
>> like \raisebox{-1ex}{E} (and maybe mess a bit with the kerning of
>> the slash, hard to say without trying it out).
>>
>&g

Re: Fwd: Slash chords

[Luca Fascione]

Hi Simon,
so this actually works rather well, I ended up taking the rotation out, as
with the actual font you get a better sense of the nib direction with the
original orientation of the solidus, nonetheless I do really like your
suggestion of using a slightly larger size, I find it does help a fair bit
with overall balance and blackness. I also messed with kerning a little

I have attached a test of the latest results, I find it looks ok (and it's
certainly good enough for my present purpose), but it could be better.

I think there are two issues at present: on the "top" of the solidus the
chords with sevenths have the slash too far to their right, the F minor has
it a touch loose, and the F major has it a touch tight. On the bottom of
the solidus, I like how B and G sit, I think A sits loose and E sits far
too tight, the present settings being somewhat of a compromise.

I suspect this is because lilypond, like TeX, thinks in boxes, and that,
combined a possibly not too accurate kerning table for the font, is not
working too well.

So the reason for this message is just to enquire as to the offchance of
being able to adjust the kerning of the bass notes on a per-note basis and
some way to do the same for the top.

(Note that this font is odd, in the the 7th symbol is raised in its
natural, baseline-referred form: you can see this in the overrides, where
asking for C7 actually yields C^7)

Anyways, in the off chance this is fixable, I'd be keen to hear how to do
so, in any event many thanks for your help so far, this is of enormous help

Cheers,
Luca


On Sat, Nov 21, 2015 at 10:36 AM, Simon Albrecht 
wrote:

> Hello Luca,
>
> with the help of the french blog post jmechmech linked in his reply, I
> cooked up the following from your code:
>
> 
> \version "2.18.2"
>
> #(define (lower-extension pitch chbass)
>"Return lowered markup for pitch note name."
>#{
>  \markup \raise #-1.9 \halign #0.2
>  #(note-name->markup pitch chbass)
>#})
>
> chExceptionMusic = {
>   1-\markup { "7" }
>   %1-\markup { "<7/" \raise #-2.5 "B" } % for illustration
> purposes only
>   1-\markup { ">" }
> }
>
> chExceptions = #(append
>  (sequential-music-to-chord-exceptions chExceptionMusic #t)
>  ignatzekExceptions)
>
> \layout {
>   \context {
> \ChordNames
> \override ChordName.font-name = #"New Real Book Chords"
> chordNameExceptions = \chExceptions
> slashChordSeparator = \markup {
>   % the \hspace commands simulate kerning
>   \hspace #-.7
>   \fontsize #1 \lower #1.2 \rotate #-10 "/"
>   \hspace #-.1
> }
> chordNoteNamer = #lower-extension
>   }
> }
>
> \score {
>   \new StaffGroup <<
> \chords {
>   f2.:m c4:7/e c2:maj7
> }
> \new Staff { \key aes \major \time 3/4 c'4 aes'2 c'4 bes'2 }
>   >>
>   \layout { }
> }
> %%
>
> Does that do what you want? I couldn’t test it with the actual font, of
> course, only with LilyPond’s default Sans font. So you’ll likely have to
> adjust the numerical values in lines 6 and 27–29 to taste. See <
> http://lilypond.org/doc/v2.18/Documentation/notation/text-markup-commands>
> for documentation on the markup commands (you can also look them up in the
> index, section D of the Notation Reference).
> You can fitfully use the \layout {} block in a stylesheet (i.e., a
> separate .ily file to \include everywhere you want this kind of chord names
> display).
>
> HTH, Simon
>
>


slashchordtest.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user