Re: Rendering Two Dots Above a Character

2022-01-25 Thread Omid Mo'menzadeh
So I just came up with another hack, which at least works properly, but I
don't think the code should be this ugly:

%%% hack begins
{
  "c" "_" "d" "_" "e" "f" "_" "g" "_" "a" "_" "b"
  {\combine "c" {\raise #1 {\general-align #X #-2 "."}}}
  "_"
  {\combine "d" {\raise #1.5 {\general-align #X #-2 "."}}}
  "_"
  {\combine "e" {\raise #1 {\general-align #X #-2 "."}}}
  {\combine "f" {\raise #1.5 {\general-align #X #-2 "."}}}
  "_"
  {\combine "g" {\raise #1 {\general-align #X #-2 "."}}}
  "_"
  {\combine "a" {\raise #1 {\general-align #X #-2 "."}}}
  "_"
  {\combine "b" {\raise #1.5 {\general-align #X #-2 "."}}}
  {\combine "c" {\raise #1 {\general-align #X #-2 ":"}}}
  "_"
  {\combine "d" {\raise #1.5 {\general-align #X #-2 ":"}}}
  "_"
  {\combine "e" {\raise #1 {\general-align #X #-2 ":"}}}
  "ė̇"
%%% hack ends

On Mon, Jan 24, 2022 at 11:26 PM Omid Mo'menzadeh 
wrote:

> Hello all.
> I am trying to create some sort of tablature for Kalimba, treating it like
> a one-string instrument with fret-labels. I want to use letters like c, ċ,
> ċ̇ (or c𐽉), etc. I figured there are Unicode characters to do exactly
> that, "combining dot above" and "combining two dots above", etc. However,
> LilyPond does not seem to be able to render "combining two dots above", and
> two "combining dot above" characters (rendered correctly by my browser, as
> well as Emacs) result in the two dots to be rendered almost on top of each
> other in LilyPond. I have attached a rather minimal example.
>
> I would appreciate any other solutions to this problem, or a way to fix
> the rendering issue.
>
> Thanks everyone.
>


Re: Rendering Two Dots Above a Character

2022-01-25 Thread Werner LEMBERG

> I am trying to create some sort of tablature for Kalimba, treating
> it like a one-string instrument with fret-labels. I want to use
> letters like c, ċ, ċ̇ (or c𐽉), etc.  I figured there are Unicode
> characters to do exactly that, "combining dot above" and "combining
> two dots above", etc.  However, LilyPond does not seem to be able to
> render "combining two dots above", and two "combining dot above"
> characters (rendered correctly by my browser, as well as Emacs)
> result in the two dots to be rendered almost on top of each other in
> LilyPond.  I have attached a rather minimal example.

This is a pure font issue, not related to LilyPond at all or the used
rendering library (Pango).  Your example works just fine with the
fonts 'Gentium Plus' or 'Charis SIL', for example.  I've slightly
modified your snippet to show a possible solution.


Werner
%%% minimal example start
\version "2.22.1"

notes = \relative c' {
  \time 3/4
  c c' c' |
}

\score {
  <<
\new StaffGroup = "tab with traditional" <<
  \new Staff = "standard" \with {
midiInstrument = "kalimba"
instrumentName = "Kalimba"
  } <<
\clef "treble"
\context Voice = "music" \notes
  >>
  \new TabStaff = "tab" \with {
stringTunings = \stringTuning 
tablatureFormat = #fret-letter-tablature-format
fretLabels = \markuplist {
  \override #'(font-name . "Charis SIL") {
  "c" "_" "d" "_" "e"
  "f" "_" "g" "_" "a" "_" "b"
  "ċ" "_" "ḋ" "_" "ė"
  "ḟ" "_" "ġ" "_" "ȧ" "_" "ḃ"
  "ċ̇" "_" "ḋ̇" "_" "ė̇" } }
  } <<
\tabFullNotation
\context TabVoice = "tab" \notes
  >>
>>
  >>
}
%%% minimal example end


Re: Stem length of beamed notes

2022-01-25 Thread Werner LEMBERG


> \once \override Beam.positions = #'(1 . 0.5) g8 fis
> 
> Indeed, AFAICS this is not clearly documented in the NR manual.

Can you provide a patch?


Werner



Re: Rendering Two Dots Above a Character

2022-01-25 Thread Werner LEMBERG

>> I am trying to create some sort of tablature for Kalimba, treating
>> it like a one-string instrument with fret-labels. I want to use
>> letters like c, ċ, ċ̇ (or c𐽉), etc.  I figured there are Unicode
>> characters to do exactly that, "combining dot above" and "combining
>> two dots above", etc.  However, LilyPond does not seem to be able to
>> render "combining two dots above", and two "combining dot above"
>> characters (rendered correctly by my browser, as well as Emacs)
>> result in the two dots to be rendered almost on top of each other in
>> LilyPond.  I have attached a rather minimal example.
> 
> This is a pure font issue, not related to LilyPond at all or the used
> rendering library (Pango).  Your example works just fine with the
> fonts 'Gentium Plus' or 'Charis SIL', for example.  I've slightly
> modified your snippet to show a possible solution.

Attached is an image that shows your example Charis SIL.


Werner


Re: Rendering Two Dots Above a Character

2022-01-25 Thread Valentin Petzel
Hello Omid,

Maybe something like this could work.

Cheers,
Valentin

Am Montag, 24. Jänner 2022, 20:56:11 CET schrieb Omid Mo'menzadeh:
> Hello all.
> I am trying to create some sort of tablature for Kalimba, treating it like
> a one-string instrument with fret-labels. I want to use letters like c, ċ,
> ċ̇ (or c𐽉), etc. I figured there are Unicode characters to do exactly
> that, "combining dot above" and "combining two dots above", etc. However,
> LilyPond does not seem to be able to render "combining two dots above", and
> two "combining dot above" characters (rendered correctly by my browser, as
> well as Emacs) result in the two dots to be rendered almost on top of each
> other in LilyPond. I have attached a rather minimal example.
> 
> I would appreciate any other solutions to this problem, or a way to fix the
> rendering issue.
> 
> Thanks everyone.%%% minimal example start
\version "2.22.1"

notes = \relative c' {
  \time 3/4
  c c' c' |
}

#(define (normalize-pitch pitch)
   (let* ((octave-r (ly:pitch-octave pitch))
  (nn-r (ly:pitch-notename pitch))
  (octave (+ octave-r (quotient nn-r 7)))
  (nn (modulo nn-r 7))
  (alt (ly:pitch-alteration pitch)))
 (if (< alt -1/2)
 (normalize-pitch (ly:pitch-transpose pitch (ly:make-pitch 0 -1 1/2)))
 (if (> alt 1/2)
 (normalize-pitch (ly:pitch-transpose pitch (ly:make-pitch 0 1 -1)))
 (if (= alt 1/2)
 (if (or (= nn 2) (= nn 6))
 (normalize-pitch (ly:pitch-transpose pitch (ly:make-pitch 0 1 -1)))
 (ly:make-pitch octave nn alt))
 (if (= alt -1/2)
 (if (or (= nn 3) (= nn 0))
 (normalize-pitch (ly:pitch-transpose pitch (ly:make-pitch 0 -1 1/2)))
 (ly:make-pitch octave nn alt))
 (ly:make-pitch octave nn alt)))

#(define (transpose-by-semitone pitch st)
   (normalize-pitch (ly:pitch-transpose pitch (ly:make-pitch 0 0 (/ st 2)

#(define (fret-letter-tablature-format-kalimba context string-number fret-number)
   (let* ((string-tuning (list-ref (ly:context-property context 'stringTunings) (1- string-number)))
  (pitch (transpose-by-semitone string-tuning fret-number))
  (root (make-translate-scaled-markup '(0 . -0.5) (note-name->markup pitch #t)))
  (dotc (quotient fret-number 12))
  (dotm (markup #:with-dimensions '(0 . 0) '(0 . 0) #:center-align #:pattern dotc X 0.2 #:musicglyph "scripts.staccato"))
  (comb-mu (markup #:override '(direction . 1) #:override '(baseline-skip . 0.8) #:dir-column (#:center-align root dotm
 comb-mu))

\score {
  <<
\new StaffGroup = "tab with traditional" <<
  \new Staff = "standard" \with {
midiInstrument = "kalimba"
instrumentName = "Kalimba"
  } <<
\clef "treble"
\context Voice = "music" \notes
  >>
  \new TabStaff = "tab" \with {
stringTunings = \stringTuning 
tablatureFormat = #fret-letter-tablature-format-kalimba
  } <<
\tabFullNotation
\context TabVoice = "tab" \notes
  >>
>>
  >>
}
%%% minimal example end


signature.asc
Description: This is a digitally signed message part.


Re: Rendering Two Dots Above a Character,Re: Rendering Two Dots Above a Character

2022-01-25 Thread Werner LEMBERG

> Maybe something like this could work.

Nice!  Note, however, that Omid uses

   +  + 

in his input file.  This clearly indicates that he wants the dots
stacked vertically, not horizontally.  Your solution is perfect in
case the vertical stacking is not intended – Unicode provides no means
to 'stack' horizontally.


Werner


Re: Changed bracket behaviour

2022-01-25 Thread Jogchum Reitsma

Op 24-01-2022 om 21:10 schreef Valentin Petzel:

Hello Jogchum,

You have a GrandStaff on the top level (I guess for spanned barlines?). This
will add a brace by default. This brace cannot get arbitrarily large, so it
only spans part of the System.

Two solutions:
Just get rid of the GrandStaff (if you do not in fact want spanned barlines,
which is usually the case with choral music as they make lyrics placement
harder), or change the start delimiter to a barline by doing
\new StaffGroup \with
{
   systemStartDelimiter = #'SystemStartBar
}
Instead.
¨
Cheers,
Valentin


Hi Valentin,

Thanks for answering!

The first solution I had already tried (in version 2.19.82), looking for 
a way to subdivide the sixteen voices in S-A-T-B segments. It gave, and 
still gives the error


document.ly:256:3: fout: Schijnbare expressie in \score ("Schijnbare 
expressie" being Dutch for "apparent epression")


Only the first system is rendered.

The second solution leads to the same result/error message.

While I admit that the Grandstaff-option leads to undesirable spanned 
barlines, in version 2.19.82 it performed the wanted grouping, without 
the extra brace seen in 2.23...


cheers, Jogchum


Re: Changed bracket behaviour

2022-01-25 Thread Jean Abou Samra



Le 25/01/2022 à 13:07, Jogchum Reitsma a écrit :

Op 24-01-2022 om 21:10 schreef Valentin Petzel:

Hello Jogchum,

You have a GrandStaff on the top level (I guess for spanned barlines?). This
will add a brace by default. This brace cannot get arbitrarily large, so it
only spans part of the System.

Two solutions:
Just get rid of the GrandStaff (if you do not in fact want spanned barlines,
which is usually the case with choral music as they make lyrics placement
harder), or change the start delimiter to a barline by doing
\new StaffGroup \with
{
   systemStartDelimiter = #'SystemStartBar
}
Instead.
¨
Cheers,
Valentin


Hi Valentin,

Thanks for answering!

The first solution I had already tried (in version 2.19.82), looking 
for a way to subdivide the sixteen voices in S-A-T-B segments. It 
gave, and still gives the error


document.ly:256:3: fout: Schijnbare expressie in \score ("Schijnbare 
expressie" being Dutch for "apparent epression")





I guess you are trying to do (simplified example):

\score {
  \new ChoirStaff <<
    \new Staff { c'1 }
    \new Staff { c'1 }
  >>
  \new ChoirStaff <<
    \new Staff { c'1 }
    \new Staff { c'1 }
  >>
}


That's not what LilyPond expects. In a \score block,
there must be one music expression, hence the warning
"spurious expression in \score". Please see
https://lilypond.org/doc/v2.22/Documentation/learning/score-is-a-_0028single_0029-compound-musical-expression
The problem is that there are several of them here,
and you are not telling LilyPond how to group them.
They have to be in parallel, not one after the other,
so they should be surrounded by << >>.

\score {
  <<
    \new ChoirStaff <<
  \new Staff { c'1 }
  \new Staff { c'1 }
    >>
    \new ChoirStaff <<
  \new Staff { c'1 }
  \new Staff { c'1 }
    >>
  >>
}

This gives the default grouping, documented at
https://lilypond.org/doc/v2.22/Documentation/notation/displaying-staves.html#grouping-staves
Namely, a mere bar to group the staves, and
no connected bar lines. That is exactly what
you want here.

To elaborate: \new GrandStaff does not necessarily
call for << >> even if that is typically what you
want to feed it. The syntax is \new GrandStaff xxx
where xxx is any music expression. You could just as
well say

\new GrandStaff {
  <<
    { c'1 }
    { c'1 }
  >>
  <<
    { d'1 }
    { d'1 }
  >>
}

even if that does not make a lot of sense
musically.




Only the first system is rendered.

The second solution leads to the same result/error message.

While I admit that the Grandstaff-option leads to undesirable spanned 
barlines, in version 2.19.82 it performed the wanted grouping, without 
the extra brace seen in 2.23...





This change was intended. What's happening in 2.22 and
earlier is that GrandStaff does not accept ChoirStaff, so
the GrandStaff actually does not receive any music at all
and ChoirStaff contexts are inserted inside Score. This
has the consequence that the expected brace is not
inserted. There are a number of similar cases. They
were sorted out in the development series by this
change in the LilyPond sources:

commit e31b0b75a9a7b6e01ecd9c9a05dc3108a89273be
Author: Jean Abou Samra 
Date:   Sat Apr 17 11:48:58 2021 +0200

    Derive all StaffGroup-like contexts from StaffGroup

    Previously, there were many inconsistencies between the context types
    StaffGroup, ChoirStaff, GrandStaff and PianoStaff.  They had 
differences
    in their lists of accepted contexts, and setting localAlterations 
or not.
    This lets ChoirStaff and GrandStaff inherit from StaffGroup 
(PianoStaff

    still inherits from GrandStaff) to keep all of them in sync.

    StaffGroup gains a bunch of \accepts, so it accepts everything also
    accepted by Score.

    This fixes a problem occurring when a TabStaff was included in a 
ChoirStaff.
    The latter did not accept it, causing a StaffGroup to be inserted 
in between,

    with its own bracket.

    Closes: #6094


In summary: your score was relying on buggy behavior.
Fortunately, it's easy to fix it by using the method
that is documented to give the behavior you want.


Hope that helps,
Jean




Re: Changed bracket behaviour

2022-01-25 Thread Jogchum Reitsma

Hi Jean,

Thanks a lot, this gives what is wanted.

Thanks also for the elaborate explanation you give, is much appreciated!

with kind regards,

Jogchum Reitsma

Op 25-01-2022 om 13:42 schreef Jean Abou Samra:



I guess you are trying to do (simplified example):

\score {
  \new ChoirStaff <<
    \new Staff { c'1 }
    \new Staff { c'1 }
  >>
  \new ChoirStaff <<
    \new Staff { c'1 }
    \new Staff { c'1 }
  >>
}


That's not what LilyPond expects. In a \score block,
there must be one music expression, hence the warning
"spurious expression in \score". Please see
https://lilypond.org/doc/v2.22/Documentation/learning/score-is-a-_0028single_0029-compound-musical-expression 


The problem is that there are several of them here,
and you are not telling LilyPond how to group them.
They have to be in parallel, not one after the other,
so they should be surrounded by << >>.

\score {
  <<
    \new ChoirStaff <<
  \new Staff { c'1 }
  \new Staff { c'1 }
    >>
    \new ChoirStaff <<
  \new Staff { c'1 }
  \new Staff { c'1 }
    >>
  >>
}




This gives the default grouping, documented at
https://lilypond.org/doc/v2.22/Documentation/notation/displaying-staves.html#grouping-staves 


Namely, a mere bar to group the staves, and
no connected bar lines. That is exactly what
you want here.

To elaborate: \new GrandStaff does not necessarily
call for << >> even if that is typically what you
want to feed it. The syntax is \new GrandStaff xxx
where xxx is any music expression. You could just as
well say

\new GrandStaff {
  <<
    { c'1 }
    { c'1 }
  >>
  <<
    { d'1 }
    { d'1 }
  >>
}

even if that does not make a lot of sense
musically.




Only the first system is rendered.

The second solution leads to the same result/error message.

While I admit that the Grandstaff-option leads to undesirable spanned 
barlines, in version 2.19.82 it performed the wanted grouping, 
without the extra brace seen in 2.23...





This change was intended. What's happening in 2.22 and
earlier is that GrandStaff does not accept ChoirStaff, so
the GrandStaff actually does not receive any music at all
and ChoirStaff contexts are inserted inside Score. This
has the consequence that the expected brace is not
inserted. There are a number of similar cases. They
were sorted out in the development series by this
change in the LilyPond sources:

commit e31b0b75a9a7b6e01ecd9c9a05dc3108a89273be
Author: Jean Abou Samra 
Date:   Sat Apr 17 11:48:58 2021 +0200

    Derive all StaffGroup-like contexts from StaffGroup

    Previously, there were many inconsistencies between the context types
    StaffGroup, ChoirStaff, GrandStaff and PianoStaff.  They had 
differences
    in their lists of accepted contexts, and setting localAlterations 
or not.
    This lets ChoirStaff and GrandStaff inherit from StaffGroup 
(PianoStaff

    still inherits from GrandStaff) to keep all of them in sync.

    StaffGroup gains a bunch of \accepts, so it accepts everything also
    accepted by Score.

    This fixes a problem occurring when a TabStaff was included in a 
ChoirStaff.
    The latter did not accept it, causing a StaffGroup to be inserted 
in between,

    with its own bracket.

    Closes: #6094


In summary: your score was relying on buggy behavior.
Fortunately, it's easy to fix it by using the method
that is documented to give the behavior you want.


Hope that helps,
Jean






Re: Rendering Two Dots Above a Character

2022-01-25 Thread Omid Mo'menzadeh
Now I feel dumb for not thinking of changing the font! This looks pretty
nice to me.
Thank you.

On Tue, Jan 25, 2022 at 1:27 PM Werner LEMBERG  wrote:

>
> >> I am trying to create some sort of tablature for Kalimba, treating
> >> it like a one-string instrument with fret-labels. I want to use
> >> letters like c, ċ, ċ̇ (or c𐽉), etc.  I figured there are Unicode
> >> characters to do exactly that, "combining dot above" and "combining
> >> two dots above", etc.  However, LilyPond does not seem to be able to
> >> render "combining two dots above", and two "combining dot above"
> >> characters (rendered correctly by my browser, as well as Emacs)
> >> result in the two dots to be rendered almost on top of each other in
> >> LilyPond.  I have attached a rather minimal example.
> >
> > This is a pure font issue, not related to LilyPond at all or the used
> > rendering library (Pango).  Your example works just fine with the
> > fonts 'Gentium Plus' or 'Charis SIL', for example.  I've slightly
> > modified your snippet to show a possible solution.
>
> Attached is an image that shows your example Charis SIL.
>
>
> Werner
>


Re: Rendering Two Dots Above a Character

2022-01-25 Thread Omid Mo'menzadeh
Wow! Although I'd want to have the two dots vertically aligned, this great
help! I really wanted to know how to use expression marks on text, and the
Ttablature format code is nice to have as an example for similar situations.
Thank you so much.

On Tue, Jan 25, 2022 at 1:31 PM Valentin Petzel  wrote:

> Hello Omid,
>
> Maybe something like this could work.
>
> Cheers,
> Valentin
>
> Am Montag, 24. Jänner 2022, 20:56:11 CET schrieb Omid Mo'menzadeh:
> > Hello all.
> > I am trying to create some sort of tablature for Kalimba, treating it
> like
> > a one-string instrument with fret-labels. I want to use letters like c,
> ċ,
> > ċ̇ (or c𐽉), etc. I figured there are Unicode characters to do exactly
> > that, "combining dot above" and "combining two dots above", etc. However,
> > LilyPond does not seem to be able to render "combining two dots above",
> and
> > two "combining dot above" characters (rendered correctly by my browser,
> as
> > well as Emacs) result in the two dots to be rendered almost on top of
> each
> > other in LilyPond. I have attached a rather minimal example.
> >
> > I would appreciate any other solutions to this problem, or a way to fix
> the
> > rendering issue.
> >
> > Thanks everyone.


Re: adjusting double glissandi

2022-01-25 Thread Aaron Hill

On 2022-01-25 11:46 am, Rachel Green wrote:

Hi,
I’m trying to adjust the glissandi in this excerpt so that the lines
are parallel and not too close to each other. I found some settings
for adjusting a single glissando, but not for a double glissando. Any
ideas?


There is prior work on this subject.  Harm has provided some code [1] 
before.


[1]: 
https://lists.gnu.org/archive/html/lilypond-user/2013-08/msg00547.html


Here is an adaptation of that logic:


glissandoTweak =
#(define-music-function
  (after? tweaks) ((boolean? #t) list?)
  (define (proc grob)
   (if after? (ly:spanner::kill-zero-spanned-time grob))
   (for-each
(lambda (x)
 (let ((prop (car x)) (value (cdr x)))
  (if (key-list? prop)
   (ly:grob-set-nested-property! grob prop value)
   (ly:grob-set-property! grob prop value
(ly:assoc-get
 (ly:grob-property grob 'glissando-index) tweaks '(
  (if after?
   #{ \once \override Glissando.after-line-breaking = #proc #}
   #{ \once \override Glissando.before-line-breaking = #proc #}))

{
 \glissandoTweak
 #`((0 . ((color . ,red)
  (Y-offset . -0.5)))
(1 . ((color . ,blue)
  ((bound-details right arrow) . #t
 2\glissando 
}



-- Aaron Hill