Re: Rendering Two Dots Above a Character
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
> 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
> \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
>> 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
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
> 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
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
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
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
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
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
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
