Re: Off-topic: does anybody know about these accidentals?

[Jean Abou Samra]

Le mardi 23 juillet 2024 à 01:05 +0200, Jean Abou Samra a écrit :
> The SMuFL standard has a *very* extensive set of accidentals, see
> https://w3c.github.io/smufl/latest/tables/standard-accidentals-12-edo.html
> and the following sections; yet I couldn't find them there either.


My bad, they are in the "Other accidentals" section
https://w3c.github.io/smufl/latest/tables/other-accidentals.html
with the names "accidentalQuarterTone{Sharp,Flat}4". Not
sure how I missed them.

I didn't find any info in the GitHub issues or commit history about why
these were included; I suspect it's "because they were in Unicode"…

And for the record, Werner forwarded the question to the Unicode
mailing list, thanks!
https://corp.unicode.org/pipermail/unicode/2024-July/010976.html



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

Off-topic: does anybody know about these accidentals?

[Jean Abou Samra]

Hi folks,

A friend of mine asked the following question, which I find pretty mysterious.

In the Unicode musical symbols block, the available microtonal accidentals are 
these:

- 𝄬 U+1D12C MUSICAL SYMBOL FLAT UP and 𝄭 U+1D12D MUSICAL SYMBOL FLAT DOWN
- 𝄮 U+1D12E MUSICAL SYMBOL NATURAL UP and 𝄯 U+1D12F MUSICAL SYMBOL NATURAL DOWN
- 𝄰 U+1D130 MUSICAL SYMBOL SHARP UP and 𝄱 U+1D131 MUSICAL SHARP DOWN
- 𝄲 U+1D132 MUSICAL SYMBOL QUARTER TONE SHARP and 𝄳 U+1D133 MUSICAL SYMBOL
  QUARTER TONE FLAT

In case you have fonts where these are as ridiculously small as on my
system, attached is a chart made with

\markuplist \override #'((padding . 2) (baseline-skip . 5))
\table #`(,CENTER ,RIGHT ,CENTER ,RIGHT) {
  \fontsize #10 𝄬 "flat up" \fontsize #10 𝄭 "flat down"
  \fontsize #10 𝄮 "natural up" \fontsize #10 𝄯 "natural down"
  \fontsize #10 𝄰 "sharp up" \fontsize #10 𝄱 "sharp down"
  \fontsize #15 𝄲 "quarter tone sharp" \fontsize #15 𝄳 "quarter tone flat"
}

The glyphs with arrows are AFAIK standard, and available in LilyPond
as accidentals.{flat,natural,sharp}.arrow{down,up}. But what about
the "quarter tone {sharp,flat}", which look like a sharp/flat with
an added digit 4?

I've never seen these. LilyPond's Emmentaler font doesn't have them
https://lilypond.org/doc/v2.25/Documentation/notation/accidental-glyphs .

The SMuFL standard has a *very* extensive set of accidentals, see
https://w3c.github.io/smufl/latest/tables/standard-accidentals-12-edo.html
and the following sections; yet I couldn't find them there either.

There is a Unicode proposal not yet accepted
https://unicode.org/L2/L2023/23276-quarter-tone-accidentals.pdf
to encode the more standard accidentals which are the default
in LilyPond (try { ceh' cih' } ): a sharp with only one
vertical branch, and a mirrored flat. The proposal quotes
https://tug.org/TUGboat/tb38-2/tb119hufflen-music.pdf :

"The glyphs defined by Unicode at present are 𝄲(U+1D132) and
𝄳(U+1D133): we have *never* seen them in *any* score."

The original proposal to encode these in Unicode was
https://unicode.org/L2/L1998/98045.pdf
and gives zero details.

Does anybody have a clue where the heck these glyphs come from?
Which composers might have used them?

Cheers,
Jean



accidentals.pdf
Description: Adobe PDF document


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

Bug in NoteName - Accidentals?

[Sebastian Käppler]

Hello again,

following the Changes to Notename - topic, I have another question. Using
printAccidentalNames seems to override the printNotesLanguage property by
reverting it to the document language. Try the following example and
comment out one of the two lines. Expected result would be to get c' h' b'
a' as note names. I only get this if using \language="deutsch" before.


melody = { c' b' bes' a' }

\score {
  <<
\new Staff { \melody }
\new NoteNames {
  *\set printNotesLanguage = "deutsch"*
  \set printOctaveNames = ##t
*  \set printAccidentalNames = #'lily*
  \melody
}
  >>
  \layout {}
}

Best regards!

Re: function to force accidentals on a subset of notes

[Michael Winter via LilyPond user discussion]

This is what happens for me too. I think it has something to do with all the 
other functions I am using. 

Oct 30, 2023, 21:25 by l...@gmx.de:

>
> Hi Michael,
>
> Am 30.10.23 um 10:42 schrieb Michael  Winter:
>
>> But  I am confused about what you said. For me, it is posting the  
>> accidental on tied notes after line breaks.
>>
>
> No I'm confused. :-) If I do
>
>
>
> \transpose a c' \relative
>  {
>    a8 gis~ gis g fis g gis a
>    gis1~ \break gis2 gis
>  }
>
>
>
> in my example file, I get:
>
>
>
>
>
> (To wit, no natural sign on the first b in measure 3).
>
>
> Is this different for you?
>
>
> Lukas
>
>

Re: function to force accidentals on a subset of notes

[Lukas-Fabian Moser]

Hi Michael,

Am 30.10.23 um 10:42 schrieb Michael Winter:
But I am confused about what you said. For me, it is posting the 
accidental on tied notes after line breaks.


No I'm confused. :-) If I do

\transpose a c' \relative
{
  a8 gis~ gis g fis g gis a
  gis1~ \break gis2 gis
}

in my example file, I get:

(To wit, no natural sign on the first b in measure 3).

Is this different for you?

Lukas

Re: function to force accidentals on a subset of notes

[Michael Winter via LilyPond user discussion]

Thanks!

This seems to work quite well : )

But I am confused about what you said. For me, it is posting the accidental on 
tied notes after line breaks.

Best,

Michael

Oct 28, 2023, 22:40 by l...@gmx.de:

