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