> Hi Michael,
>
>> Thanks Lukas!
>>
>> This works but also forces the accidental on tied notes.
>>
>
> Sorry for not getting back to you sooner.
>
> The following version registers ties and removes our auto-generated 
> accidentals for notes in which a tie ends. (It's a bit overeager and also 
> removes tied accidentals after line breaks, so we get a behaviour as if 
> Accidental.hide-tied-accidental-after-break is set to ##t. Please give word 
> if you want me to change that.)
>
> Lukas
>
> \version "2.24.0"
>
> forced-accidentals-pitches =
> #(music-pitches #{ bes b #})
>
> #(define (diatonic-pitch-class= p q)
>    (and (= (ly:pitch-notename p) (ly:pitch-notename q))
>     (= (ly:pitch-alteration p) (ly:pitch-alteration q
>
> Force_accidentals_engraver =
> #(lambda (context)
>    (let
>     ((ties '())
>  (affected-note-events '()))
>    (make-engraver
>     (end-acknowledgers
>  ((tie-interface engraver grob source-engraver)
>   (set! ties (cons grob ties
>     ((stop-translation-timestep engraver)
>  (for-each
>   (lambda (tie)
>     (let* ((right-notehead (ly:spanner-bound tie RIGHT))
>    (right-notehead-cause (ly:grob-property right-notehead 
> 'cause)))
>   (if (member right-notehead-cause affected-note-events)
>   (ly:grob-suicide!
>    ;;; the accidental grob should be guaranteed to
>    ;;; exist since we forced it into existence...
>    (ly:grob-object
>     right-notehead 'accidental-grob)
>   ties)
>  (set! ties '())
>  (set! affected-note-events '()))
>     (listeners
>  ((note-event engraver event)
>   (when (member (ly:event-property event 'pitch)
>     forced-accidentals-pitches
>     diatonic-pitch-class=)
>     (ly:event-set-property! event 'force-accidental #t)
>     (set! affected-note-events
>   (cons event affected-note-events
>
> \layout {
>   \context {
>     \Voice
>     \consists #Force_accidentals_engraver
>   }
> }
>
> \transpose a c' \relative
> {
>   a8 gis~ gis g fis g gis a
>   gis1~ gis2 gis
> }
>

Re: function to force accidentals on a subset of notes

[Lukas-Fabian Moser]

Hi Michael,


Thanks Lukas!

This works but also forces the accidental on tied notes.


Sorry for not getting back to you sooner.

The following version registers ties and removes our auto-generated 
accidentals for notes in which a tie ends. (It's a bit overeager and 
also removes tied accidentals after line breaks, so we get a behaviour 
as if Accidental.hide-tied-accidental-after-break is set to ##t. Please 
give word if you want me to change that.)


Lukas

\version "2.24.0"

forced-accidentals-pitches =
#(music-pitches #{ bes b #})

#(define (diatonic-pitch-class= p q)
   (and (= (ly:pitch-notename p) (ly:pitch-notename q))
    (= (ly:pitch-alteration p) (ly:pitch-alteration q

Force_accidentals_engraver =
#(lambda (context)
   (let
    ((ties '())
 (affected-note-events '()))
   (make-engraver
    (end-acknowledgers
 ((tie-interface engraver grob source-engraver)
  (set! ties (cons grob ties
    ((stop-translation-timestep engraver)
 (for-each
  (lambda (tie)
    (let* ((right-notehead (ly:spanner-bound tie RIGHT))
   (right-notehead-cause (ly:grob-property right-notehead 
'cause)))

  (if (member right-notehead-cause affected-note-events)
  (ly:grob-suicide!
   ;;; the accidental grob should be guaranteed to
   ;;; exist since we forced it into existence...
   (ly:grob-object
    right-notehead 'accidental-grob)
  ties)
 (set! ties '())
 (set! affected-note-events '()))
    (listeners
 ((note-event engraver event)
  (when (member (ly:event-property event 'pitch)
    forced-accidentals-pitches
    diatonic-pitch-class=)
    (ly:event-set-property! event 'force-accidental #t)
    (set! affected-note-events
  (cons event affected-note-events

\layout {
  \context {
    \Voice
    \consists #Force_accidentals_engraver
  }
}

\transpose a c' \relative
{
  a8 gis~ gis g fis g gis a
  gis1~ gis2 gis
}

Re: function to force accidentals on a subset of notes

[Michael Winter via LilyPond user discussion]

Thanks Lukas!

This works but also forces the accidental on tied notes.

Best,

Michael

Oct 22, 2023, 10:19 by l...@gmx.de:

>
> Hi Michael,
>
>
> this is easily accomplished with an custom engraver. (I perfectly  
> understand that the terms "easily" and "custom engraver" don't  seem to 
> go well together at first - I thought so for many years as  well -, but 
> after some getting used to it, the concept is actually  quite simple and 
> elegant.)
>
>
>
> \version "2.24.0"
>  
>  forced-accidentals-pitches =
>  #(music-pitches #{ bes b #})
>  
>  #(define (diatonic-pitch-class= p q)
>     (and (= (ly:pitch-notename p) (ly:pitch-notename q))
>      (= (ly:pitch-alteration p) (ly:pitch-alteration q
>  
>  Force_accidentals_engraver =
>  #(lambda (context)
>     (make-engraver
>      (listeners
>       ((note-event engraver event)
>    (if (member (ly:event-property event 'pitch)
>    forced-accidentals-pitches
>    diatonic-pitch-class=)
>    (ly:event-set-property! event 'force-accidental #t))
>  
>  \layout {
>    \context {
>      \Voice
>      \consists #Force_accidentals_engraver
>    }
>  }
>  
>  \transpose a c' \relative
>  {
>    a8 gis g fis g gis a4
>  }
>
>
>
> Lukas
>
> Am 21.10.23 um 11:37 schrieb Michael  Winter via LilyPond user discussion:
>
>> Thanks Jean,
>>
>> I am not sure I completely follow.
>>
>> Lets say I have a music sequence:
>>
>> a b c d e f g a bes c d e f g ...
>>
>> How do I apply what you have written as a functionto only show the 
>> flats and naturals for b and bes. Again. I donot want to apply this 
>> to individual notes.
>>
>> Sorry if I am missing something.
>>
>> Best,
>>
>> Michael
>>
>>
>> Oct 21, 2023, 01:37 by >> j...@abou-samra.fr>> :
>>
>>>
>>> Try
>>>
>>> \displayMusic c'!
>>>
>>> This shows you that the >>> !>>>  syntax corresponds to  setting
>>>   the >>> force-accidental>>>  property to true. Thus, if  you 
>>> have  identified the note events you want to force accidentals  
>>> on, you can do
>>>
>>> (ly:music-set-property! the-note-event 'force-accidental #t)
>>>
>>> on each of them.
>>>
>>>
>>> Best,
>>>
>>>
>>> Jean
>>>
>>>
>>
>>

Re: function to force accidentals on a subset of notes

[Lukas-Fabian Moser]

Hi Michael,

this is easily accomplished with an custom engraver. (I perfectly 
understand that the terms "easily" and "custom engraver" don't seem to 
go well together at first - I thought so for many years as well -, but 
after some getting used to it, the concept is actually quite simple and 
elegant.)


\version "2.24.0"

forced-accidentals-pitches =
#(music-pitches #{ bes b #})

#(define (diatonic-pitch-class= p q)
   (and (= (ly:pitch-notename p) (ly:pitch-notename q))
    (= (ly:pitch-alteration p) (ly:pitch-alteration q

Force_accidentals_engraver =
#(lambda (context)
   (make-engraver
    (listeners
 ((note-event engraver event)
  (if (member (ly:event-property event 'pitch)
  forced-accidentals-pitches
  diatonic-pitch-class=)
  (ly:event-set-property! event 'force-accidental #t))

\layout {
  \context {
    \Voice
    \consists #Force_accidentals_engraver
  }
}

\transpose a c' \relative
{
  a8 gis g fis g gis a4
}

Lukas

Am 21.10.23 um 11:37 schrieb Michael Winter via LilyPond user discussion:

Thanks Jean,

I am not sure I completely follow.

Lets say I have a music sequence:

a b c d e f g a bes c d e f g ...

How do I apply what you have written as a function to only show the 
flats and naturals for b and bes. Again. I do not want to apply this 
to individual notes.


Sorry if I am missing something.

Best,

Michael


Oct 21, 2023, 01:37 by j...@abou-samra.fr:

Try

|\displayMusic c'! |

This shows you that the |!| syntax corresponds to setting the
|force-accidental| property to true. Thus, if you have identified
the note events you want to force accidentals on, you can do

|(ly:music-set-property! the-note-event 'force-accidental #t) |

on each of them.

Best,

Jean

Re: function to force accidentals on a subset of notes

[Michael Winter via LilyPond user discussion]

Thanks Jean,

I am not sure I completely follow.

Lets say I have a music sequence:

a b c d e f g a bes c d e f g ...

How do I apply what you have written as a function to only show the flats and 
naturals for b and bes. Again. I do not want to apply this to individual notes.

Sorry if I am missing something.

Best,

Michael

Oct 21, 2023, 01:37 by j...@abou-samra.fr:

>
> Try
>
> \displayMusic c'!
>
> This shows you that the > !>  syntax corresponds to settingthe > 
> force-accidental>  property to true. Thus, if you haveidentified the note 
> events you want to force accidentalson, you can do
>
> (ly:music-set-property! the-note-event 'force-accidental #t)
>
> on each of them.
>
>
> Best,
>
>
> Jean
>
>

Re: function to force accidentals on a subset of notes

[Jean Abou Samra]

Try

```
\displayMusic c'!
```

This shows you that the `!` syntax corresponds to setting
the `force-accidental` property to true. Thus, if you have
identified the note events you want to force accidentals
on, you can do

```
(ly:music-set-property! the-note-event 'force-accidental #t)
```

on each of them.

Best,

Jean



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

function to force accidentals on a subset of notes

[Michael Winter via LilyPond user discussion]

I have a piece that is in the following scale:

c d e fis g aes bes b

Is it possible to force the accidentals just for the bes and the b?

But here is the catch...
I am both transposing the part and respelling pitch-classes as show below. The 
scale above is actually the resulting printed set of notes. The music is 
already generated and I would not want to have to do this manually for each 
occurance.

Thanks in advance,

Michael


transposePitchClasses =
#(define-music-function (scaleA scaleB music) (ly:music? ly:music? ly:music?)
  (let* ((scaleA (ly:music-property scaleA 'elements))
 (scaleB (ly:music-property scaleB 'elements))
 (scaleA (map (lambda (x) (ly:music-property x 'pitch)) scaleA))
 (scaleB (map (lambda (x) (ly:music-property x 'pitch)) scaleB))
 (classesA (map (lambda (p) (cons (ly:pitch-notename p) 
(ly:pitch-alteration p))) scaleA)))
  (map-some-music
    (lambda (m)
  (let ((p (ly:music-property m 'pitch)))
    (if (not (null? p))
    (let* ((nn (ly:pitch-notename p))
   (oct (ly:pitch-octave p))
   (alt (ly:pitch-alteration p))
   (pos (list-index (lambda (x) (and (= (car x) nn) (= (cdr x) 
alt))) classesA)))
    (if pos
  (let* ((p2 (list-ref scaleA pos))
 (oct2 (ly:pitch-octave p2))
 (p3 (list-ref scaleB pos))
 (new-pitch (ly:pitch-transpose p3 (ly:make-pitch (- oct 
oct2) 0
  (ly:music-set-property! m 'pitch new-pitch)))
  m)
  #f)))
   music)
 music))
\new Staff \with {
  instrumentName = #"synth I (2)"
  shortInstrumentName = #"synI"
  \remove "Time_signature_engraver"
    }
    <<
  \transpose a c'
  \transposePitchClasses {a b cis dih e fih geh gis} {a b cis dis e f g gis}
  \include "includes/ammann_part_6.ly" %this is the music
    >>

Re: How to define a turn with two accidentals

[Volodymyr Prokopyuk]

Hi Michael,

Fantastic solution! Thank you very much!

LilyPond is similar to Emacs: given my superficial understanding of both
LilyPond and Elisp, quite often non-standard things are quite hard to nail
down without help from experts, but most of them are possible!

Thank you,
Vlad

On Fri, Oct 13, 2023 at 3:20 PM Michael Werner  wrote:

> Hi Vlad,
>
> On Fri, Oct 13, 2023 at 6:02 AM Volodymyr Prokopyuk <
> volodymyrprokop...@gmail.com> wrote:
>
>> I'd like to create a *music function* for convenience to be used like \after
>> 4. { \udTurn \sharp \natural } g=''2 a8 g f e |
>>
>> How do I create a music function for this purpose? I've tried the
>> following with the *error* of unknown command \sharp
>>
>>   udTurn = #(define-music-function (up down) (markup? markup?)
>> #{ \markup \center-column {
>>   \raise #-1 \teeny #up
>>   \musicglyph "scripts.turn"
>>   \lower #-1 \teeny #down
>> } #})
>>
>
> I got something that seems to work by switching from a music function to a
> markup function. This code:
>
>  \version "2.24.2"
>
> #(define-markup-command (udTurn layout props up down) (markup? markup?)
>(interpret-markup layout props
>#{ \markup { \center-column {
>  \raise #-1 \teeny #up
>  \musicglyph "scripts.turn"
>  \lower #-1 \teeny #down
> }
>} #} ))
>
> \new Score {
>   \new Staff {
> \new Voice {
>   \after 4. ^\markup{ \udTurn \sharp \natural }
>   g''2 a8 g f e
>   \after 4. ^\markup{ \udTurn \flat \sharp }
>   g''2 a8 g f e
> }
>   }
> }
>
> is producing:
>
> [image: image.png]
>
> Might not be the best way to go about this, but it seems to be working as
> described. Hopefully at least enough to get started with.
> --
> Michael
>
>

Re: How to define a turn with two accidentals

[Michael Werner]

Hi Vlad,

On Fri, Oct 13, 2023 at 6:02 AM Volodymyr Prokopyuk <
volodymyrprokop...@gmail.com> wrote:

> I'd like to create a *music function* for convenience to be used like \after
> 4. { \udTurn \sharp \natural } g=''2 a8 g f e |
>
> How do I create a music function for this purpose? I've tried the
> following with the *error* of unknown command \sharp
>
>   udTurn = #(define-music-function (up down) (markup? markup?)
> #{ \markup \center-column {
>   \raise #-1 \teeny #up
>   \musicglyph "scripts.turn"
>   \lower #-1 \teeny #down
> } #})
>

I got something that seems to work by switching from a music function to a
markup function. This code:

 \version "2.24.2"

#(define-markup-command (udTurn layout props up down) (markup? markup?)
   (interpret-markup layout props
   #{ \markup { \center-column {
 \raise #-1 \teeny #up
 \musicglyph "scripts.turn"
 \lower #-1 \teeny #down
}
   } #} ))

\new Score {
  \new Staff {
\new Voice {
  \after 4. ^\markup{ \udTurn \sharp \natural }
  g''2 a8 g f e
  \after 4. ^\markup{ \udTurn \flat \sharp }
  g''2 a8 g f e
}
  }
}

is producing:

[image: image.png]

Might not be the best way to go about this, but it seems to be working as
described. Hopefully at least enough to get started with.
-- 
Michael

Re: How to define a turn with two accidentals

[Volodymyr Prokopyuk]

Hi,

Thank you very much for your advice!

While the below *code*

  \after 4. ^\markup \center-column {
\raise #-1 \teeny \sharp
\musicglyph "scripts.turn"
\lower #-1 \teeny \natural
  }
  g=''2 a8 g f e |

gives the *desired result*

[image: image.png]


I'd like to create a *music function* for convenience to be used like \after
4. { \udTurn \sharp \natural } g=''2 a8 g f e |

How do I create a music function for this purpose? I've tried the following
with the *error* of unknown command \sharp

  udTurn = #(define-music-function (up down) (markup? markup?)
#{ \markup \center-column {
  \raise #-1 \teeny #up
  \musicglyph "scripts.turn"
  \lower #-1 \teeny #down
} #})

Thank you,
Vlad

On Fri, Oct 13, 2023 at 10:48 AM Hans Åberg  wrote:

>
> > On Oct 12, 2023, at 23:10, Volodymyr Prokopyuk <
> volodymyrprokop...@gmail.com> wrote:
> >
> > Is it possible to define a turn with two accidentals as shown below?
>
> I think you must design them, say adding another column item to what I use:
>
> mordentsharp = ^\markup \left-align \center-column {
>  \musicglyph #"scripts.mordent" \raise #1.0 \tiny\sharp
> }
>
> turnlowersharp = ^\markup { \lower #8.0 \left-align \center-column {
>   \musicglyph #"scripts.turn" \raise #1.0 \tiny\sharp
> }
> }
>
>
>

Re: How to define a turn with two accidentals

[Hans Åberg]

> On Oct 12, 2023, at 23:10, Volodymyr Prokopyuk  
> wrote:
> 
> Is it possible to define a turn with two accidentals as shown below?

I think you must design them, say adding another column item to what I use:

mordentsharp = ^\markup \left-align \center-column {
 \musicglyph #"scripts.mordent" \raise #1.0 \tiny\sharp
}

turnlowersharp = ^\markup { \lower #8.0 \left-align \center-column {
  \musicglyph #"scripts.turn" \raise #1.0 \tiny\sharp
}
}

Re: How to define a turn with two accidentals

[Knute Snortum]

Expanding on Jakob's suggestion, try:

\version "2.24.2"

sharpTurnFlat =
  \markup {
\center-column {
  \lower #2 \tiny \flat
  \lower #1 \musicglyph "scripts.turn"
  \tiny \sharp
}
  }

\relative c'' {
  \time 2/4
  g4-\tweak X-offset 1.5 ^\markup \sharpTurnFlat
  e'8 c
  \bar "||"
}

--
Knute Snortum



On Thu, Oct 12, 2023 at 4:41 PM Jakob Pedersen  wrote:

> Hi Vlad,
>
> Perhaps not quite what you are looking for, but you can use columns of
> markup like so:
>
> \relative c'' { \time 2/4 g4^\markup { \center-column { \flat \musicglyph
> "scripts.turn" \sharp } } e'8 c \bar "||" }
>
> I'm sure there's a better way known to the real experts, so consider this
> a not-quite-good hack.
>
> Best wishes,
> Jakob
>
> On 12.10.2023 23.10, Volodymyr Prokopyuk wrote:
>
> Hi,
>
> Is it possible to define a turn with two accidentals as shown below?
>
> [image: image.png]
>
> The LilyPond documentation has a snippet here
> https://lilypond.org/doc/v2.24/Documentation/notation/expressive-marks-attached-to-notes
> for a turn with one accidental.
>
> Thank you,
> Vlad
>
>
>

Re: How to define a turn with two accidentals

[Jakob Pedersen]

Hi Vlad,

Perhaps not quite what you are looking for, but you can use columns of 
markup like so:


\relative c'' { \time 2/4 g4^\markup { \center-column { \flat 
\musicglyph "scripts.turn" \sharp } } e'8 c \bar "||" }


I'm sure there's a better way known to the real experts, so consider 
this a not-quite-good hack.


Best wishes,
Jakob

On 12.10.2023 23.10, Volodymyr Prokopyuk wrote:

Hi,

Is it possible to define a turn with two accidentals as shown below?

image.png

The LilyPond documentation has a snippet here 
https://lilypond.org/doc/v2.24/Documentation/notation/expressive-marks-attached-to-notes 
for a turn with one accidental.


Thank you,
Vlad

How to define a turn with two accidentals

[Volodymyr Prokopyuk]

Hi,

Is it possible to define a turn with two accidentals as shown below?

[image: image.png]

The LilyPond documentation has a snippet here
https://lilypond.org/doc/v2.24/Documentation/notation/expressive-marks-attached-to-notes
for a turn with one accidental.

Thank you,
Vlad

Re: shifting accidentals horizontally

[Werner LEMBERG]

> A possible solution for this could be to do a similar thing to add
> certain note columns to separate NoteCollision grobs, so they can be
> spaced independently.

I've added Valentin's solution as a new snippet to the LSR.

  https://lsr.di.unimi.it/LSR/Item?u=1&id=1172


Werner

Re: automatic accidentals in subsequent measure(s) of *a different staff* in a PianoStaff context

[David Kastrup]

Kieren MacMillan  writes:

> Hi all,
>
>>> Haven't you been dreaming about your First Patch™ for quite a while?
>
> Why, yes… yes I have!
>
>> You mean, in a dozen years?
>
> My immediate reactions was “wait wut i actually made three commits at
> some point?” LOL

Graham was really good at getting people involved and matching their
capabilities to tasks.  It's a good sign that you seem to be getting
there again.

-- 
David Kastrup

Re: automatic accidentals in subsequent measure(s) of *a different staff* in a PianoStaff context

[Kieren MacMillan]

Hi all,

>> Haven't you been dreaming about your First Patch™ for quite a while?

Why, yes… yes I have!

> You mean, in a dozen years?

My immediate reactions was “wait wut i actually made three commits at some 
point?” LOL

>> I mean, this would just be a matter of adding the style to the
>> accidental-styles alist in scm/music-functions.scm (plus updating the
>> documentation and regtests). Just saying...
> 
> Indeed that sounds like a job for an uncautious "Yes" sayer.

On the one hand, a large part of my problem as a member of society is being too 
uncautious a “Yes” sayer! ;)
On the other hand… “YES! I intend to try to get this into a patch!!”
[Now we'll see if less than a dozen years passes before it happens.]

Best,
Kieren.
__

My work day may look different than your work day. Please do not feel obligated 
to read or respond to this email outside of your normal working hours.

Re: automatic accidentals in subsequent measure(s) of *a different staff* in a PianoStaff context

[David Kastrup]

Jean Abou Samra  writes:

>> > > Nice!  Shall we add this to LilyPond proper?
>> > I have no opinion.
>> 
>> I do (surprise surprise):
>> Yes.
>> Though possibly with a different name (?).
>> Regardless, seems like a useful LSR item.
>
>
> Haven't you been dreaming about your First Patch™ for quite a while?

You mean, in a dozen years?  Because I have

commit 03cb2f1ebc5ba2ca8ef2a7d05954a33babae5ac3
Author: Kieren MacMillan 
Date:   Thu May 27 09:48:37 2010 -0600

Add independent control of thickness and offset for underline markup

commit 5795203d3821ceaa5cd0e024350682fcfaf90691
Author: Kieren MacMillan 
Date:   Fri Mar 13 11:12:29 2009 -0400

Add docstrings to functions in music-functions-init.ly; from Kieren.

commit 17ab05d3eb28ffc7112c3a4af47116dd8dd7207c
Author: Kieren MacMillan 
Date:   Tue Sep 30 11:36:46 2008 +0100

Docs: Templates: piano centered dynamics

> I mean, this would just be a matter of adding the style to the
> accidental-styles alist in scm/music-functions.scm (plus updating the
> documentation and regtests). Just saying...

Indeed that sounds like a job for an uncautious "Yes" sayer.

-- 
David Kastrup

Re: automatic accidentals in subsequent measure(s) of *a different staff* in a PianoStaff context

[Jean Abou Samra]

> > > Nice!  Shall we add this to LilyPond proper?
> > I have no opinion.
> 
> I do (surprise surprise):
> Yes.
> Though possibly with a different name (?).
> Regardless, seems like a useful LSR item.


Haven't you been dreaming about your First Patch™ for quite a while? I mean,
this would just be a matter of adding the style to the accidental-styles alist
in scm/music-functions.scm (plus updating the documentation and regtests). Just
saying...

Best
Jean





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

Re: automatic accidentals in subsequent measure(s) of *a different staff* in a PianoStaff context

[Kieren MacMillan]

Howdy!

> On Sep 5, 2023, at 5:55 AM, Jean Abou Samra  wrote:
> > %% An accidental style that also prints cancellation signs in the
> > %% following measure for different octaves ("piano" only does it for
> > %% the same octave).

Thanks — that's perfect.  :)

>> Nice!  Shall we add this to LilyPond proper?
> I have no opinion.

I do (surprise surprise):
Yes.
Though possibly with a different name (?).
Regardless, seems like a useful LSR item.

Many thanks!
Kieren.
__

My work day may look different than your work day. Please do not feel obligated 
to read or respond to this email outside of your normal working hours.

Re: automatic accidentals in subsequent measure(s) of *a different staff* in a PianoStaff context

[Jean Abou Samra]

Le mardi 05 septembre 2023 à 09:48 +, Werner LEMBERG a écrit :
> > %% An accidental style that also prints cancellation signs in the
> > %% following measure for different octaves ("piano" only does it for
> > %% the same octave).
> 
> Nice!  Shall we add this to LilyPond proper?

I have no opinion.



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

Re: automatic accidentals in subsequent measure(s) of *a different staff* in a PianoStaff context

[Werner LEMBERG]

> %% An accidental style that also prints cancellation signs in the
> %% following measure for different octaves ("piano" only does it for
> %% the same octave).

Nice!  Shall we add this to LilyPond proper?


Werner

Re: automatic accidentals in subsequent measure(s) of *a different staff* in a PianoStaff context

[Jean Abou Samra]

Try this:

\version "2.25.7"

%% An accidental style that also prints cancellation signs in the following
%% measure for different octaves ("piano" only does it for the same octave).
#(set! accidental-styles
   (cons
`(piano-customized #f
   (Staff ,(make-accidental-rule 'same-octave 0)
  ,(make-accidental-rule 'any-octave 0)
  ,(make-accidental-rule 'same-octave 1)
  ,(make-accidental-rule 'any-octave 1)
  GrandStaff
  ,(make-accidental-rule 'same-octave 1)
  ,(make-accidental-rule 'any-octave 1))
   ()
   GrandStaff)
accidental-styles))

\language "english"

\layout {
  \context {
\PianoStaff
\accidentalStyle piano-customized
  }
}

\new PianoStaff <<
  \new Staff { 1   }
  \new Staff { \clef bass 1   }
>>





Best,
Jean



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

automatic accidentals in subsequent measure(s) of *a different staff* in a PianoStaff context

[Kieren MacMillan]

Hi all,

  SNIPPET BEGINS
\version "2.25.2"
\language "english"

\layout {
  \context {
\PianoStaff
\accidentalStyle piano
  }
}

\new PianoStaff <<
  \new Staff { 1   }
  \new Staff { \clef bass 1   }
>>
  SNIPPET ENDS

Is there an automated way to make a natural sign (full or cautionary) appear on 
the C in m3 of the LH, as a result of the fact that m2 in the RH contains a C#?

Thanks,
Kieren.
__

My work day may look different than your work day. Please do not feel obligated 
to read or respond to this email outside of your normal working hours.

Re: markup accidentals for a microtonal system

[Thomas Richter]

Hello Nike,

following your submission I extended Ekmelily to support now arbitrary 
markup (not only glyphs from an external font); see 
www.ekmelic-music.org/en/extra/ekmelily.htm 
<http://www.ekmelic-music.org/en/extra/ekmelily.htm> (version 3.11).


Maybe this is a solution for you. It defines accidentals for eighth 
tones with glyphs from LilyPond's Emmentaler font and additional markup, 
and it also works for midi output.  It uses notenames defined in 
"ekmel-48.ily", but I could also define a new set of notenames with 
suffix "et" for eighth tones upward, however, I'm not sure how to name 
downward alterations.



\version "2.24.0"
\include "ekmel-48.ily"

arrow = \markup {
    \override #'(thickness . 1.45)
    \overlay {
    \draw-line #'(0.01 . -2)
    \draw-line #'(-0.3 . -0.7)
    \draw-line #'(0.3 . -0.7)
    }}

\ekmelicUserStyle myeighthnotation #`(
    (1/8 ,(markup #:translate '(0 . 0.4) arrow))
    (-1/8 ,(markup #:translate '(0 . 1.5) #:rotate 180 arrow))
    (1/4 ,(markup #:musicglyph "accidentals.sharp.slashslash.stem"))
    (-1/4 ,(markup #:musicglyph "accidentals.mirroredflat"))
    (3/8 ,(markup #:combine
    #:musicglyph "accidentals.sharp.slashslash.stem"
    #:translate '(0.35 . 2.5) arrow))
    (-3/8 ,(markup #:combine
    #:musicglyph "accidentals.mirroredflat"
    #:translate '(0.7 . 0) #:rotate 180 arrow))
    (1/2 ,(markup #:sharp))
    (-1/2 ,(markup #:flat))
    (5/8 ,(markup #:musicglyph "accidentals.sharp.arrowup"))
    (-5/8 ,(markup #:musicglyph "accidentals.flat.arrowdown"))
    (3/4 ,(markup #:musicglyph 
"accidentals.sharp.slashslash.stemstemstem"))

    (-3/4 ,(markup #:musicglyph "accidentals.mirroredflat.flat"))
    (7/8 ,(markup #:combine
    #:musicglyph "accidentals.sharp.slashslash.stemstemstem"
    #:translate '(1.24 . 2.5) arrow))
    (-7/8 ,(markup #:combine
    #:musicglyph "accidentals.mirroredflat.flat"
    #:translate '(0.8 . 0) #:rotate 180 arrow))
    (1 ,(markup #:doublesharp))
    (-1 ,(markup #:doubleflat))
)

\fixed c' {
    cil cih cisel cis cisil cisih cisisel cisis
    del deh desil des desel deseh desesil deses
}

Regards,
Thomas Richter

Re: markup accidentals for a microtonal system

[Gregory Evans]

Hi Nike,

I believe this could work. First you would assign glyph values to your
accidentals arbitrarily, ensuring you use no duplicate glyph. Then you
could use something like the following function to swap the glyphs out for
your markups.

alt-accidentals = #(lambda (grob)
(let* (
(sz (ly:grob-property grob 'font-size 0))
(mlt (magstep sz))
(glyph (ly:grob-property grob 'glyph-name)))
(cond
((equal? glyph "accidentals.sharp.slashslash.stem")
(grob-interpret-markup grob one-quarter-sharp-markup-short)
)
((equal? glyph "accidentals.sharp.slashslash.stemstemstem")
(grob-interpret-markup grob three-quarters-sharp-markup-triple)
)
((equal? glyph "accidentals.mirroredflat")
(grob-interpret-markup grob one-quarter-flat-markup-black)
)
((equal? glyph "accidentals.mirroredflat.flat")
(ly:stencil-scale (grob-interpret-markup grob
three-quarters-flat-markup-black) (* .7 mlt) (* .7 mlt))
)
(else (ly:clef::print grob)))
)
)

This will check the accidentals when they are supposed to be printed and if
the glyph matches your condition it is replaced by a new symbol (a markup
interpreted as a grob). You can also use this mlt variable to rescale the
symbol relative to the font size if you need it. Somewhere at the top of
your file, or in a stylesheet you will include \override Accidental.stencil
= \alt-accidentals to activate the substitution process. If this doesn’t
work, there’s always Ekmelily (
http://www.ekmelic-music.org/en/extra/ekmelily.htm).

regards,
gregory evans

p.s. I will be interested to see if anyone has a different solution.

On Sun, Aug 13, 2023 at 2:27 AM Nike Hedges  wrote:

> Hi,
>
> Looking back at how to implement a microtonal system in LilyPond,
>
> I've known it with a single glyph of an accidental per pitch,
> as my old question was answered:
> Re: Eighth Tones (microtonal) by Mark Knoop
> https://lists.gnu.org/archive/html/lilypond-user/2015-07/msg00485.html
>
> Now I want to mark up an accidental glyph into a new accidental symbol,
> e.g. shown here,
> Re: accidental query by Gregory Evans
> https://lists.gnu.org/archive/html/lilypond-user/2023-02/msg00256.html
>
> and to put such a markup into a microtonal system Mark suggested.
>
> However I couldn't find any room to put \markup here but one glyph name.
>
> arrowGlyphs = #`(
> ( 1 . "accidentals.doublesharp")
> (,SEVEN-E-SHARP .
> "accidentals.sharp.slashslashslash.stemstem")
>
>
> How could I possibly build a microtonal system with markup? Or rather I
> can't help putting \markup on each note on the fly as Gregory does, can I?
>
>
> Kind regards,
> Nike Hedges
>
>

-- 
gregory rowland evans
http://www.gregoryrowlandevans.com
https://github.com/GregoryREvans
https://soundcloud.com/gregory-rowland-evans

markup accidentals for a microtonal system

[Nike Hedges]

Hi,

Looking back at how to implement a microtonal system in LilyPond,

I've known it with a single glyph of an accidental per pitch,
as my old question was answered:
Re: Eighth Tones (microtonal) by Mark Knoop
https://lists.gnu.org/archive/html/lilypond-user/2015-07/msg00485.html

Now I want to mark up an accidental glyph into a new accidental symbol,
e.g. shown here,
Re: accidental query by Gregory Evans
https://lists.gnu.org/archive/html/lilypond-user/2023-02/msg00256.html

and to put such a markup into a microtonal system Mark suggested.

However I couldn't find any room to put \markup here but one glyph name.

arrowGlyphs = #`(
( 1 . "accidentals.doublesharp")
(,SEVEN-E-SHARP .
"accidentals.sharp.slashslashslash.stemstem")


How could I possibly build a microtonal system with markup? Or rather I
can't help putting \markup on each note on the fly as Gregory does, can I?


Kind regards,
Nike Hedges

Re: shifting accidentals horizontally

[Paul Hodges]

Gould p91 "Altered Unisons" gives the requested layout, not the LilyPond one.


Paul



 From:   Werner LEMBERG  
 To:
 Cc:
 Sent:   12/06/2023 18:46 
 Subject:   Re: shifting accidentals horizontally 

 
> Not the answer to the Lilypond question, but as a reference of 
> comparison, here is what Dorico does in this situation by default, 
> and I believe this to be correct standard practice. 
 
Well, it can't be generalized – sometimes LilyPond's default is the 
right choice.  However, it would be nice to have a simple command to 
get the 'other' solution (that Dorico defaults to). 
 
 
    Werner 

Re: shifting accidentals horizontally

[Valentin Petzel]

Or rather there is the

NoteColumn.ignore-collision

property. If set to #t the Note column will not be added to any NoteCollision 
grob. The problem here is that in this case there need to be no positional 
correction. So we require some additional check in the engraver to apply this 
correction depending on whether this ignore-collision property is true.

Cheers,
Valentin

Am Dienstag, 13. Juni 2023, 12:13:46 CEST schrieb Werner LEMBERG:
> > A possible solution for this could be to do a similar thing to add
> > certain note columns to separate NoteCollision grobs, so they can be
> > spaced independently.  However, it your case it should suffice to
> > prevent any Collisions to be detected by doing
> > 
> > \once\override Staff.NoteCollision.note-collision-threshold = #-1
> 
> 
> Excellent, and thanks again!  It works just fine.
> 
> I'm more and more convinced that the whole issue is stuff for an
> excellent LSR snippet :-) Will you have time to provide that?
> 
> 
> Werner

#(define (which lst)
   (define (impl lst count)
 (if (null? lst)
 #f
 (if (car lst)
 count
 (impl (cdr lst) (1+ count)
   (impl lst 0))


#(define (custom_accidental_placement_engraver context)
   (define (grob-array->list x)
 (if (ly:grob-array? x)
 (ly:grob-array->list x)
 '()))
   (let ((placement #f) (right-padding #f))
 (make-engraver
  (acknowledgers
   ((accidental-interface engraver grob source-engraver)
(if (assoc-get 'capture (ly:grob-property grob 'details) #f)
(begin
  (if (not placement)
  (begin
   (set! placement (ly:engraver-make-grob engraver 'AccidentalPlacement '()))
   (ly:grob-set-parent! placement X (ly:grob-parent (ly:grob-parent grob Y) X))
   (let ((padding (ly:grob-property-data placement 'right-padding)))
 (set!
  right-padding
  (lambda (grob)
(let* ((grobs (ly:grob-object grob 'accidental-grobs))
   (grobs (apply append (map cdr grobs)))
   (heads (map (lambda (x) (ly:grob-parent x Y)) grobs))
   (stems (map (lambda (x) (ly:grob-object x 'stem)) heads))
   (cols (map (lambda (x) (ly:grob-parent x X)) heads))
   (collisions (map (lambda (x) (ly:grob-parent x X)) cols))
   (cols2 (apply append
 (map 
  (lambda (x)
(grob-array->list (ly:grob-object x 'elements)))
  collisions)))
   (heads2 (apply append
  (map
   (lambda (x)
 (grob-array->list (ly:grob-object x 'note-heads)))
   cols2)))
   (stems2 (map (lambda (x) (ly:grob-object x 'stem)) heads))
   (grob-set1 (ly:grob-list->grob-array (append heads stems)))
   (grob-set2 (ly:grob-list->grob-array (append heads stems heads2 stems2)))
   (refp (ly:grob-common-refpoint-of-array grob grob-set1 X))
   (refp2 (ly:grob-common-refpoint-of-array grob grob-set2 X))
   (ext (ly:grob-extent refp refp2 X))
   (ext2 (ly:grob-extent refp2 refp2 X))
   (offset (car ext))
   (offset (- offset (car ext2
  (- (if (procedure? padding) (padding grob) padding) offset)))
  (let* ((src-placement (ly:grob-parent grob X))
 (grobs (ly:grob-object src-placement 'accidental-grobs))
 (has-grob? (map (lambda (pair) (memq grob (cdr pair))) grobs))
 (pair (list-ref grobs (which has-grob?)))
 (notename (car pair))
 (groblist (cdr pair))
 (new-grobs (ly:grob-object placement 'accidental-grobs))
 (new-groblist (assoc-get notename new-grobs '()))
 (groblist (delete grob groblist eq?))
 (new-groblist (cons grob new-groblist))
 (grobs (assoc-set! grobs notename groblist))
 (new-grobs (assoc-set! new-grobs notename new-groblist)))
(if (not (ly:grob-property (ly:grob-parent (ly:grob-parent grob Y) X) 'ignore-collision #f))
(ly:grob-set-property! placement 'right-padding right-padding))
(ly:grob-set-object! src-placement 'accidental-g

Re: shifting accidentals horizontally

[Werner LEMBERG]

> A possible solution for this could be to do a similar thing to add
> certain note columns to separate NoteCollision grobs, so they can be
> spaced independently.  However, it your case it should suffice to
> prevent any Collisions to be detected by doing
> 
> \once\override Staff.NoteCollision.note-collision-threshold = #-1

Excellent, and thanks again!  It works just fine.

I'm more and more convinced that the whole issue is stuff for an
excellent LSR snippet :-) Will you have time to provide that?


Werner

Re: shifting accidentals horizontally

[Valentin Petzel]

Hello Werner,

this Problem is not caused by my solution, but generally by your approach of 
taking the Notes with collision applied (the 8th note bb on the left, the b,e 
on the right) and shifting the bb until it is right of the others. This still 
means that the  will be offcentered.

So this will also happen with your original extra-offset solution. A possible 
solution for this could be to do a similar thing to add certain note columns 
to separate NoteCollision grobs, so they can be spaced independently. However, 
it your case it should suffice to prevent any Collisions to be detected by doing

\once\override Staff.NoteCollision.note-collision-threshold = #-1

(this essentially means a collision is only considered such if the distance is 
under -1, so never).

This will of course mean that you’ll need to use other hshift values, as 
horizontal positioning will then be totally your responsibility. So doing 
something like this should work:

<<
  \new Staff {
<< { \once\override Staff.NoteCollision.note-collision-threshold = #-1 2. 4 |
 \once\override Staff.NoteCollision.note-collision-threshold = #-1 2. 4 } \\
   { \once \override NoteColumn.force-hshift = #2
 bes'!8 a' g' f' bes' a' g' f' |
 \once \override NoteColumn.force-hshift = #3
 \once \override Accidental.details.capture = ##t
 bes'!8 a' g' f' bes' a' g' f' } >>
  }
  \new Staff {
\clef bass
2 q |
q2 q |
  }
>>

Cheers,
Valentin

Am Dienstag, 13. Juni 2023, 06:37:46 CEST schrieb Werner LEMBERG:
> > @Werner I’ve added a small fix concerning the case when there is no
> > NoteCollision grob (in which case this should not be relevant in the
> > first place).
> 
> 
> Thanks a lot!  I think this would be a great snippet for the
> LSR.
> 
> Note, however, that there are alignment problems with other staves,
> see below.  For this particular case I can fix it by using
> `NoteColumn.X-offset`, but this isn't a sustainable solution.
> 
> 
> Werner
> 
> 
> ==
> 
> 
> #(define (which lst)
>(define (impl lst count)
>  (if (null? lst)
>  #f
>  (if (car lst)
>  count
>  (impl (cdr lst) (1+ count)
>(impl lst 0))
> 
> 
> #(define (custom_accidental_placement_engraver context)
>(define (grob-array->list x)
>  (if (ly:grob-array? x)
>  (ly:grob-array->list x)
>  '()))
>(let ((placement #f))
>  (make-engraver
>   (acknowledgers
>((accidental-interface engraver grob source-engraver)
> (if (assoc-get 'capture (ly:grob-property grob 'details) #f)
> (begin
>   (if (not placement)
>   (begin
>(set! placement (ly:engraver-make-grob engraver
> 'AccidentalPlacement '()))
 (ly:grob-set-parent! placement X
> (ly:grob-parent (ly:grob-parent grob Y) X)) (let ((padding
> (ly:grob-property-data placement 'right-padding))) (ly:grob-set-property!
>   placement
>   'right-padding
>   (lambda (grob)
> (let* ((grobs (ly:grob-object placement
> 'accidental-grobs))
 (grobs (apply append (map cdr grobs))) (heads (map
> (lambda (x) (ly:grob-parent x Y)) grobs)) (stems (map (lambda (x)
> (ly:grob-object x 'stem)) heads)) (cols (map (lambda (x) (ly:grob-parent x
> X)) heads)) (collisions (map (lambda (x) (ly:grob-parent x X)) cols))
> (cols2 (apply append
>  (map 
>   (lambda (x)
> (grob-array->list
> (ly:grob-object x 'elements)))
 collisions)))
>(heads2 (apply append
>   (map
>(lambda (x)
>  (grob-array->list
> (ly:grob-object x 'note-heads)))
 cols2)))
>(stems2 (map (lambda (x) (ly:grob-object x
> 'stem)) heads))
 (grob-set1 (ly:grob-list->grob-array (append heads
> stems))) (grob-set2 (ly:grob-list->grob-array (append heads stems heads2
> stems2))) (refp (ly:grob-common-refpoint-of-array grob grob-set1 X)) (refp2
> (ly:grob-common-refpoint-of-array grob grob-set2 X)) (ext (ly:grob-extent
> refp refp2 X)) (ext2 (ly:grob-extent refp2 refp2 X)) (offset (car ext))
>(offset (- offset (car ext2
>   (- (if (procedure? padding) (padding grob)
> padding) offset)))
 (let* ((src-placement (ly:grob-parent grob X))
>  (grobs (ly:grob-object src-placement
> 'accidental-grobs))
 (has-grob? (map (lambda (pair) (memq grob (cdr pair)))
> grobs)) (pair (list-ref grobs (which has-grob?)))
>  (notename (car pair))
>  (groblist (cdr pair))
>  (new-grobs

Re: shifting accidentals horizontally

[Werner LEMBERG]

> @Werner I’ve added a small fix concerning the case when there is no
> NoteCollision grob (in which case this should not be relevant in the
> first place).

Thanks a lot!  I think this would be a great snippet for the
LSR.

Note, however, that there are alignment problems with other staves,
see below.  For this particular case I can fix it by using
`NoteColumn.X-offset`, but this isn't a sustainable solution.


Werner


==


#(define (which lst)
   (define (impl lst count)
 (if (null? lst)
 #f
 (if (car lst)
 count
 (impl (cdr lst) (1+ count)
   (impl lst 0))


#(define (custom_accidental_placement_engraver context)
   (define (grob-array->list x)
 (if (ly:grob-array? x)
 (ly:grob-array->list x)
 '()))
   (let ((placement #f))
 (make-engraver
  (acknowledgers
   ((accidental-interface engraver grob source-engraver)
(if (assoc-get 'capture (ly:grob-property grob 'details) #f)
(begin
  (if (not placement)
  (begin
   (set! placement (ly:engraver-make-grob engraver 
'AccidentalPlacement '()))
   (ly:grob-set-parent! placement X (ly:grob-parent 
(ly:grob-parent grob Y) X))
   (let ((padding (ly:grob-property-data placement 
'right-padding)))
 (ly:grob-set-property!
  placement
  'right-padding
  (lambda (grob)
(let* ((grobs (ly:grob-object placement 
'accidental-grobs))
   (grobs (apply append (map cdr grobs)))
   (heads (map (lambda (x) (ly:grob-parent x Y)) 
grobs))
   (stems (map (lambda (x) (ly:grob-object x 
'stem)) heads))
   (cols (map (lambda (x) (ly:grob-parent x X)) 
heads))
   (collisions (map (lambda (x) (ly:grob-parent x 
X)) cols))
   (cols2 (apply append
 (map 
  (lambda (x)
(grob-array->list 
(ly:grob-object x 'elements)))
  collisions)))
   (heads2 (apply append
  (map
   (lambda (x)
 (grob-array->list 
(ly:grob-object x 'note-heads)))
   cols2)))
   (stems2 (map (lambda (x) (ly:grob-object x 
'stem)) heads))
   (grob-set1 (ly:grob-list->grob-array (append 
heads stems)))
   (grob-set2 (ly:grob-list->grob-array (append 
heads stems heads2 stems2)))
   (refp (ly:grob-common-refpoint-of-array grob 
grob-set1 X))
   (refp2 (ly:grob-common-refpoint-of-array grob 
grob-set2 X))
   (ext (ly:grob-extent refp refp2 X))
   (ext2 (ly:grob-extent refp2 refp2 X))
   (offset (car ext))
   (offset (- offset (car ext2
  (- (if (procedure? padding) (padding grob) padding) 
offset)))
  (let* ((src-placement (ly:grob-parent grob X))
 (grobs (ly:grob-object src-placement 'accidental-grobs))
 (has-grob? (map (lambda (pair) (memq grob (cdr pair))) 
grobs))
 (pair (list-ref grobs (which has-grob?)))
 (notename (car pair))
 (groblist (cdr pair))
 (new-grobs (ly:grob-object placement 'accidental-grobs))
 (new-groblist (assoc-get notename new-grobs '()))
 (groblist (delete grob groblist eq?))
 (new-groblist (cons grob new-groblist))
 (grobs (assoc-set! grobs notename groblist))
 (new-grobs (assoc-set! new-grobs notename new-groblist)))
(ly:grob-set-object! src-placement 'accidental-grobs grobs)
(ly:grob-set-object! placement 'accidental-grobs new-grobs)
(ly:grob-set-parent! grob X placement))
  ((finish-timestep engraver)
   (set! placement #f)

\layout {
  \context {
\Voice
\consists #custom_accidental_placement_engraver
  }
}

<<
  \new Staff {
<< { 2. 4 |
 2. 4 } \\
   { \once \override NoteColumn.force-hshift = #2.4
 bes'!8 a' g' f' bes' a' g' f' |
 \once \override NoteColumn.force-hshift = #3.4
 \once \override Accidental.details.capture = ##t
 bes'!8 a' g' f' bes' a' g' f' } >>
  }
  \new Staff {

Re: shifting accidentals horizontally

[Werner LEMBERG]

> Even though I can imagine this happening, I don't recall seeing it
> as a pianist.  Even if you tweak it to swap the note columns, I
> think it will still be a bit confusing.

As Damian has observed, there are plenty of examples in Bartók's piano
sonata.  Other, similar situations can be found in Berg's vocal scores
of Lulu or Wozzeck, say, which both contain highly complex, polyphonal
music, and where the creators of the vocal scores took great pains to
retain the polyphony in the piano reduction.

> There are two obvious fixes: if you are the composer, you could
> consider changing the B♭ into an A♯. And the other solution is to
> move the B♭ note to the lower staff in a local treble clef.

I'm aware of that, thanks, but neither is a good solution for my use
case.


Werner

Re: shifting accidentals horizontally

[Damian leGassick]

> Even though I can imagine this happening, I don't recall seeing
> it as a pianist. Even if you tweak it to swap the note columns,
> I think it will still be a bit confusing.
> 
> There are two obvious fixes: if you are the composer, you could
> consider changing the B♭ into an A♯. And the other solution is
> to move the B♭ note to the lower staff in a local treble clef.

there’s many examples in Bartok, e.g. Sonata, p9 has about 10 of them

D

Re: shifting accidentals horizontally

[Valentin Petzel]

Hello Jean,

I think a possible case would be something like the appended case, so if we 
have some sort of superimposed patterns.

@Werner I’ve added a small fix concerning the case when there is no 
NoteCollision grob (in which case this should not be relevant in the first 
place).

Cheers,
Valentin

Am Montag, 12. Juni 2023, 22:32:17 CEST schrieb Jean Abou Samra:
> Le lundi 12 juin 2023 à 17:02 +, Werner LEMBERG a écrit :
> > Please consider the example code below.  The first line shows
> > LilyPond's default, the second line shows what I need.  As can be
> > seen, the solution in the second line is imperfect – I just did the
> > most basic changes to demonstrate what I want, namely the down-stemmed
> > note to be positioned after the up-stemmed chord.
> > 
> > Is there an automated solution for this problem (namely correctly
> > positioned and spaced naturals for the chord)?  The LSR doesn't really
> > help, unfortunately.
> > 
> > BTW, such situations happen from time to time in piano music.
> > 
> > ```
> > \version "2.25.6"
> > 
> > << { 2. } \\
> >{ bes'!8 } >>
> > 
> > << { 2. } \\
> >{
> >  \once \override NoteColumn.force-hshift = #3.3
> >  \once \override Accidental.extra-offset = #'(4.7 . 0)
> >  bes'!8 } >>
> > ```
> 
> Even though I can imagine this happening, I don't recall seeing
> it as a pianist. Even if you tweak it to swap the note columns,
> I think it will still be a bit confusing.
> 
> There are two obvious fixes: if you are the composer, you could
> consider changing the B♭ into an A♯. And the other solution is
> to move the B♭ note to the lower staff in a local treble clef.

#(define (which lst)
   (define (impl lst count)
 (if (null? lst)
 #f
 (if (car lst)
 count
 (impl (cdr lst) (1+ count)
   (impl lst 0))


#(define (custom_accidental_placement_engraver context)
   (define (grob-array->list x)
 (if (ly:grob-array? x)
 (ly:grob-array->list x)
 '()))
   (let ((placement #f))
 (make-engraver
  (acknowledgers
   ((accidental-interface engraver grob source-engraver)
(if (assoc-get 'capture (ly:grob-property grob 'details) #f)
(begin
  (if (not placement)
  (begin
   (set! placement (ly:engraver-make-grob engraver 'AccidentalPlacement '()))
   (ly:grob-set-parent! placement X (ly:grob-parent (ly:grob-parent grob Y) X))
   (let ((padding (ly:grob-property-data placement 'right-padding)))
 (ly:grob-set-property!
  placement
  'right-padding
  (lambda (grob)
(let* ((grobs (ly:grob-object placement 'accidental-grobs))
   (grobs (apply append (map cdr grobs)))
   (heads (map (lambda (x) (ly:grob-parent x Y)) grobs))
   (stems (map (lambda (x) (ly:grob-object x 'stem)) heads))
   (cols (map (lambda (x) (ly:grob-parent x X)) heads))
   (collisions (map (lambda (x) (ly:grob-parent x X)) cols))
   (cols2 (apply append
 (map 
  (lambda (x)
(grob-array->list (ly:grob-object x 'elements)))
  collisions)))
   (heads2 (apply append
  (map
   (lambda (x)
 (grob-array->list (ly:grob-object x 'note-heads)))
   cols2)))
   (stems2 (map (lambda (x) (ly:grob-object x 'stem)) heads))
   (grob-set1 (ly:grob-list->grob-array (append heads stems)))
   (grob-set2 (ly:grob-list->grob-array (append heads stems heads2 stems2)))
   (refp (ly:grob-common-refpoint-of-array grob grob-set1 X))
   (refp2 (ly:grob-common-refpoint-of-array grob grob-set2 X))
   (ext (ly:grob-extent refp refp2 X))
   (ext2 (ly:grob-extent refp2 refp2 X))
   (offset (car ext))
   (offset (- offset (car ext2
  (- (if (procedure? padding) (padding grob) padding) offset)))
  (let* ((src-placement (ly:grob-parent grob X))
 (grobs (ly:grob-object src-placement 'accidental-grobs))
 (has-grob? (map (lambda (pair) (memq grob (cdr pair))) grobs))
 (pair (list-ref grobs (which has-grob?)))
 (notename (car pair))
 (

Re: shifting accidentals horizontally

[Jean Abou Samra]

Le lundi 12 juin 2023 à 17:02 +, Werner LEMBERG a écrit :
> Please consider the example code below.  The first line shows
> LilyPond's default, the second line shows what I need.  As can be
> seen, the solution in the second line is imperfect – I just did the
> most basic changes to demonstrate what I want, namely the down-stemmed
> note to be positioned after the up-stemmed chord.
> 
> Is there an automated solution for this problem (namely correctly
> positioned and spaced naturals for the chord)?  The LSR doesn't really
> help, unfortunately.
> 
> BTW, such situations happen from time to time in piano music.
> 
> ```
> \version "2.25.6"
> 
> << { 2. } \\
>    { bes'!8 } >>
> 
> << { 2. } \\
>    {
>  \once \override NoteColumn.force-hshift = #3.3
>  \once \override Accidental.extra-offset = #'(4.7 . 0)
>  bes'!8 } >>
> ```


Even though I can imagine this happening, I don't recall seeing
it as a pianist. Even if you tweak it to swap the note columns,
I think it will still be a bit confusing.

There are two obvious fixes: if you are the composer, you could
consider changing the B♭ into an A♯. And the other solution is
to move the B♭ note to the lower staff in a local treble clef.


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

Re: shifting accidentals horizontally

[Valentin Petzel]

Hello Werner,

I’ve tried something using an engraver that sends of accidentals from the 
given context to a separate AccidentalPlacement grob:

%
#(define (which lst)
   (define (impl lst count)
 (if (null? lst)
 #f
 (if (car lst)
 count
 (impl (cdr lst) (1+ count)
   (impl lst 0))

#(define (custom_accidental_placement_engraver context)
   (let ((placement #f))
 (make-engraver
  (acknowledgers
   ((accidental-interface engraver grob source-engraver)
(if (not placement)
(begin
 (set! placement (ly:engraver-make-grob engraver 
'AccidentalPlacement '()))
 (ly:grob-set-parent! placement X (ly:grob-parent (ly:grob-parent 
grob Y) X
(let* ((src-placement (ly:grob-parent grob X))
   (grobs (ly:grob-object src-placement 'accidental-grobs))
   (has-grob? (map (lambda (pair) (memq grob (cdr pair))) grobs))
   (pair (list-ref grobs (which has-grob?)))
   (notename (car pair))
   (groblist (cdr pair))
   (new-grobs (ly:grob-object placement 'accidental-grobs))
   (new-groblist (assoc-get notename new-grobs '()))
   (groblist (delete grob groblist eq?))
   (new-groblist (cons grob new-groblist))
   (grobs (assoc-set! grobs notename groblist))
   (new-grobs (assoc-set! new-grobs notename new-groblist)))
  (ly:grob-set-object! src-placement 'accidental-grobs grobs)
  (ly:grob-set-object! placement 'accidental-grobs new-grobs)
  (ly:grob-set-parent! grob X placement
  ((finish-timestep engraver)
   (set! placement #f)

{
  << { 2. } \\
   \new Voice \with { \consists #custom_accidental_placement_engraver } { 
\once \override NoteColumn.force-hshift = #3.3 bes'!8 } >>
}
%


Sadly this does not really do the trick because the Accidental-Placement grob 
uses the NoteCollision grob to gain access to all heads and stems and 
positions relative to the common refpoint. In my opinion this could be 
improved by using this common refpoint as offset for the AccidentalPlacement, 
and then position the Accidentals relative to this AccidentalPlacement. This 
would give us the ability to shift the Accidentals by shifting the X-offset.

We can still do something like

{
  << { 2. } \\
   \new Voice \with { \consists #custom_accidental_placement_engraver }
   { \once\override AccidentalPlacement.right-padding = #-3.7 \once \override 
NoteColumn.force-hshift = #3.4 bes'!8 } >>
},

So what I’ve done now is to use that property to automatically determine a 
"correct" value. Note that this may cause collisions!


%
#(define (which lst)
   (define (impl lst count)
 (if (null? lst)
 #f
 (if (car lst)
 count
 (impl (cdr lst) (1+ count)
   (impl lst 0))

#(define (custom_accidental_placement_engraver context)
   (let ((placement #f))
 (make-engraver
  (acknowledgers
   ((accidental-interface engraver grob source-engraver)
(if (not placement)
(begin
 (set! placement (ly:engraver-make-grob engraver 
'AccidentalPlacement '()))
 (ly:grob-set-parent! placement X (ly:grob-parent (ly:grob-parent 
grob Y) X))
 (let ((padding (ly:grob-property-data placement 'right-padding)))
   (ly:grob-set-property!
placement
'right-padding
(lambda (grob)
  (let* ((grobs (ly:grob-object placement 'accidental-grobs))
 (grobs (apply append (map cdr grobs)))
 (heads (map (lambda (x) (ly:grob-parent x Y)) grobs))
 (stems (map (lambda (x) (ly:grob-object x 'stem)) 
heads))
 (cols (map (lambda (x) (ly:grob-parent x X)) heads))
 (collisions (map (lambda (x) (ly:grob-parent x X)) 
cols))
 (cols2 (apply append
   (map 
(lambda (x)
  (ly:grob-array->list (ly:grob-object 
x 'elements)))
collisions)))
 (heads2 (apply append
(map
 (lambda (x)
   (ly:grob-array->list (ly:grob-
object x 'note-heads)))
 cols2)))
 (stems2 (map (lambda (x) (ly:grob-object x 'stem)) 
heads))
 (grob-set1 (ly:grob-list->grob-array (append heads 
stems)))
 (grob-set2 (ly:grob-list->grob-array (append heads 
stems heads2 stems2)))
  

Re: shifting accidentals horizontally

[Werner LEMBERG]

> Not the answer to the Lilypond question, but as a reference of
> comparison, here is what Dorico does in this situation by default,
> and I believe this to be correct standard practice.

Well, it can't be generalized – sometimes LilyPond's default is the
right choice.  However, it would be nice to have a simple command to
get the 'other' solution (that Dorico defaults to).


Werner

Re: shifting accidentals horizontally

[Andrew Bernard]

Not the answer to the Lilypond question, but as a reference of 
comparison, here is what Dorico does in this situation by default, and I 
believe this to be correct standard practice.


Andrew

shifting accidentals horizontally

[Werner LEMBERG]

Please consider the example code below.  The first line shows
LilyPond's default, the second line shows what I need.  As can be
seen, the solution in the second line is imperfect – I just did the
most basic changes to demonstrate what I want, namely the down-stemmed
note to be positioned after the up-stemmed chord.

Is there an automated solution for this problem (namely correctly
positioned and spaced naturals for the chord)?  The LSR doesn't really
help, unfortunately.

BTW, such situations happen from time to time in piano music.

```
\version "2.25.6"

<< { 2. } \\
   { bes'!8 } >>

<< { 2. } \\
   {
 \once \override NoteColumn.force-hshift = #3.3
 \once \override Accidental.extra-offset = #'(4.7 . 0)
 bes'!8 } >>
```


Werner

Re: Unicode accidentals vs. Markup accidentals

[David Wright]

On Sun 15 Jan 2023 at 22:52:50 (-0800), Saul Tobin wrote:
> Lilypond ships with a text font as well as a music font. I agree that I
> suspect that currently Lilypond's text font does not actually define these
> Unicode music characters, so it falls back on the OS to find them. Why not
> just add copies of Emmentaler glyphs to the Lilypond text fonts for
> characters within the Unicode spec? That seems like a pretty reasonable
> suggestion to me...

It might be worth thinking about where you would draw the line between
glyphs you would replace and those you wouldn't. After all, your
original post, and the Subject line, only dealt with accidentals, but
should you replace the entire Music Symbols Unicode Block, including
the combining forms, and fine tune them all so that the Emmentaler
would match LP's text font? (Some glyphs in the Block are also accidentals.)

Cheers,
David.

Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals

[Jean Abou Samra]

Le 16/01/2023 à 16:57, Kieren MacMillan a écrit :

Hi all,


In any case, please submit this to the LSR!

I was *just* going to look at this to see if it could be improved viz-a-viz 
Jean’s suggestion that callbacks using after-line-breaking are often better 
done with grob-transformer. [Yes, I know this is *before*-line-breaking…] If 
so, that should happen before LSR submission, I would think!

Maybe Someone™ can just tell me if it’s worth investigating or not…?



In this case, you cannot use \override TextScript.text = 
#(grob-transformer 'text ...)
because Text_engraver sets the property on the TextScript, so this 
overwrites

any overrides you might have done. However, you could do

\version "2.24.0"

tsharp = \markup \fontsize #-2 \number "♯"
tflat = \markup \fontsize #-2 \number "♭"
tnatural = \markup \fontsize #-2 \number "♮"

\new Staff {
  \override TextScript.stencil =
    #(lambda (grob)
   (let ((text (ly:grob-property grob 'text)))
 (grob-interpret-markup
  grob
  #{ \markup \replace #`(("♭" . ,#{ \markup \tflat #})
 ("♯" . ,#{ \markup \tsharp #})
 ("♮" . ,#{ \markup \tnatural #}))
 #text #})))
  c'1^"B♭"
  c'1^"C♯"
  c'1^"D♮"
}


Although it's probably simplest to do

\version "2.24.0"

\paper {
  #(add-text-replacements!
    `(("♯" . ,#{ \markup \fontsize #-2 \number "♯" #})
  ("♭" . ,#{ \markup \fontsize #-2 \number "♭" #})
  ("♮" . ,#{ \markup \fontsize #-2 \number "♮" #})))
}

\markup { A♯ B♭ C♮ }

\score {
  \header {
    piece = "Prelude in C♯"
  }
  {
    c'1^"B♭"
    c'1^"C♯"
    c'1^"D♮"
  }
}


As you can see, add-text-replacements! install the replacements
for all places markup can be used, not just for TextScript.

Best,
Jean



OpenPGP_signature
Description: OpenPGP digital signature

Re: Unicode accidentals vs. Markup accidentals

[Werner LEMBERG]

>>> Is there a possibility to register this or a similar function globally
>>> so that all markup strings can use it?
> 
> It is the same mechanism, and add-text-replacements! answers
> Werner’s question.

Thanks.  I only did a quick index search for 'replace' in the NR, and
there was no hit.  This is now

  https://gitlab.com/lilypond/lilypond/-/merge_requests/1814


Werner

Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals

[Kieren MacMillan]

Hi all,

> In any case, please submit this to the LSR!

I was *just* going to look at this to see if it could be improved viz-a-viz 
Jean’s suggestion that callbacks using after-line-breaking are often better 
done with grob-transformer. [Yes, I know this is *before*-line-breaking…] If 
so, that should happen before LSR submission, I would think!

Maybe Someone™ can just tell me if it’s worth investigating or not…?

Thanks
Kieren.

Re: Unicode accidentals vs. Markup accidentals, Re: Unicode accidentals vs. Markup accidentals

[Jean Abou Samra]

> Le 16 janv. 2023 à 15:07, Mark Knoop  a écrit :
> 
> 
> At 12:51 on 16 Jan 2023, Werner LEMBERG wrote:
>>> \new Staff {
>>>  \override TextScript.before-line-breaking =
>>>  #(lambda (grob)
>>> (ly:grob-set-property! grob 'text
>>>(markup #:replace
>>>`(("♭" . ,#{ \markup{ \tflat} #})
>>>  ("♯" . ,#{ \markup{ \tsharp} #})
>>>  ("♮" . ,#{ \markup{ \tnatural} #}))
>>>(ly:grob-property grob 'text
>>>  c'1^"B♭"
>>>  c'1^"C♯"
>>>  c'1^"D♮"
>>> }
> 
>> *This* is nice!  It sort-of corresponds to 'active characters' in TeX.
>> Is there a possibility to register this or a similar function globally
>> so that all markup strings can use it?
> 
> How does this differ from the current mechanism using
> add-text-replacements! and replacement-alist?


It is the same mechanism, and add-text-replacements! answers Werner’s question.


> Could these be extended to
> allow the replacement string to include \markup?


Already done by me at some point in the 2.23 series (or the code above wouldn’t 
work).

Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals

[Mark Knoop]

At 12:51 on 16 Jan 2023, Werner LEMBERG wrote:
>> \new Staff {
>>   \override TextScript.before-line-breaking =
>>   #(lambda (grob)
>>  (ly:grob-set-property! grob 'text
>> (markup #:replace
>> `(("♭" . ,#{ \markup{ \tflat} #})
>>   ("♯" . ,#{ \markup{ \tsharp} #})
>>   ("♮" . ,#{ \markup{ \tnatural} #}))
>> (ly:grob-property grob 'text
>>   c'1^"B♭"
>>   c'1^"C♯"
>>   c'1^"D♮"
>> }

> *This* is nice!  It sort-of corresponds to 'active characters' in TeX.
> Is there a possibility to register this or a similar function globally
> so that all markup strings can use it?

How does this differ from the current mechanism using
add-text-replacements! and replacement-alist? Could these be extended to
allow the replacement string to include \markup?

--
Mark Knoop

Re: Unicode accidentals vs. Markup accidentals,Re: Unicode accidentals vs. Markup accidentals

[Werner LEMBERG]

> I quite like this, but incorporating this into my previous code I
> found going down TWO steps to be optically more pleasing.

OK :-)

> \new Staff {
>   \override TextScript.before-line-breaking =
>   #(lambda (grob)
>  (ly:grob-set-property! grob 'text
> (markup #:replace
> `(("♭" . ,#{ \markup{ \tflat} #})
>   ("♯" . ,#{ \markup{ \tsharp} #})
>   ("♮" . ,#{ \markup{ \tnatural} #}))
> (ly:grob-property grob 'text
>   c'1^"B♭"
>   c'1^"C♯"
>   c'1^"D♮"
> }

*This* is nice!  It sort-of corresponds to 'active characters' in TeX.
Is there a possibility to register this or a similar function globally
so that all markup strings can use it?

In any case, please submit this to the LSR!


Werner

Re: Unicode accidentals vs. Markup accidentals

[Kieren MacMillan]

Hi Werner,

> I rather suggest the following
> 
> ```
> F = \markup { \smaller \number ♭ }
> S = \markup { \smaller \number ♯ }
> N = \markup { \smaller \number ♮ }
> 
> \new Staff {
>  c'1^\markup \concat { B \F }
>  c'1^\markup \concat { C \S }
>  c'1^\markup \concat { D \N }
> }
> ```
> 
> If you look more closely, the accidentals produced by `\number` are
> different from the ones produced by `\flat` and friends.  The former
> are mainly for text markup and thus have more reasonable metric
> values, while the latter are suited mainly for non-text markup.

Very nice! Definitely superior.
Kieren.

Re: Unicode accidentals vs. Markup accidentals

[Valentin Petzel]

Hello Werner,

I quite like this, but incorporating this into my previous code I found going 
down TWO steps to be optically more pleasing. This probably because the 
\number accidentals are designed for use with with numbers, which are slightly 
higher than regular text and very bold faced. So in your example the 
accidentals just look quite chunky and big. Going down two font sizes looks 
much more elegant in my opinion:

#(define-markup-command (tsharp layout props) ()
   (interpret-markup layout props (markup #:fontsize -2 #:number "♯")))
#(define-markup-command (tflat layout props) ()
   (interpret-markup layout props (markup #:fontsize -2 #:number "♭")))
#(define-markup-command (tnatural layout props) ()
   (interpret-markup layout props (markup #:fontsize -2 #:number "♮")))

#(define-markup-command (with-sharp layout props m) (markup?)
   (interpret-markup layout props (markup #:concat (m #:tsharp
#(define-markup-command (with-flat layout props m) (markup?)
   (interpret-markup layout props (markup #:concat (m #:tflat
#(define-markup-command (with-natural layout props m) (markup?)
   (interpret-markup layout props (markup #:concat (m #:tnatural

#(define-markup-command (with-sharp-between layout props m1 m2) (markup? 
markup?)
   (interpret-markup layout props (markup #:concat (m1 #:tsharp m2
#(define-markup-command (with-flat-between layout props m1 m2) (markup? markup?)
   (interpret-markup layout props (markup #:concat (m1 #:tflat m2
#(define-markup-command (with-natural-between layout props m1 m2) (markup? 
markup?)
   (interpret-markup layout props (markup #:concat (m1 #:tnatural m2

\markup { A C with a \tsharp can be written \with-sharp-between C ,
  a C with a \tnatural can be written \with-natural C and
  a C with a \tflat can be written \with-flat-between C . }

\new Staff {
  \override TextScript.before-line-breaking =
  #(lambda (grob)
 (ly:grob-set-property! grob 'text
(markup #:replace
`(("♭" . ,#{ \markup{ \tflat} #})
  ("♯" . ,#{ \markup{ \tsharp} #})
  ("♮" . ,#{ \markup{ \tnatural} #}))
(ly:grob-property grob 'text
  c'1^"B♭"
  c'1^"C♯"
  c'1^"D♮"
}

Cheers, Valentin

Am Montag, 16. Jänner 2023, 09:31:54 CET schrieb Werner LEMBERG:
> > Lilypond ships with a text font as well as a music font.  I agree
> > that I suspect that currently Lilypond's text font does not actually
> > define these Unicode music characters, so it falls back on the OS to
> > find them.  Why not just add copies of Emmentaler glyphs to the
> > Lilypond text fonts for characters within the Unicode spec?
> 
> 
> IMHO, there is zero benefit of doing that.  I guess one of the first
> action a slightly more advanced user does is to change the default
> fonts to something else, because the default is not 'sexy' enough to
> most people.  Irrespective of that it would be an additional burden to
> us to maintain such modifications.
> 
> 
> > I also don't think it's unreasonable to suggest that the default
> > typography should look good.
> 
> 
> No question – I think the default *does* look good, as demonstrated in
> my previous e-mail.
> 
> 
> > I hope we can agree that the output on staves 1 & 2 is significantly
> > worse than the output on staff 3 (attached picture if it doesn't
> > display inline for you).
> 
> 
> Yes, but you are using the wrong commands.  Have you actually noticed
> the example I've sent in my last e-mail?
> 
> 
> > Staves 1&2 are Unicode and default markup glyphs as in my original
> > post (compiled on Windows). To get staff 3 the following is
> > required:
> > 
> > \new Staff {
> > 
> > c'1^\markup\concat\vcenter { B \hspace #0.2 \fontsize #-1.5 \flat }
> > c'1^\markup\concat\vcenter { C \hspace #0.1 \fontsize #-2 \sharp }
> > c'1^\markup\concat\vcenter { D \hspace #0.2 \fontsize #-1.5 \natural
> > }
> >   
> >   }
> > 
> > 
> > IMO Staff 3 should be the default output, not something that
> > requires so much tweaking.
> 
> 
> I rather suggest the following
> 
> ```
> F = \markup { \smaller \number ♭ }
> S = \markup { \smaller \number ♯ }
> N = \markup { \smaller \number ♮ }
> 
> \new Staff {
>   c'1^\markup \concat { B \F }
>   c'1^\markup \concat { C \S }
>   c'1^\markup \concat { D \N }
> }
> ```
> 
> If you look more closely, the accidentals produced by `\number` are
> different from the ones produced by `\flat` and friends.  The former
> are mainly for text markup and thus have more reasonable metric
> values, while the latter are suited mainly for non-text markup.
> 
> BTW, the new text accidentals are new in version 2.24.
> 
> 
> Werner



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

Re: Unicode accidentals vs. Markup accidentals

[Valentin Petzel]

Hello Saul,

I do not find this much surprising at all. Yes, Lilypond could do lots of 
automagic, automatically replacing such signs by the respective music font 
version. But it does not and rather gives you (the user) the control and the 
responsibility. But typesetting in Lilypond is neither particularly easy to 
work with nor particularly powerful.  The design choice of having all markups 
be separated by space requires a lot of \concat. This does show that lilypond 
was not mainly conceived as a typesetting program, but as a notation program.

Now, the problem we have here is as already discussed that Lilypond does by 
default use a font that does not provide these glyphs. A simple solution could 
be using a different font. MuseScore provides a font "Edwin", which is a fork 
of the font used by Lilypond with a few added symbols. The team of Dorico does 
provide an OFL font "Academico", which reproduces the same typeface, and 
provides a few added symbols. The downsides of this is that these fonts simply 
use the accidental glyphs from MuseScore’s notation font Leland and Dorico’s 
notation font Bravura. This means they do not optically match the font that 
well and they most certainly do not match Lilypond’s notation glyphs.

If you can live with such a thing, changing the text font to Dorico’s 
Academico will produce quite nice results.

On the other hand to make life easier and code easier to read you may alwas 
define your own markup commands like this:

#(define-markup-command (tsharp layout props) ()
   (interpret-markup layout props (markup #:raise 0.8 #:fontsize -3 #:sharp)))
#(define-markup-command (tflat layout props) ()
   (interpret-markup layout props (markup #:raise 0.4 #:fontsize -1.7 #:flat)))
#(define-markup-command (tnatural layout props) ()
   (interpret-markup layout props (markup #:raise 0.67 #:fontsize -2.5 
#:natural)))

#(define-markup-command (with-sharp layout props m) (markup?)
   (interpret-markup layout props (markup #:concat (m #:hspace 0.15 
#:tsharp
#(define-markup-command (with-flat layout props m) (markup?)
   (interpret-markup layout props (markup #:concat (m #:hspace 0.2 #:tflat
#(define-markup-command (with-natural layout props m) (markup?)
   (interpret-markup layout props (markup #:concat (m #:hspace 0.2 
#:tnatural

#(define-markup-command (with-sharp-between layout props m1 m2) (markup? 
markup?)
   (interpret-markup layout props (markup #:concat (m1 #:hspace 0.15 #:tsharp 
m2
#(define-markup-command (with-flat-between layout props m1 m2) (markup? markup?)
   (interpret-markup layout props (markup #:concat (m1 #:hspace 0.2 #:tflat 
m2
#(define-markup-command (with-natural-between layout props m1 m2) (markup? 
markup?)
   (interpret-markup layout props (markup #:concat (m1 #:hspace 0.2 #:tnatural 
m2

\markup { A C with a \tsharp can be written \with-sharp-between C ,
  a C with a \tnatural can be written \with-natural C and
  a C with a \tflat can be written \with-flat-between C . }


Also while Lilypond will not automatically replace Unicode characters, you can 
tell it to do so manually:

\new Staff {
  \override TextScript.before-line-breaking =
  #(lambda (grob)
 (ly:grob-set-property! grob 'text
(markup #:replace
`(("♭" . ,#{ \markup{\hspace #0.2 \tflat} 
#})
  ("♯" . ,#{ \markup{\hspace #0.15 
\tsharp} #})
  ("♮" . ,#{ \markup{\hspace #0.2 
\tnatural} #}))
(ly:grob-property grob 'text
  c'1^"B♭"
  c'1^"C♯"
  c'1^"D♮"
}

Cheers,
Valentin



Am Montag, 16. Jänner 2023, 07:52:50 CET schrieb Saul Tobin:
> Lilypond ships with a text font as well as a music font. I agree that I
> suspect that currently Lilypond's text font does not actually define these
> Unicode music characters, so it falls back on the OS to find them. Why not
> just add copies of Emmentaler glyphs to the Lilypond text fonts for
> characters within the Unicode spec? That seems like a pretty reasonable
> suggestion to me...
> 
> I also don't think it's unreasonable to suggest that the default typography
> should look good. I hope we can agree that the output on staves 1 & 2 is
> significantly worse than the output on staff 3 (attached picture if it
> doesn't display inline for you).
> [image: image.png]
> Staves 1&2 are Unicode and default markup glyphs as in my original post
> (compiled on Windows). To get staff 3 the following is required:
> 
> \new Staff {
> c'1^\markup\concat\vcenter { B \hspace #0.2 \fontsize #-1.5 \flat }
> c'1^\markup\concat\vcenter { C \hspace #0.1 \fontsize #-2 \sharp }
> c'1^\markup\concat\vcenter { D \hspace #0.2 \fontsize #-1.5 \natural }
>   }
> 
> IMO Staff 3 should be the default output, not something that requires so
> much tweaking.
> 
> On Sun, Jan 15, 2023 at 9:56 PM Werner LEMBERG  wrote:
> > > IMO Lilypond should render musical 

Re: Unicode accidentals vs. Markup accidentals

[Werner LEMBERG]

> Lilypond ships with a text font as well as a music font.  I agree
> that I suspect that currently Lilypond's text font does not actually
> define these Unicode music characters, so it falls back on the OS to
> find them.  Why not just add copies of Emmentaler glyphs to the
> Lilypond text fonts for characters within the Unicode spec?

IMHO, there is zero benefit of doing that.  I guess one of the first
action a slightly more advanced user does is to change the default
fonts to something else, because the default is not 'sexy' enough to
most people.  Irrespective of that it would be an additional burden to
us to maintain such modifications.

> I also don't think it's unreasonable to suggest that the default
> typography should look good.

No question – I think the default *does* look good, as demonstrated in
my previous e-mail.

> I hope we can agree that the output on staves 1 & 2 is significantly
> worse than the output on staff 3 (attached picture if it doesn't
> display inline for you).

Yes, but you are using the wrong commands.  Have you actually noticed
the example I've sent in my last e-mail?

> Staves 1&2 are Unicode and default markup glyphs as in my original
> post (compiled on Windows). To get staff 3 the following is
> required:
> 
> \new Staff {
> c'1^\markup\concat\vcenter { B \hspace #0.2 \fontsize #-1.5 \flat }
> c'1^\markup\concat\vcenter { C \hspace #0.1 \fontsize #-2 \sharp }
> c'1^\markup\concat\vcenter { D \hspace #0.2 \fontsize #-1.5 \natural }
>   }
> 
> IMO Staff 3 should be the default output, not something that
> requires so much tweaking.

I rather suggest the following

```
F = \markup { \smaller \number ♭ }
S = \markup { \smaller \number ♯ }
N = \markup { \smaller \number ♮ }

\new Staff {
  c'1^\markup \concat { B \F }
  c'1^\markup \concat { C \S }
  c'1^\markup \concat { D \N }
}
```

If you look more closely, the accidentals produced by `\number` are
different from the ones produced by `\flat` and friends.  The former
are mainly for text markup and thus have more reasonable metric
values, while the latter are suited mainly for non-text markup.

BTW, the new text accidentals are new in version 2.24.


Werner

Re: Unicode accidentals vs. Markup accidentals

[Saul Tobin]

Lilypond ships with a text font as well as a music font. I agree that I
suspect that currently Lilypond's text font does not actually define these
Unicode music characters, so it falls back on the OS to find them. Why not
just add copies of Emmentaler glyphs to the Lilypond text fonts for
characters within the Unicode spec? That seems like a pretty reasonable
suggestion to me...

I also don't think it's unreasonable to suggest that the default typography
should look good. I hope we can agree that the output on staves 1 & 2 is
significantly worse than the output on staff 3 (attached picture if it
doesn't display inline for you).
[image: image.png]
Staves 1&2 are Unicode and default markup glyphs as in my original post
(compiled on Windows). To get staff 3 the following is required:

\new Staff {
c'1^\markup\concat\vcenter { B \hspace #0.2 \fontsize #-1.5 \flat }
c'1^\markup\concat\vcenter { C \hspace #0.1 \fontsize #-2 \sharp }
c'1^\markup\concat\vcenter { D \hspace #0.2 \fontsize #-1.5 \natural }
  }

IMO Staff 3 should be the default output, not something that requires so
much tweaking.

On Sun, Jan 15, 2023 at 9:56 PM Werner LEMBERG  wrote:

>
> > IMO Lilypond should render musical Unicode characters using the same
> > font as the music itself,
>
> No, it should not.  If you select font 'foo' for text rendering,
> everything should come from that font.  If a certain character is not
> in 'foo', it is the FontConfig library rather than LilyPond that
> selects a fallback font – and it is more or less unpredictable which
> fallback is actually used due to the way how FontConfig works.  If you
> want LilyPond glyphs you have to explicitly select them.
>
> In general, I strongly suggest that you *always* select the correct
> font for text rendering to assure that your document stays portable
> and can be reliably compiled on other systems.
>
> > and the default size/alignment of the glyphs within text markup
> > should not require adjustment to look correct.
>
> How do you want to adjust the size in an automated way?  Just think of
> using Times New Roman together with Courier, as shown in the image –
> what size should the LilyPond glyphs have?  And the default
> positioning is not too bad, as demonstrated in the other image.
>
> ```
> \markup { "foo" \number "♭♯♮" "bar" }
> ```
>
>
> Werner
>

Re: Unicode accidentals vs. Markup accidentals

[Werner LEMBERG]

> IMO Lilypond should render musical Unicode characters using the same
> font as the music itself,

No, it should not.  If you select font 'foo' for text rendering,
everything should come from that font.  If a certain character is not
in 'foo', it is the FontConfig library rather than LilyPond that
selects a fallback font – and it is more or less unpredictable which
fallback is actually used due to the way how FontConfig works.  If you
want LilyPond glyphs you have to explicitly select them.

In general, I strongly suggest that you *always* select the correct
font for text rendering to assure that your document stays portable
and can be reliably compiled on other systems. 

> and the default size/alignment of the glyphs within text markup
> should not require adjustment to look correct.

How do you want to adjust the size in an automated way?  Just think of
using Times New Roman together with Courier, as shown in the image –
what size should the LilyPond glyphs have?  And the default
positioning is not too bad, as demonstrated in the other image.

```
\markup { "foo" \number "♭♯♮" "bar" }
```


Werner

Re: Unicode accidentals vs. Markup accidentals

[Saul Tobin]

IMO Lilypond should render musical Unicode characters using the same font
as the music itself, and the default size/alignment of the glyphs within
text markup should not require adjustment to look correct.

On Sun, Jan 15, 2023 at 4:07 AM William Rehwinkel <
will...@williamrehwinkel.net> wrote:

> Dear Saul,
>
> I don't see why this would be surprising... as you said it's the
> difference of using the unicode symbol from the text font (such as
> unicode symbol https://www.compart.com/en/unicode/U+266D for a flat) for
> an accidental and pasting in the lilypond musical font symbol for that
> accidental. You can prove this by loading a different font either for
> the serif font or musical glyph font. (Sorry for probably using wrong
> terminology here)
>
> In my opinion using the lilypond font accidental in a markup block is
> probably intended for other use cases, such as putting an editorial
> accidental above or below a note instead of in its usual place.
>
> As for how it looks, I suppose that is a matter of taste. But I would
> probably use the unicode accidental symbols if the need for writing an
> accidental in a piece of text came up in the future. You could
> definitely make the text using lilypond accidentals look right by
> changing the font size of either the text or the accidental, it's just a
> matter of the size and alignment.
>
> -William
>
> On 1/15/23 01:05, Saul Tobin wrote:
> > Surprisingly, typing the Unicode characters for accidental symbols does
> > not produce the same font output as using the markup commands:
> >
> > <<
> >\new Staff {
> >  c'1^"B♭"
> >  c'1^"C♯"
> >  c'1^"D♮"
> >}
> >\new Staff {
> >  c'1^\markup { B \flat }
> >  c'1^\markup { C \sharp }
> >  c'1^\markup { D \natural }
> >}
> >  >>
> >
> > And neither looks particularly great IMO.
>
> --
> + -- +
> |William Rehwinkel - Oberlin College and |
> |   Conservatory '24 |
> |  will...@williamrehwinkel.net  |
> | PGP key:   |
> | https://williamrehwinkel.net/static/pubkey.txt |
> + -- +
>

Re: Unicode accidentals vs. Markup accidentals

[William Rehwinkel]

Dear Saul,

I don't see why this would be surprising... as you said it's the 
difference of using the unicode symbol from the text font (such as 
unicode symbol https://www.compart.com/en/unicode/U+266D for a flat) for 
an accidental and pasting in the lilypond musical font symbol for that 
accidental. You can prove this by loading a different font either for 
the serif font or musical glyph font. (Sorry for probably using wrong 
terminology here)


In my opinion using the lilypond font accidental in a markup block is 
probably intended for other use cases, such as putting an editorial 
accidental above or below a note instead of in its usual place.


As for how it looks, I suppose that is a matter of taste. But I would 
probably use the unicode accidental symbols if the need for writing an 
accidental in a piece of text came up in the future. You could 
definitely make the text using lilypond accidentals look right by 
changing the font size of either the text or the accidental, it's just a 
matter of the size and alignment.


-William

On 1/15/23 01:05, Saul Tobin wrote:
Surprisingly, typing the Unicode characters for accidental symbols does 
not produce the same font output as using the markup commands:


<<
   \new Staff {
     c'1^"B♭"
     c'1^"C♯"
     c'1^"D♮"
   }
   \new Staff {
     c'1^\markup { B \flat }
     c'1^\markup { C \sharp }
     c'1^\markup { D \natural }
   }
 >>

And neither looks particularly great IMO.


--
+ -- +
|William Rehwinkel - Oberlin College and |
|   Conservatory '24 |
|  will...@williamrehwinkel.net  |
| PGP key:   |
| https://williamrehwinkel.net/static/pubkey.txt |
+ -- +


OpenPGP_signature
Description: OpenPGP digital signature

Unicode accidentals vs. Markup accidentals

[Saul Tobin]

Surprisingly, typing the Unicode characters for accidental symbols does not
produce the same font output as using the markup commands:

<<
  \new Staff {
c'1^"B♭"
c'1^"C♯"
c'1^"D♮"
  }
  \new Staff {
c'1^\markup { B \flat }
c'1^\markup { C \sharp }
c'1^\markup { D \natural }
  }
>>

And neither looks particularly great IMO.

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

[Leo Correia de Verdier]

That is not another bug, that is because I only redefined the regular barline 
(not the double) to print on the beginning of staves. Add:

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

to the layout block and you’re back. That needs to be done for every kind of 
barline you use. 

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

> 22 nov. 2022 kl. 15:17 skrev 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, 
>  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
>> 
>> 
>> 
>> 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, 
>>  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]

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

[Leo Correia de Verdier]

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
> 
> 
> 
> 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, 
>  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
>
>
>

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

[Leo Correia de Verdier]

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
> 

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: Help with ties and accidentals

[Mark Stephen Mrotek]

Keith,

 

Been there, done that.

You are welcome. 

Continue to play with Lilypond. It shall reward your efforts.

 

Mark

 

From: KEITH LYNN [mailto:klyn...@comcast.net] 
Sent: Saturday, March 26, 2022 7:00 PM
To: Mark Stephen Mrotek ; Lilypond-User Mailing List 

Subject: RE: Help with ties and accidentals

 

Thanks for your help Mark. I think my fundamental problem was I forgot the rule 
that an accidental on a note stays in effect for the whole measure. I really 
appreciate your help. 

On 03/26/2022 9:46 PM Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> > wrote: 

 

 

Keith,

 

See the attached.

 

Mark

 

From: KEITH LYNN [mailto:klyn...@comcast.net] 
Sent: Saturday, March 26, 2022 6:28 PM
To: Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> >; 
Lilypond-User Mailing List mailto:lilypond-user@gnu.org> >
Subject: RE: Help with ties and accidentals

 

Sorry for the mistake on the links 

 

Original - Music <http://69.246.129.36/002.jpg> 

Lilypond Input - Input <http://69.246.129.36/input1.jpg> 

Ouput - Output <http://69.246.129.36/input2.jpg> 

On 03/26/2022 9:12 PM KEITH LYNN mailto:klyn...@comcast.net> > wrote:

 

 

Mark, 

  I'm trying to reproduce the following sheet music

 

Original <http://69.246.129.36/002.jpg>  

 

 I'm using this code to try to produce it 

 

Lilypond file <http://69.246.129.36/002.jpg>  

 

 And it's producing this result 

 

Output <http://69.246.129.36/002.jpg>  

 

 I can't see how to make the accidentals disappear and also to produce the 
two lines connecting the right edge of the beam to the next two notes. 

On 03/26/2022 6:48 PM Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> > wrote:

 

 

Keith,

 

Please provide a minimum working code of what you want.

 

Mark

 

From: KEITH LYNN [mailto:klyn...@comcast.net] 
Sent: Saturday, March 26, 2022 3:22 PM
To: Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> >
Subject: RE: Help with ties and accidentals

 

Thanks Mark. Is there a way to prevent the natural symbol from being produced? 

On 03/26/2022 6:03 PM Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> > wrote:

 

 

Keith,

 

Ties ( ~ ) are only between notes of the same pitch.

Might you want you want a slur, i.e.,  (  )?

 

Mark

 

From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] 
On Behalf Of KEITH LYNN
Sent: Saturda)y, March 26, 2022 2:53 PM
To: lilypond-user@gnu.org <mailto:lilypond-user@gnu.org> 
Subject: Help with ties and accidentals

 

I am having trouble trying to produce a tie between a flat note  and a non flat 
note of the same pitch. 

 

For example, I want to tie a bes to a b, but instead of producing the tie 
symbol, it places a natural symbol in front of the second note.

 

How do I stop that? Thanks.

RE: Help with ties and accidentals

[KEITH LYNN]

Thanks for your help Mark. I think my fundamental problem was I forgot the rule 
that an accidental on a note stays in effect for the whole measure. I really 
appreciate your help.

> On 03/26/2022 9:46 PM Mark Stephen Mrotek  wrote:
> 
> 
> 
> Keith,
> 
>  
> 
> See the attached.
> 
>  
> 
> Mark
> 
>  
> 
> From: KEITH LYNN [mailto:klyn...@comcast.net]
> Sent: Saturday, March 26, 2022 6:28 PM
> To: Mark Stephen Mrotek ; Lilypond-User Mailing 
> List 
> Subject: RE: Help with ties and accidentals
> 
> 
> Sorry for the mistake on the links
> 
>  
> 
> Original - Music http://69.246.129.36/002.jpg
> 
> Lilypond Input - Input http://69.246.129.36/input1.jpg
> 
> Ouput - Output http://69.246.129.36/input2.jpg
> 
> > > 
> > On 03/26/2022 9:12 PM KEITH LYNN  > mailto:klyn...@comcast.net > wrote:
> > 
> > 
> > 
> > Mark,
> > 
> >   I'm trying to reproduce the following sheet music
> > 
> >  
> > 
> > Original http://69.246.129.36/002.jpg
> > 
> >  
> > 
> >  I'm using this code to try to produce it
> > 
> >  
> > 
> > Lilypond file http://69.246.129.36/002.jpg
> > 
> >  
> > 
> >  And it's producing this result
> > 
> >  
> > 
> > Output http://69.246.129.36/002.jpg
> > 
> >  
> > 
> >  I can't see how to make the accidentals disappear and also to 
> > produce the two lines connecting the right edge of the beam to the next two 
> > notes.
> > 
> > > > > 
> > > On 03/26/2022 6:48 PM Mark Stephen Mrotek 
> > > mailto:carsonm...@ca.rr.com > wrote:
> > > 
> > > 
> > > 
> > > Keith,
> > > 
> > >      
> > > 
> > > Please provide a minimum working code of what you want.
> > > 
> > >  
> > > 
> > > Mark
> > > 
> > >  
> > > 
> > > From: KEITH LYNN [mailto:klyn...@comcast.net]
> > > Sent: Saturday, March 26, 2022 3:22 PM
> > > To: Mark Stephen Mrotek  > > mailto:carsonm...@ca.rr.com >
> > > Subject: RE: Help with ties and accidentals
> > > 
> > > 
> > > Thanks Mark. Is there a way to prevent the natural symbol 
> > > from being produced?
> > > 
> > > > > > > 
> > > > On 03/26/2022 6:03 PM Mark Stephen Mrotek 
> > > > mailto:carsonm...@ca.rr.com > wrote:
> > > > 
> > > > 
> > > > 
> > > > Keith,
> > > > 
> > > >  
> > > > 
> > > > Ties ( ~ ) are only between notes of the same pitch.
> > > > 
> > > > Might you want you want a slur, i.e.,  (  )?
> > > > 
> > > >  
> > > > 
> > > > Mark
> > > > 
> > > >  
> > > > 
> > > > From: lilypond-user 
> > > > [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf 
> > > > Of KEITH LYNN
> > > > Sent: Saturda)y, March 26, 2022 2:53 PM
> > > > To: lilypond-user@gnu.org mailto:lilypond-user@gnu.org
> > > > Subject: Help with ties and accidentals
> > > > 
> > > > 
> > > > I am having trouble trying to produce a tie between a 
> > > > flat note  and a non flat note of the same pitch.
> > > > 
> > > >  
> > > > 
> > > > For example, I want to tie a bes to a b, but instead of 
> > > > producing the tie symbol, it places a natural symbol in front of the 
> > > > second note.
> > > > 
> > > >  
> > > > 
> > > > How do I stop that? Thanks.
> > > > 
> > > > > > > 
> > > > > 
> > > 

RE: Help with ties and accidentals

[Mark Stephen Mrotek]

Keith,

 

See the attached.

 

Mark

 

From: KEITH LYNN [mailto:klyn...@comcast.net] 
Sent: Saturday, March 26, 2022 6:28 PM
To: Mark Stephen Mrotek ; Lilypond-User Mailing List 

Subject: RE: Help with ties and accidentals

 

Sorry for the mistake on the links 

 

Original - Music <http://69.246.129.36/002.jpg> 

Lilypond Input - Input <http://69.246.129.36/input1.jpg> 

Ouput - Output <http://69.246.129.36/input2.jpg> 

On 03/26/2022 9:12 PM KEITH LYNN mailto:klyn...@comcast.net> > wrote: 

 

 

Mark, 

  I'm trying to reproduce the following sheet music

 

Original <http://69.246.129.36/002.jpg>  

 

 I'm using this code to try to produce it 

 

Lilypond file <http://69.246.129.36/002.jpg>  

 

 And it's producing this result 

 

Output <http://69.246.129.36/002.jpg>  

 

 I can't see how to make the accidentals disappear and also to produce the 
two lines connecting the right edge of the beam to the next two notes. 

On 03/26/2022 6:48 PM Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> > wrote: 

 

 

Keith,

 

Please provide a minimum working code of what you want.

 

Mark

 

From: KEITH LYNN [mailto:klyn...@comcast.net] 
Sent: Saturday, March 26, 2022 3:22 PM
To: Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> >
Subject: RE: Help with ties and accidentals

 

Thanks Mark. Is there a way to prevent the natural symbol from being produced? 

On 03/26/2022 6:03 PM Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> > wrote:

 

 

Keith,

 

Ties ( ~ ) are only between notes of the same pitch.

Might you want you want a slur, i.e.,  (  )?

 

Mark

 

From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] 
On Behalf Of KEITH LYNN
Sent: Saturda)y, March 26, 2022 2:53 PM
To: lilypond-user@gnu.org <mailto:lilypond-user@gnu.org> 
Subject: Help with ties and accidentals

 

I am having trouble trying to produce a tie between a flat note  and a non flat 
note of the same pitch. 

 

For example, I want to tie a bes to a b, but instead of producing the tie 
symbol, it places a natural symbol in front of the second note.

 

How do I stop that? Thanks.

\version "2.22.1"

\relative c'' {
  <<{ c8 ges16 f ges f ges f |
  ges} \\
{8  4 |
 8}>>
}

RE: Help with ties and accidentals

[Mark Stephen Mrotek]

Keith,

 

Piece is in C

Every time you want a bes you must write bes.

The same applies with the ges.

Give me a moment to do a code for you.

 

Mark

 

From: KEITH LYNN [mailto:klyn...@comcast.net] 
Sent: Saturday, March 26, 2022 6:28 PM
To: Mark Stephen Mrotek ; Lilypond-User Mailing List 

Subject: RE: Help with ties and accidentals

 

Sorry for the mistake on the links 

 

Original - Music <http://69.246.129.36/002.jpg> 

Lilypond Input - Input <http://69.246.129.36/input1.jpg> 

Ouput - Output <http://69.246.129.36/input2.jpg> 

On 03/26/2022 9:12 PM KEITH LYNN mailto:klyn...@comcast.net> > wrote: 

 

 

Mark, 

  I'm trying to reproduce the following sheet music

 

Original <http://69.246.129.36/002.jpg>  

 

 I'm using this code to try to produce it 

 

Lilypond file <http://69.246.129.36/002.jpg>  

 

 And it's producing this result 

 

Output <http://69.246.129.36/002.jpg>  

 

 I can't see how to make the accidentals disappear and also to produce the 
two lines connecting the right edge of the beam to the next two notes. 

On 03/26/2022 6:48 PM Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> > wrote: 

 

 

Keith,

 

Please provide a minimum working code of what you want.

 

Mark

 

From: KEITH LYNN [mailto:klyn...@comcast.net] 
Sent: Saturday, March 26, 2022 3:22 PM
To: Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> >
Subject: RE: Help with ties and accidentals

 

Thanks Mark. Is there a way to prevent the natural symbol from being produced? 

On 03/26/2022 6:03 PM Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> > wrote:

 

 

Keith,

 

Ties ( ~ ) are only between notes of the same pitch.

Might you want you want a slur, i.e.,  (  )?

 

Mark

 

From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] 
On Behalf Of KEITH LYNN
Sent: Saturda)y, March 26, 2022 2:53 PM
To: lilypond-user@gnu.org <mailto:lilypond-user@gnu.org> 
Subject: Help with ties and accidentals

 

I am having trouble trying to produce a tie between a flat note  and a non flat 
note of the same pitch. 

 

For example, I want to tie a bes to a b, but instead of producing the tie 
symbol, it places a natural symbol in front of the second note.

 

How do I stop that? Thanks.

RE: Help with ties and accidentals

[Mark Stephen Mrotek]

Keith,

 

I do not see any difference between Original and Output.
Please check for accuracy.

Flash: In what key is this coded?

 

Mark

 

From: KEITH LYNN [mailto:klyn...@comcast.net] 
Sent: Saturday, March 26, 2022 6:13 PM
To: Mark Stephen Mrotek ; Lilypond-User Mailing List 

Subject: RE: Help with ties and accidentals

 

Mark, 

  I'm trying to reproduce the following sheet music

 

Original <http://69.246.129.36/002.jpg>  

 

 I'm using this code to try to produce it 

 

Lilypond file <http://69.246.129.36/002.jpg>  

 

 And it's producing this result 

 

Output <http://69.246.129.36/002.jpg>  

 

 I can't see how to make the accidentals disappear and also to produce the 
two lines connecting the right edge of the beam to the next two notes. 

On 03/26/2022 6:48 PM Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> > wrote: 

 

 

Keith,

 

Please provide a minimum working code of what you want.

 

Mark

 

From: KEITH LYNN [mailto:klyn...@comcast.net] 
Sent: Saturday, March 26, 2022 3:22 PM
To: Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> >
Subject: RE: Help with ties and accidentals

 

Thanks Mark. Is there a way to prevent the natural symbol from being produced? 

On 03/26/2022 6:03 PM Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> > wrote:

 

 

Keith,

 

Ties ( ~ ) are only between notes of the same pitch.

Might you want you want a slur, i.e.,  (  )?

 

Mark

 

From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] 
On Behalf Of KEITH LYNN
Sent: Saturda)y, March 26, 2022 2:53 PM
To: lilypond-user@gnu.org <mailto:lilypond-user@gnu.org> 
Subject: Help with ties and accidentals

 

I am having trouble trying to produce a tie between a flat note  and a non flat 
note of the same pitch. 

 

For example, I want to tie a bes to a b, but instead of producing the tie 
symbol, it places a natural symbol in front of the second note.

 

How do I stop that? Thanks.

RE: Help with ties and accidentals

[KEITH LYNN]

Sorry for the mistake on the links

Original - Music http://69.246.129.36/002.jpg
Lilypond Input - Input http://69.246.129.36/input1.jpg
Ouput - Output http://69.246.129.36/input2.jpg

> On 03/26/2022 9:12 PM KEITH LYNN  wrote:
> 
> 
> Mark,
>   I'm trying to reproduce the following sheet music
> 
> Original http://69.246.129.36/002.jpg
> 
>  I'm using this code to try to produce it
> 
> Lilypond file http://69.246.129.36/002.jpg
> 
>  And it's producing this result
> 
> Output http://69.246.129.36/002.jpg
> 
>  I can't see how to make the accidentals disappear and also to 
> produce the two lines connecting the right edge of the beam to the next two 
> notes.
> 
> > > On 03/26/2022 6:48 PM Mark Stephen Mrotek 
>  wrote:
> > 
> > 
> > 
> > Keith,
> > 
> >  
> > 
> > Please provide a minimum working code of what you want.
> > 
> >  
> > 
> > Mark
> > 
> >  
> > 
> > From: KEITH LYNN [mailto:klyn...@comcast.net]
> > Sent: Saturday, March 26, 2022 3:22 PM
> > To: Mark Stephen Mrotek 
> > Subject: RE: Help with ties and accidentals
> > 
> > 
> > Thanks Mark. Is there a way to prevent the natural symbol from 
> > being produced?
> > 
> > > > > 
> > > On 03/26/2022 6:03 PM Mark Stephen Mrotek 
> > > mailto:carsonm...@ca.rr.com > wrote:
> > > 
> > > 
> > > 
> > > Keith,
> > > 
> > >  
> > > 
> > > Ties ( ~ ) are only between notes of the same pitch.
> > > 
> > > Might you want you want a slur, i.e.,  (  )?
> > > 
> > >  
> > > 
> > > Mark
> > > 
> > >  
> > > 
> > > From: lilypond-user 
> > > [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf Of 
> > > KEITH LYNN
> > > Sent: Saturda)y, March 26, 2022 2:53 PM
> > > To: lilypond-user@gnu.org mailto:lilypond-user@gnu.org
> > > Subject: Help with ties and accidentals
> > > 
> > > 
> > > I am having trouble trying to produce a tie between a flat 
> > > note  and a non flat note of the same pitch.
> > > 
> > >  
> > > 
> > > For example, I want to tie a bes to a b, but instead of 
> > > producing the tie symbol, it places a natural symbol in front of the 
> > > second note.
> > > 
> > >  
> > > 
> > > How do I stop that? Thanks.
> > > 
> > > > > 
> > > 

Re: Help with ties and accidentals

[David Kastrup]

KEITH LYNN  writes:

> Mark,
> I'm trying to reproduce the following sheet music
>
> Original http://69.246.129.36/002.jpg
>
> I'm using this code to try to produce it
>
> Lilypond file http://69.246.129.36/002.jpg
>
> And it's producing this result
>
> Output http://69.246.129.36/002.jpg
>

That's the same link 3 times in a row, not really helpful.  However, if
we assume that this is the original, it is clear that you are making the
mistake I already told you about: there is not a single b in those
measures: all of them are bes.  Your input notenames apparently try to
tell LilyPond how the notes are to be _printed_ rather than how they are
to _sound_.

This is not how LilyPond's pitch entry works.  Please read the Learning
Manual section about pitches in
.

-- 
David Kastrup

RE: Help with ties and accidentals

[KEITH LYNN]

Mark,
I'm trying to reproduce the following sheet music

Original http://69.246.129.36/002.jpg

I'm using this code to try to produce it

Lilypond file http://69.246.129.36/002.jpg

And it's producing this result

Output http://69.246.129.36/002.jpg

I can't see how to make the accidentals disappear and also to produce the two 
lines connecting the right edge of the beam to the next two notes.

> On 03/26/2022 6:48 PM Mark Stephen Mrotek  wrote:
> 
> 
> 
> Keith,
> 
>  
> 
> Please provide a minimum working code of what you want.
> 
>  
> 
> Mark
> 
>  
> 
> From: KEITH LYNN [mailto:klyn...@comcast.net]
> Sent: Saturday, March 26, 2022 3:22 PM
>     To: Mark Stephen Mrotek 
> Subject: RE: Help with ties and accidentals
> 
> 
> Thanks Mark. Is there a way to prevent the natural symbol from being 
> produced?
> 
> > > 
> > On 03/26/2022 6:03 PM Mark Stephen Mrotek  > mailto:carsonm...@ca.rr.com > wrote:
> > 
> > 
> > 
> > Keith,
> > 
> >  
> > 
> > Ties ( ~ ) are only between notes of the same pitch.
> > 
> > Might you want you want a slur, i.e.,  (  )?
> > 
> >  
> > 
> > Mark
> > 
> >  
> > 
> > From: lilypond-user 
> > [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf Of 
> > KEITH LYNN
> > Sent: Saturda)y, March 26, 2022 2:53 PM
> > To: lilypond-user@gnu.org mailto:lilypond-user@gnu.org
> > Subject: Help with ties and accidentals
> > 
> > 
> > I am having trouble trying to produce a tie between a flat note  
> > and a non flat note of the same pitch.
> > 
> >  
> > 
> > For example, I want to tie a bes to a b, but instead of producing 
> > the tie symbol, it places a natural symbol in front of the second note.
> > 
> >  
> > 
> > How do I stop that? Thanks.
> > 
> > > 

Re: Help with ties and accidentals

[David Kastrup]

KEITH LYNN  writes:

> I am having trouble trying to produce a tie between a flat note and a
> non flat note of the same pitch.

That sounds like a misunderstanding of what "tie" means.  Ties are used
for connecting several notes of the same pitch into a single note of the
combined duration.  However, your problem might be a different
terminology/concept problem:

> For example, I want to tie a bes to a b, but instead of producing the
> tie symbol, it places a natural symbol in front of the second note.
>
> How do I stop that? Thanks.

This sounds like you are confused about LilyPond's input note language.
Notes of equal pitch have equal input note names.

A bes is not something at the notation height of b with a flat before
it.  A bes is something that sounds a half note lower than a natural b.
Regardless of how it gets printed.

So you probably want to write bes ~ bes here.  You might want to read
the LilyPond tutorial: it is intended to be comparatively compact
sequential reading introducing the main LilyPond concepts and get you
started.

-- 
David Kastrup

RE: Help with ties and accidentals

[Mark Stephen Mrotek]

Keith,

 

Please provide a minimum working code of what you want.

 

Mark

 

From: KEITH LYNN [mailto:klyn...@comcast.net] 
Sent: Saturday, March 26, 2022 3:22 PM
To: Mark Stephen Mrotek 
Subject: RE: Help with ties and accidentals

 

Thanks Mark. Is there a way to prevent the natural symbol from being produced? 

On 03/26/2022 6:03 PM Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> > wrote: 

 

 

Keith,

 

Ties ( ~ ) are only between notes of the same pitch.

Might you want you want a slur, i.e.,  (  )?

 

Mark

 

From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] 
On Behalf Of KEITH LYNN
Sent: Saturda)y, March 26, 2022 2:53 PM
To: lilypond-user@gnu.org <mailto:lilypond-user@gnu.org> 
Subject: Help with ties and accidentals

 

I am having trouble trying to produce a tie between a flat note  and a non flat 
note of the same pitch. 

 

For example, I want to tie a bes to a b, but instead of producing the tie 
symbol, it places a natural symbol in front of the second note.

 

How do I stop that? Thanks.

Help with ties and accidentals

[KEITH LYNN]

I am having trouble trying to produce a tie between a flat note  and a non flat 
note of the same pitch.

For example, I want to tie a bes to a b, but instead of producing the tie 
symbol, it places a natural symbol in front of the second note.

How do I stop that? Thanks.

Re: Engraving chords with the same note twice, but different accidentals

[Hans Åberg]

> On 3 Feb 2022, at 19:04, Knute Snortum  wrote:
> 
> On Thu, Feb 3, 2022 at 9:32 AM Leo Correia de Verdier
>  wrote:
>> 
>> On Thu, Feb 3, 2022, 11:51 AM Kieren MacMillan 
>>  wrote:
>>> 
>>> Hi all,
>>> 
 Speaking as a keyboard player (and lilypond novice) I would recommend 
 re-spelling the a flat as a g sharp! Sometimes, theory has to take a 
 backseat to readability.
>>> 
>>> If theoretical correctness (or, say, accuracy to a previous source) isn't a 
>>> requirement, then I agree with Charlie: this is a moment in which, as a 
>>> keyboard player, I'd much rather see two different notes [by pitch name].
>>> 
>>> Otherwise, I'd say the split-stem convention is [perhaps 
>>> counterintuitively?!] more readable for me. If you want to do this in 
>>> Lilypond, I'm pretty sure Harm has solved this particular issue (see e.g., 
>>> https://archiv.lilypondforum.de/index.php/topic,1176.msg6932.html#msg6932).
> 
> Ok, the first attachment is using Harm's splayed stem chord function.
> Better?  Worse?
> 
> Respelling the chord using a "gs" for the "af" is a possibility, but
> what about respelling the "a" as a "bff"?  The second attachment shows
> how that would look.

This seems to be the theoretically correct, as you have a number of persistent 
A♭, and above a B♭ which is lowered chromatically, so it becomes a B𝄫 then.

One example of a playability concern is for an orchestral harp, which can set 
pedal flats and sharps as in a key signature, but can not change the pedals 
fast enough during performance. Then it must be a G♯ and an A; letting the 
harpist do the respelling costs money (according to Blatter).

Re: Engraving chords with the same note twice, but different accidentals

[Kira Garvie]

I’m personally not a fan of the splayed stem notation - I’ve never seen it
before so it makes me go “what?” before I get to the notes. It also sort of
looks like the a natural should be played first because it’s stem goes down
to the beam?  I would rather have the b-double flat notation - then the
motion b-flat, b-double flat, back to b-flat is clear, and a g-sharp in the
middle of flats would make my brain do a double take… I think that’s
clearer than the a-flat and natural next to each other, and respects the
spelling. It makes it clear it’s just the top voice of each chord that’s
moving.

On Thu, Feb 3, 2022 at 1:37 PM Knute Snortum  wrote:

> On Thu, Feb 3, 2022 at 9:32 AM Leo Correia de Verdier
>  wrote:
> >
> > I differ on that. For me, (and with the perspective of only this
> measure) both the option of respelling the a flat in only that chord (looks
> like the repeated a flat moves) and respelling the a flats in the whole
> measure (and having to read the second between a flat and b flat as a
> diminished third) are more awkward than reading the augmented unison. I
> slightly prefer the notation with both heads on the same stem, but find
> them both quite readable.
> >
> > 3 feb. 2022 kl. 18:13 skrev David M. Boothe, CAS <
> david.booth...@gmail.com>:
> >
> > 
> > I also would prefer to see a G#. However between the two examples, I
> think the first is slightly more readable.
> >
> > That said, what are the subsequent A's supposed to be - flat or natural?
> As written, I would play them as naturals in the first example, but flats
> in the second example. Were I engraving this, I would put an explicit
> accidental, whether flat or natural on the fourth A, as well.
> >
> >
> > dB
> >
> > On Thu, Feb 3, 2022, 11:51 AM Kieren MacMillan <
> kieren_macmil...@sympatico.ca> wrote:
> >>
> >> Hi all,
> >>
> >> > Speaking as a keyboard player (and lilypond novice) I would recommend
> re-spelling the a flat as a g sharp! Sometimes, theory has to take a
> backseat to readability.
> >>
> >> If theoretical correctness (or, say, accuracy to a previous source)
> isn't a requirement, then I agree with Charlie: this is a moment in which,
> as a keyboard player, I'd much rather see two different notes [by pitch
> name].
> >>
> >> Otherwise, I'd say the split-stem convention is [perhaps
> counterintuitively?!] more readable for me. If you want to do this in
> Lilypond, I'm pretty sure Harm has solved this particular issue (see e.g.,
> https://archiv.lilypondforum.de/index.php/topic,1176.msg6932.html#msg6932
> ).
>
> Ok, the first attachment is using Harm's splayed stem chord function.
> Better?  Worse?
>
> Respelling the chord using a "gs" for the "af" is a possibility, but
> what about respelling the "a" as a "bff"?  The second attachment shows
> how that would look.
>
> --
> Knute Snortum
>

Re: Engraving chords with the same note twice, but different accidentals

[Knute Snortum]

On Thu, Feb 3, 2022 at 9:32 AM Leo Correia de Verdier
 wrote:
>
> I differ on that. For me, (and with the perspective of only this measure) 
> both the option of respelling the a flat in only that chord (looks like the 
> repeated a flat moves) and respelling the a flats in the whole measure (and 
> having to read the second between a flat and b flat as a diminished third) 
> are more awkward than reading the augmented unison. I slightly prefer the 
> notation with both heads on the same stem, but find them both quite readable.
>
> 3 feb. 2022 kl. 18:13 skrev David M. Boothe, CAS :
>
> 
> I also would prefer to see a G#. However between the two examples, I think 
> the first is slightly more readable.
>
> That said, what are the subsequent A's supposed to be - flat or natural? As 
> written, I would play them as naturals in the first example, but flats in the 
> second example. Were I engraving this, I would put an explicit accidental, 
> whether flat or natural on the fourth A, as well.
>
>
> dB
>
> On Thu, Feb 3, 2022, 11:51 AM Kieren MacMillan 
>  wrote:
>>
>> Hi all,
>>
>> > Speaking as a keyboard player (and lilypond novice) I would recommend 
>> > re-spelling the a flat as a g sharp! Sometimes, theory has to take a 
>> > backseat to readability.
>>
>> If theoretical correctness (or, say, accuracy to a previous source) isn't a 
>> requirement, then I agree with Charlie: this is a moment in which, as a 
>> keyboard player, I'd much rather see two different notes [by pitch name].
>>
>> Otherwise, I'd say the split-stem convention is [perhaps 
>> counterintuitively?!] more readable for me. If you want to do this in 
>> Lilypond, I'm pretty sure Harm has solved this particular issue (see e.g., 
>> https://archiv.lilypondforum.de/index.php/topic,1176.msg6932.html#msg6932).

Ok, the first attachment is using Harm's splayed stem chord function.
Better?  Worse?

Respelling the chord using a "gs" for the "af" is a possibility, but
what about respelling the "a" as a "bff"?  The second attachment shows
how that would look.

--
Knute Snortum

Re: Engraving chords with the same note twice, but different accidentals

[Leo Correia de Verdier]

I differ on that. For me, (and with the perspective of only this measure) both 
the option of respelling the a flat in only that chord (looks like the repeated 
a flat moves) and respelling the a flats in the whole measure (and having to 
read the second between a flat and b flat as a diminished third) are more 
awkward than reading the augmented unison. I slightly prefer the notation with 
both heads on the same stem, but find them both quite readable. 

> 3 feb. 2022 kl. 18:13 skrev David M. Boothe, CAS :
> 
> 
> I also would prefer to see a G#. However between the two examples, I think 
> the first is slightly more readable.
> 
> That said, what are the subsequent A's supposed to be - flat or natural? As 
> written, I would play them as naturals in the first example, but flats in the 
> second example. Were I engraving this, I would put an explicit accidental, 
> whether flat or natural on the fourth A, as well.
> 
> 
> dB
> 
>> On Thu, Feb 3, 2022, 11:51 AM Kieren MacMillan 
>>  wrote:
>> Hi all,
>> 
>> > Speaking as a keyboard player (and lilypond novice) I would recommend 
>> > re-spelling the a flat as a g sharp! Sometimes, theory has to take a 
>> > backseat to readability.
>> 
>> If theoretical correctness (or, say, accuracy to a previous source) isn't a 
>> requirement, then I agree with Charlie: this is a moment in which, as a 
>> keyboard player, I'd much rather see two different notes [by pitch name].
>> 
>> Otherwise, I'd say the split-stem convention is [perhaps 
>> counterintuitively?!] more readable for me. If you want to do this in 
>> Lilypond, I'm pretty sure Harm has solved this particular issue (see e.g., 
>> https://archiv.lilypondforum.de/index.php/topic,1176.msg6932.html#msg6932).
>> 
>> Cheers,
>> Kieren.
> 
> dB

Re: Engraving chords with the same note twice, but different accidentals

[David M. Boothe, CAS]

I also would prefer to see a G#. However between the two examples, I think
the first is slightly more readable.

That said, what are the subsequent A's supposed to be - flat or natural? As
written, I would play them as naturals in the first example, but flats in
the second example. Were I engraving this, I would put an explicit
accidental, whether flat or natural on the fourth A, as well.


dB

On Thu, Feb 3, 2022, 11:51 AM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi all,
>
> > Speaking as a keyboard player (and lilypond novice) I would recommend
> re-spelling the a flat as a g sharp! Sometimes, theory has to take a
> backseat to readability.
>
> If theoretical correctness (or, say, accuracy to a previous source) isn't
> a requirement, then I agree with Charlie: this is a moment in which, as a
> keyboard player, I'd much rather see two different notes [by pitch name].
>
> Otherwise, I'd say the split-stem convention is [perhaps
> counterintuitively?!] more readable for me. If you want to do this in
> Lilypond, I'm pretty sure Harm has solved this particular issue (see e.g.,
> https://archiv.lilypondforum.de/index.php/topic,1176.msg6932.html#msg6932
> ).
>
> Cheers,
> Kieren.
>
dB

Re: Engraving chords with the same note twice, but different accidentals

[Kieren MacMillan]

Hi all,

> Speaking as a keyboard player (and lilypond novice) I would recommend 
> re-spelling the a flat as a g sharp! Sometimes, theory has to take a backseat 
> to readability.

If theoretical correctness (or, say, accuracy to a previous source) isn't a 
requirement, then I agree with Charlie: this is a moment in which, as a 
keyboard player, I'd much rather see two different notes [by pitch name].

Otherwise, I'd say the split-stem convention is [perhaps counterintuitively?!] 
more readable for me. If you want to do this in Lilypond, I'm pretty sure Harm 
has solved this particular issue (see e.g., 
https://archiv.lilypondforum.de/index.php/topic,1176.msg6932.html#msg6932).

Cheers,
Kieren.

Re: Engraving chords with the same note twice, but different accidentals

[Charlie Volow]

Hi Knute,

Speaking as a keyboard player (and lilypond novice) I would recommend
re-spelling the a flat as a g sharp! Sometimes, theory has to take a
backseat to readability. If the a natural is supposed to sound before the a
flat, I might write that one as a grace note to an arpeggiated dyad. That
said, I’ll let someone else give an answer that more specifically answers
what you’re hoping to achieve :)

Best,
Charlie

On Thu, Feb 3, 2022 at 10:14 Knute Snortum  wrote:

> Hi everyone,
>
> I've run into a situation where I need to engrave a chord that has the
> same note twice, but with different accidentals.  Like this (third
> chord):
>
> %%%
> \version "2.22.1"
> \language "english"
>
> \relative {
>   \key ef \major
>   \time 3/4
>   8-.\arpeggio \arpeggio( \arpeggio
> \arpeggio \arpeggio \arpeggio) |
> }
> %%%
>
> I have a screenshot of the "default" way that LilyPond engraves this
> attached ("default" in the sense that I only placed a bang after the
> af).  Keyboard players: would you be able to sight read this quickly?
> Is there a different way that would be better, like the second
> attachment?
>
> To get that "y-stem" in LP, the snippets say to do this:
>
> %%%
> \version "2.22.1"
>
> fixA = {
>   \once \override Stem.length = #11
> }
>
> fixB = {
>   \once \override NoteHead.X-offset = #1.7
>   \once \override Stem.length = #7
>   \once \override Stem.rotation = #'(45 0 0)
>   \once \override Stem.extra-offset = #'(-0.1 . -0.2)
>   \once \override Flag.style = #'no-flag
>   \once \override Accidental.extra-offset = #'(4 . -.1)
> }
>
> \relative c' {
>   << { \fixA 8 } \\ { \voiceThree \fixB dis } >> s
> }
> %%%
>
> But my problem with that is I can't get the beam to "attach" to the
> notes in other voices.
>
> To sum up: a) what's the best way to engrave this kind of chord, and
> b) how do I do it?  I appreciate any feedback you can give me.
>
> --
> Knute Snortum
>

Engraving chords with the same note twice, but different accidentals

[Knute Snortum]

Hi everyone,

I've run into a situation where I need to engrave a chord that has the
same note twice, but with different accidentals.  Like this (third
chord):

%%%
\version "2.22.1"
\language "english"

\relative {
  \key ef \major
  \time 3/4
  8-.\arpeggio \arpeggio( \arpeggio
\arpeggio \arpeggio \arpeggio) |
}
%%%

I have a screenshot of the "default" way that LilyPond engraves this
attached ("default" in the sense that I only placed a bang after the
af).  Keyboard players: would you be able to sight read this quickly?
Is there a different way that would be better, like the second
attachment?

To get that "y-stem" in LP, the snippets say to do this:

%%%
\version "2.22.1"

fixA = {
  \once \override Stem.length = #11
}

fixB = {
  \once \override NoteHead.X-offset = #1.7
  \once \override Stem.length = #7
  \once \override Stem.rotation = #'(45 0 0)
  \once \override Stem.extra-offset = #'(-0.1 . -0.2)
  \once \override Flag.style = #'no-flag
  \once \override Accidental.extra-offset = #'(4 . -.1)
}

\relative c' {
  << { \fixA 8 } \\ { \voiceThree \fixB dis } >> s
}
%%%

But my problem with that is I can't get the beam to "attach" to the
notes in other voices.

To sum up: a) what's the best way to engrave this kind of chord, and
b) how do I do it?  I appreciate any feedback you can give me.

--
Knute Snortum

Re: Persian accidentals (koron and sori)

[Carl Sorensen]

These look lovely to me, but I'm not a Persian music expert.

Carl



 

Re: Persian accidentals (koron and sori)

[Hans Åberg]

> On 6 Dec 2021, at 15:49, Werner LEMBERG  wrote:
> 
>>>> https://w3c.github.io/smufl/latest/tables/persian-accidentals.html
>>> 
>>> Yes, and it is soo ugly.
>> 
>> It is best consulting some with traditional Persian sheet music.
>> But the few ones I have seen tend to be hand drawn, not of very high
>> quality, but similar.
>> 
>> The accidentals were designed by Ali-Naqi Vaziri, and became popular
>> for use in Persian sheet music.
>> 
>> https://en.wikipedia.org/wiki/Ali-Naqi_Vaziri
> 
> I know, thanks.  Here you can find some glyph examples
> 
>  https://corp.unicode.org/~roozbeh/sori-koron.pdf

Your design is similar to the first scanned example, so perhaps it is OK to 
sync them with the standard accidentals then.

Perhaps Adam Good has something to say (CC-ed).

Re: Persian accidentals (koron and sori)

[Werner LEMBERG]

> One comment: When looking at Fig. 11 in your PDF, two suggestions
> came to my mind.  The handwritten accidentials show some less sharp
> edges because the ink is flowing in the inner angles of the glyph.
> As you already take the liberty to match the style of classical
> accidentials, how about avoiding some sharp inner angles by
> 
> 1. filling the tiny white triangle in the sharp-like glyph (I am less
>convinced)

I won't do that – I trust that it happens automatically :-)

> 2. making the right inner angle round (looks good to me)

Mhmm, I don't like this, especially if the koron is positioned between
staff lines.  Additionally, Emmentaler doesn't use rounded corners in
the inside of glyphs in general.

However, I'm going to redesign this glyph soon to make it blend even
better with Emmentaler.

> I have two images attached where the additinal ink is painted in red
> and in black.

Thanks.  By the way, here is a link that shows the two new glyphs at
all available Emmentaler sizes:

  
https://gitlab.com/lilypond/lilypond/uploads/b40d4d586ddb994f91be7c650d808833/iranian.pdf


Werner

Re: Persian accidentals (koron and sori)

[Noeck]

Dear Werner,

I am all for it and know nothing about Persian music.

One comment: When looking at Fig. 11 in your PDF, two suggestions came
to my mind. The handwritten accidentials show some less sharp edges
because the ink is flowing in the inner angles of the glyph. As you
already take the liberty to match the style of classical accidentials,
how about avoiding some sharp inner  angles by

1. filling the tiny white triangle in the sharp-like glyph (I am less
convinced)

2. making the right inner angle round (looks good to me)

I have two images attached where the additinal ink is painted in red and
in black.

Of course, this is just a suggestion.

Joram






I know, thanks.  Here you can find some glyph examples

   https://corp.unicode.org/~roozbeh/sori-koron.pdf


 Werner

Re: Persian accidentals (koron and sori)

[Werner LEMBERG]

>>> https://w3c.github.io/smufl/latest/tables/persian-accidentals.html
>> 
>> Yes, and it is soo ugly.
> 
> It is best consulting some with traditional Persian sheet music.
> But the few ones I have seen tend to be hand drawn, not of very high
> quality, but similar.
> 
> The accidentals were designed by Ali-Naqi Vaziri, and became popular
> for use in Persian sheet music.
> 
> https://en.wikipedia.org/wiki/Ali-Naqi_Vaziri

I know, thanks.  Here you can find some glyph examples

  https://corp.unicode.org/~roozbeh/sori-koron.pdf


Werner

Re: Persian accidentals (koron and sori)

[Hans Åberg]

> On 6 Dec 2021, at 15:34, Werner LEMBERG  wrote:
> 
>>> In case there are experts on Persian music notation: please have a
>>> look here
>>> 
>>> https://gitlab.com/lilypond/lilypond/-/merge_requests/1047
>>> 
>>> and comment on the design.
>> 
>> Here is how they look at SMuFL. Rather thin and of equal thickness,
>> contrary to the standard accidentals.
>> 
>> https://w3c.github.io/smufl/latest/tables/persian-accidentals.html
> 
> Yes, and it is soo ugly.

It is best consulting some with traditional Persian sheet music. But the few 
ones I have seen tend to be hand drawn, not of very high quality, but similar.

The accidentals were designed by Ali-Naqi Vaziri, and became popular for use in 
Persian sheet music.

https://en.wikipedia.org/wiki/Ali-Naqi_Vaziri

Re: Persian accidentals (koron and sori)

[Werner LEMBERG]

>> In case there are experts on Persian music notation: please have a
>> look here
>> 
>>  https://gitlab.com/lilypond/lilypond/-/merge_requests/1047
>> 
>> and comment on the design.
> 
> Here is how they look at SMuFL. Rather thin and of equal thickness,
> contrary to the standard accidentals.
> 
> https://w3c.github.io/smufl/latest/tables/persian-accidentals.html

Yes, and it is soo ugly.


Werner

Re: Persian accidentals (koron and sori)

[Hans Åberg]

> On 6 Dec 2021, at 12:10, Werner LEMBERG  wrote:
> 
> In case there are experts on Persian music notation: please have a
> look here
> 
>  https://gitlab.com/lilypond/lilypond/-/merge_requests/1047
> 
> and comment on the design.

Here is how they look at SMuFL. Rather thin and of equal thickness, contrary to 
the standard accidentals.

https://w3c.github.io/smufl/latest/tables/persian-accidentals.html

Persian accidentals (koron and sori)

[Werner LEMBERG]

In case there are experts on Persian music notation: please have a
look here

  https://gitlab.com/lilypond/lilypond/-/merge_requests/1047

and comment on the design.


Werner

Question about "neo-modern" style for accidentals

[Paolo Prete]

Hello,

In a context of atonal music, using accidentals in the neo-modern style, I
would like to obtain the following behavior automatically: when a note
initially appears with an accidental (sharp or flat), and then the same
note appears without accidentals after other intermediate notes, I would
like the natural sign not to be printed.

1) Is it possible?
2) If it is possible, is it also possible to print it as a cautionary?
3) If 1) is not possible, can LilyPond at least print on the output, as a
memo, that the natural sign has been added, so that I can manually delete
(or change) it later?

Thanks in advance for any answer!
P

%
\score {

  {
% What I see
cis' d' e' c'
% What I would like to obtain
cis' d' e' \tweak Accidental.stencil ##f c'
% I would like to obtain this as well
cis' d' e' c'?
  }

  \layout {
\context {
  \Score
\accidentalStyle "neo-modern-cautionary"
}
  }

}
%