date:20230107



> Le 8 janv. 2023 à 06:02, Mark Probert  a écrit :
> 
> Hi.
> 
> At the moment I’m doing quite a few lead sheets. The slightly unfortunate 
> thing is some of these tunes are a stave or two over a page in length. 
> 
> I thought I’d reach out and see if there is such a thing as a macro or music 
> function like \fitToOnePage that would fit in a layout/page and can 
> automatically resize the items to live on that single page.
> 
> Any help appreciated
> 
> -mark.


See https://lilypond.org/doc/v2.24/Documentation/notation/other-paper-variables
It’s as easy as

\paper {
  page-count = 1
}

Best
Jean

Fit to one/n pages

2023-01-07 Thread Mark Probert

Hi.

At the moment I’m doing quite a few lead sheets. The slightly unfortunate
thing is some of these tunes are a stave or two over a page in length.

I thought I’d reach out and see if there is such a thing as a macro or
music function like \fitToOnePage that would fit in a layout/page and can
automatically resize the items to live on that single page.

Any help appreciated

-mark.

Re: N in markup command exported as I with an underlying dot


Le 07/01/2023 à 20:45, Xin Guo a écrit :

Hi,

I’m new to lily pond. Somehow when I try to export “N” in markup command. It’s 
shown up as an I with an underlying dot in the PDF. When I copy it and pasted 
in the browser, it’s shown up as “N”. Not sure what’s the issue here. Can 
someone help me?

Code snippet I used.

\version "2.24.0"

\language "english"

\markup "N n N n”

I have attached the example output.





It's a Homebrew problem, see the recent thread

https://lists.gnu.org/archive/html/lilypond-user/2022-12/msg00349.html

(it continues here: 
https://lists.gnu.org/archive/html/lilypond-user/2023-01/msg9.html)


In short: use the official binaries provided on lilypond.org for now.

Best,
Jean




OpenPGP_signature
Description: OpenPGP digital signature

N in markup command exported as I with an underlying dot

2023-01-07 Thread Xin Guo

Hi,

I’m new to lily pond. Somehow when I try to export “N” in markup command. It’s 
shown up as an I with an underlying dot in the PDF. When I copy it and pasted 
in the browser, it’s shown up as “N”. Not sure what’s the issue here. Can 
someone help me?

Code snippet I used.

\version "2.24.0"

\language "english"

\markup "N n N n”

I have attached the example output.


Thanks a lot for your help.

Best Regards,
Xin Guo

Re: Conflict between articulate.ly and \accacciatura in 2.24.0

2023-01-07 Thread Gordon Bower

Thank you! Glad to hear there is already a solution.

GRB


> This has already been fixed. It was
> https://gitlab.com/lilypond/lilypond/-/issues/6489
>
> It will work fine with the upcoming 2.24.1 version, and you can work
> around it by editing the file articulate.ly inside of LilyPond’s internal
> directory in the way shown here:
> https://gitlab.com/lilypond/lilypond/-/merge_requests/1772/diffs
>
> Best,
> Jean
>

Re: \stopStaff \startStaff bug

Hi Jean,

> I think this would handle quite a number of cases without
> the user thinking about it, while still avoiding ambiguity
> at all times.

That would certainly be an improvement over the status quo!

Kieren.

Re: \stopStaff \startStaff bug


Le 07/01/2023 à 19:16, Jean Abou Samra a écrit :

"\dt + warning if not used"



Come to think of it:

For sure, we don't need a warning about \dt (or grace skips) not being
used in the case where there are no zero-length events at that point.

The grace note problem is extremely general. However, the use cases in
which people write bug reports about it are largely the same: the
events involved are mostly \clef, \time and \key.

As a limited special heuristic, there could be no warning and an
automatic move to before graces if all the zero-length events
are of this category. (More might be added, like \bar and \section.)

I think this would handle quite a number of cases without
the user thinking about it, while still avoiding ambiguity
at all times.



OpenPGP_signature
Description: OpenPGP digital signature

Re: \stopStaff \startStaff bug


Le 07/01/2023 à 18:43, David Kastrup a écrit :

Well, this was sort of saying that there may be no silver bullet, but we
may have to pick between chrome and aluminum ones.

Sometimes there is a solution that blends better into human expectations
than strict logic.




That's possible.

In my opinion, "\dt + warning if not used" is not a bad contender
due to its robustness and simplicity, but other tradeoffs are
thinkable between heuristics matching what users expect,
implementation and Scheme extension simplicity, and backwards
compatibility. That said, I have no idea how difficult something
like making overrides extend over graces would be.



OpenPGP_signature
Description: OpenPGP digital signature

Re: Custom engraver to modify bent grace notes

Le 07/01/2023 à 18:41, Nate Whetsell a écrit :

Hi,

I have a question about using a custom engraver to modify how grace
notes appear when LilyPond’s new string bending is applied to them.
This is the first custom engraver I’ve attempted to write, so I think
I’ve overlooked something rather basic. The repository for the
engraver is at
https://github.com/nwhetsell/lilypond-bending-additions, and the
current engraver is at

https://github.com/nwhetsell/lilypond-bending-additions/blob/0bbfdaa9a76bef10c4b23cc97b1edede8fde2f2a/bending-additions.ily

Conceptually, I’m trying to do three things:

1. If a string bend starts on a grace note, don’t reduce the size of
the fret number in a TabStaff.

2. If, in addition, the bent grace note is a pre-bend, put the
notehead in parentheses, and don’t draw ledger lines, flags, or stems.

3. If a string bend ends on a grace note, don’t draw the
notehead, ledger lines, accidentals, flags, or stems (don’t draw
anything, basically).

I'm ignorant about guitar techniques, but is this note really a grace
note? Wouldn't you be better off getting rid of graces, and creating a
grob like TrillPitchHead from your engraver?

Assuming that grace notes are what you want in the first place ...

Bearing in mind that there’s a lot about writing engravers that I
don’t know,

Maybe it will help to read
https://extending-lilypond.readthedocs.io/en/latest/translation.html#writing-an-engraver

where I think I’m having difficulty is determining whether a note is a
grace note. In short, I’m getting a notehead grob using an
acknowledger and then checking the value of its ly:moment-grace
in
the engraver’s stop-translation-timestep method. However, this doesn’t
work directly. In stop-translation-timestep, the moment of a notehead
created in that timestep appears to always be null.

Yes, it's not set up yet. Basically, grob::when is meant to be used in
the backend (grob callbacks). During translation (in engravers), there
is no need. By definition, all note heads that arrive in the same time
step are grace notes iff that time step is a grace time step, and you
can get the moment of the current time step in the engravers using

(ly:context-current-moment context)

HTH

OpenPGP_signature
Description: OpenPGP digital signature

Re: \stopStaff \startStaff bug


Le 07/01/2023 à 18:32, Kieren MacMillan a écrit :

David’s interpretation of my idea isn’t correct. I never suggested letting the 
second Staff start after the grace note, simply that decisions for that Staff 
should be made independently of the Staff that contains the grace music.

Here’s a set of rules that handles this issue without a problem that I can see:

1. Determine which contexts are affected by G.

2a. Determine all grobs and events (e.g. overrides) in each Staff that aren’t 
affected by G.
2b. Split non-affected contexts into pre-G and post-G portions.

3a. Determine all grobs and events (e.g., overrides) in each Staff affected by 
G.
3b. Split affected contexts into pre-G, G, and post-G portions.

4. Determine spacing, taking into account all portions as determined above.

So in this “clef at the beginning” example, my rules map to logic as follows:

1. Upper staff is affected by G; lower staff isn’t.

2a. Lower staff should include: bass clef, time signature, and note.
2b. Bass clef and time signature are pre-G; note [and any note-attached 
zero-duration events!] is post-G.

3a. Upper staff should include: treble clef, time signature, grace note, and 
note.
3b. Treble clef and time signature are pre-G; grace note is G; note is post-G

4. Proceed as per normal spacing rules.




You want the decisions to be done based on the grobs created, i.e., in
the backend.

The problems is that the decisions have to be made earlier than that. The
basic problem is picking at which moment you want to send an event to the
engravers, so you don't have access to the grobs that will be created by
engravers in reaction to this process.

Best
Jean



OpenPGP_signature
Description: OpenPGP digital signature

Re: \stopStaff \startStaff bug

Hi all,

>> That would presumably lead to
>> 
>> {
>>   \once \override NoteHead.color = ...
>>   \once \override Staff.NoteHead.color = ...
>>   ...
>> }
>> 
>> getting the events reordered so that the Staff.NoteHead override
>> starts before graces and the NoteHead one starts after, which I
>> would definitely find surprising.

As long as it’s logical, predictable, and consistent, “surprising” is no worse 
than what we have now — and the number of cases where users would be surprised 
would probably drop significantly from the current implementation.

> Well, this was sort of saying that there may be no silver bullet, but we
> may have to pick between chrome and aluminum ones.
> 
> Sometimes there is a solution that blends better into human expectations
> than strict logic.

Couldn’t have said it better myself.  ;)

Cheers,
Kieren.

Re: \stopStaff \startStaff bug

Jean Abou Samra  writes:

> Le 07/01/2023 à 17:58, David Kastrup a écrit :
>>> In that case, the NoteHead one has no effect, because \once applies to
>>> the next time step only, and the next time step is for a grace note
>>> another voice.
>> The recovery action of \once should likely occur after the next _local_
>> timestep.
>
> OK, that is an interesting idea, although I would personally find ...
>
>
>> With that interpretation, \once \override Staff.NoteHead.color would
>> color _all_ grace notes.
>
>
> ... this somewhat confusing.
>
>
>
>> An alternative would be to try to involve
>> \context ... constructs in the grace fixup decisions, in which case
>> NoteHead.color and Staff.NoteHead.color would lead to different timings
>> of the result.
>
>
>
> That would presumably lead to
>
> {
>   \once \override NoteHead.color = ...
>   \once \override Staff.NoteHead.color = ...
>   ...
> }
>
> getting the events reordered so that the Staff.NoteHead override
> starts before graces and the NoteHead one starts after, which I
> would definitely find surprising.
>
>
> Either way, stuff like
>
>
> \version "2.24.0"
>
> articulations = {
>   <>\< \after 8 \! s4
> }
>
> \new Voice <<
>   { \grace b8 c'8 d'8 }
>   \articulations
>>>
>
>
> would have its output changed in a way that I would consider
> unwanted.

Well, this was sort of saying that there may be no silver bullet, but we
may have to pick between chrome and aluminum ones.

Sometimes there is a solution that blends better into human expectations
than strict logic.

-- 
David Kastrup

Custom engraver to modify bent grace notes

2023-01-07 Thread Nate Whetsell

Hi,

I have a question about using a custom engraver to modify how grace notes 
appear when LilyPond’s new string bending is applied to them. This is the first 
custom engraver I’ve attempted to write, so I think I’ve overlooked something 
rather basic. The repository for the engraver is at 
https://github.com/nwhetsell/lilypond-bending-additions, and the current 
engraver is at

https://github.com/nwhetsell/lilypond-bending-additions/blob/0bbfdaa9a76bef10c4b23cc97b1edede8fde2f2a/bending-additions.ily

Conceptually, I’m trying to do three things:

1. If a string bend starts on a grace note, don’t reduce the size of the fret 
number in a TabStaff.

2. If, in addition, the bent grace note is a pre-bend, put the notehead in 
parentheses, and don’t draw ledger lines, flags, or stems.

3. If a string bend ends on a grace note, don’t draw the notehead, ledger 
lines, accidentals, flags, or stems (don’t draw anything, basically).

Bearing in mind that there’s a lot about writing engravers that I don’t know, 
where I think I’m having difficulty is determining whether a note is a grace 
note. In short, I’m getting a notehead grob using an acknowledger and then 
checking the value of its ly:moment-grace 

 in the engraver’s stop-translation-timestep method. However, this doesn’t work 
directly. In stop-translation-timestep, the moment of a notehead created in 
that timestep appears to always be null. As workaround, I’m saving the notehead 
and then getting its moment in the next call to stop-translation-timestep, at 
which point the notehead’s moment is no longer null.

The issue here is that there are some properties that appear to only have an 
effect when they’re applied to a notehead in the same timestep in which it’s 
created. For example, setting no-ledgers to #t has no affect when applied to 
noteheads from a previous timestep.

There’s some simplified code that attempts to illustrate this below. Is there 
another way for a custom engraver to determine whether a note is a grace note?

Thanks in advance!
Nate

\version "2.24.0"

#(define (Grace_reporting_engraver context)
  (let (
  (current-note-head '())
  (previous-note-head '()))

(make-engraver
  (acknowledgers
((note-head-interface engraver grob source-engraver)
  (set! current-note-head grob)))

  ((stop-translation-timestep engraver)
(if (not (null? current-note-head))
  (let (
  (moment (grob::when current-note-head)))
(if (not (null? moment))
  (if (not (eq? (ly:moment-grace moment) 0))
(begin (newline)(display "==> current-note-head is for a grace 
note")))
  (begin (newline)(display "==> current-note-head has null 
moment")

(if (not (null? previous-note-head))
  (let (
  (moment (grob::when previous-note-head)))
(if (not (null? moment))
  (if (not (eq? (ly:moment-grace moment) 0))
(begin (newline)(display "==> previous-note-head is for a grace 
note")))
  (begin (newline)(display "==> previous-note-head has null 
moment")

(set! previous-note-head current-note-head)
(set! current-note-head '())

{
  \new Voice \with {
\consists #Grace_reporting_engraver
  } {
\grace c' \grace d' \grace e'
  }
}

#(define (Current_note_ledger_hider context)
  (let (
  (current-note-head '()))

(make-engraver
  (acknowledgers
((note-head-interface engraver grob source-engraver)
  (set! current-note-head grob)))

  ((stop-translation-timestep engraver)
(if (not (null? current-note-head))
  (ly:grob-set-property! current-note-head 'no-ledgers #t))

{
  \new Voice \with {
\consists #Current_note_ledger_hider
  } {
\grace c''' \grace c'''
  }
}

#(define (Previous_note_ledger_hider context)
  (let (
  (current-note-head '())
  (previous-note-head '()))

(make-engraver
  (acknowledgers
((note-head-interface engraver grob source-engraver)
  (set! current-note-head grob)))

  ((stop-translation-timestep engraver)
(if (not (null? previous-note-head))
  (ly:grob-set-property! previous-note-head 'no-ledgers #t))

(set! previous-note-head current-note-head)
(set! current-note-head '())

{
  \new Voice \with {
\consists #Previous_note_ledger_hider
  } {
\grace c''' \grace c'''
  }
}

Re: \stopStaff \startStaff bug

Hi David,

> Then I will wait until I see your actual implementation instead of
> reading any meaning into your words.

“Non-implemented” and “implemented” are not the only two possible states in the 
development of computer code.

I look forward to any discussion, with any developers, of possible logic and 
rules in the pursuit of a proposed implementation that might occur between the 
current “non-implemented” state and any future “implemented” state. My email 
that crossed this one in the ether is perhaps a starting point for such a 
discussion.

Cheers,
Kieren.

Re: \stopStaff \startStaff bug

Hi all,

> You cannot let the second Staff start after the grace note.

David’s interpretation of my idea isn’t correct. I never suggested letting the 
second Staff start after the grace note, simply that decisions for that Staff 
should be made independently of the Staff that contains the grace music.

Here’s a set of rules that handles this issue without a problem that I can see:

1. Determine which contexts are affected by G.

2a. Determine all grobs and events (e.g. overrides) in each Staff that aren’t 
affected by G.
2b. Split non-affected contexts into pre-G and post-G portions.

3a. Determine all grobs and events (e.g., overrides) in each Staff affected by 
G.
3b. Split affected contexts into pre-G, G, and post-G portions.

4. Determine spacing, taking into account all portions as determined above.


So in this “clef at the beginning” example, my rules map to logic as follows:

1. Upper staff is affected by G; lower staff isn’t.

2a. Lower staff should include: bass clef, time signature, and note.
2b. Bass clef and time signature are pre-G; note [and any note-attached 
zero-duration events!] is post-G.

3a. Upper staff should include: treble clef, time signature, grace note, and 
note.
3b. Treble clef and time signature are pre-G; grace note is G; note is post-G

4. Proceed as per normal spacing rules.


Happy to hear comments about the rules and logic outlined above.

Cheers,
Kieren.

Re: \stopStaff \startStaff bug


Le 07/01/2023 à 17:58, David Kastrup a écrit :

In that case, the NoteHead one has no effect, because \once applies to
the next time step only, and the next time step is for a grace note
another voice.

The recovery action of \once should likely occur after the next _local_
timestep.




OK, that is an interesting idea, although I would personally find ...



With that interpretation, \once \override Staff.NoteHead.color would
color _all_ grace notes.



... this somewhat confusing.




An alternative would be to try to involve
\context ... constructs in the grace fixup decisions, in which case
NoteHead.color and Staff.NoteHead.color would lead to different timings
of the result.




That would presumably lead to

{
  \once \override NoteHead.color = ...
  \once \override Staff.NoteHead.color = ...
  ...
}

getting the events reordered so that the Staff.NoteHead override
starts before graces and the NoteHead one starts after, which I
would definitely find surprising.


Either way, stuff like


\version "2.24.0"

articulations = {
  <>\< \after 8 \! s4
}

\new Voice <<
  { \grace b8 c'8 d'8 }
  \articulations
>>


would have its output changed in a way that I would consider
unwanted.





So what do you do for an arbitrary \once \override? Especially if
there is a Scheme engraver that might decide to create this grob at
any time?

\once \override is not a grob.



Well, I meant the grob type that \once \override is modifying.




OpenPGP_signature
Description: OpenPGP digital signature

Re: \stopStaff \startStaff bug

Kieren MacMillan  writes:

> Hi David,
>
>> That's just wild hand-waving.  You cannot let the second Staff start
>> after the grace note.  That would look like
>
> You have inferred things about my suggested implementation which I
> neither stated nor implied.
> (These kinds of discussions always go better when people don’t make
> assumptions.)

Then I will wait until I see your actual implementation instead of
reading any meaning into your words.

-- 
David Kastrup

Re: \stopStaff \startStaff bug

Hi David,

> That's just wild hand-waving.  You cannot let the second Staff start
> after the grace note.  That would look like

You have inferred things about my suggested implementation which I neither 
stated nor implied.
(These kinds of discussions always go better when people don’t make 
assumptions.)

> A "theory" has hard rules.  You haven't come up with any set of rules
> that would not either _mandate_ the behavior that constitutes issue 34
> or would result in worse artifacts.

At the moment, I am in the Organizing and Sensing phases of behaviour, not 
Doing. (I realize many of the programmers in this list are of the “Do first” 
persuasion, but that’s not my process.) I’m more than happy to work with you 
with a set of “hard rules” that neither mandates the Issue #34 behaviour nor 
“would result in worse artifacts”, if you’re willing to put aside making 
assumptions about my proposed implementation and actually work on the problem 
instead.

> Computer problems cannot be solved with linguistics, only with logic.

I do that all the time as a programmer… and get paid pretty well for the 
effort, as it turns out.  =)

Cheers,
Kieren.

Re: \stopStaff \startStaff bug

Kieren MacMillan  writes:

> Hi David (et al.),
>
>>> In that case, the NoteHead one has no effect, because \once applies to
>>> the next time step only, and the next time step is for a grace note
>>> another voice.
>> 
>> The recovery action of \once should likely occur after the next _local_
>> timestep.
>> 
>>> Do they occur after?  In that case, the TimeSignature one has no
>>> effect, because the TimeSignature grob was created before the graces.
>>> The latter is the currently chosen interpretation.
>> 
>> With that interpretation, \once \override Staff.NoteHead.color would
>> color _all_ grace notes.  An alternative would be to try to involve
>> \context ... constructs in the grace fixup decisions, in which case
>> NoteHead.color and Staff.NoteHead.color would lead to different timings
>> of the result.
>> 
>>> So what do you do for an arbitrary \once \override? Especially if
>>> there is a Scheme engraver that might decide to create this grob at
>>> any time?
>> 
>> \once \override is not a grob.
>
> It appears that David is saying exactly what I’m suggesting
> [separating grobs from zero-duration events, eliminating
> context-bleed, etc.], the only exception being the order of operations
> (pre-grace or post-grace). If David’s approach *does* “map well into
> code intended for computers”, I could care less about the actual order
> of operations that Lilypond takes.

Nope, David is saying nothing in any way remotely similar to what you
are saying.  I have tried sketching several different approaches to
dealing with the "\once problem" (which is a particularly obnoxious
angle of the general \override problem) that Jean pointed out to be
problematic in the context of extending the fixup mechanism to parallel
music.

Neither is really an expression of any principle but rather a suggestion
of how to apply additional bandaids to particular points for reducing
the amount of user-surprising artifacts.

"user-surprising artifact" unfortunately is not the same as "illogical".

-- 
David Kastrup

Re: \stopStaff \startStaff bug

Hi David (et al.),

>> In that case, the NoteHead one has no effect, because \once applies to
>> the next time step only, and the next time step is for a grace note
>> another voice.
> 
> The recovery action of \once should likely occur after the next _local_
> timestep.
> 
>> Do they occur after?  In that case, the TimeSignature one has no
>> effect, because the TimeSignature grob was created before the graces.
>> The latter is the currently chosen interpretation.
> 
> With that interpretation, \once \override Staff.NoteHead.color would
> color _all_ grace notes.  An alternative would be to try to involve
> \context ... constructs in the grace fixup decisions, in which case
> NoteHead.color and Staff.NoteHead.color would lead to different timings
> of the result.
> 
>> So what do you do for an arbitrary \once \override? Especially if
>> there is a Scheme engraver that might decide to create this grob at
>> any time?
> 
> \once \override is not a grob.

It appears that David is saying exactly what I’m suggesting [separating grobs 
from zero-duration events, eliminating context-bleed, etc.], the only exception 
being the order of operations (pre-grace or post-grace). If David’s approach 
*does* “map well into code intended for computers”, I could care less about the 
actual order of operations that Lilypond takes.

Cheers,
Kieren.

Re: \stopStaff \startStaff bug

Kieren MacMillan  writes:

> Hi Jean,
>
>> Um, that is exactly the current default. And it is what makes
>> 
>> \version "2.24.0"
>> 
>> <<
>>   \new Staff { \grace c'8 c'1 }
>>   \new Staff {
>> \clef bass % zero-length => after graces
>> c'1
>>   }
>> >>
>> 
>> return output that most users are not expecting.
>
> In this case (as with so many!) the problem isn't moment-bleed, it's
> context-bleed: the grace music doesn’t apply to the lower staff, and
> thus shouldn’t be included in decision-making there; likewise, the
> clef doesn’t apply to the upper staff, and so shouldn’t be included in
> the decision-making there.

That's just wild hand-waving.  You cannot let the second Staff start
after the grace note.  That would look like

> a.k.a. This still isn’t evidence that disproves my theory of how
> things could/should work.

A "theory" has hard rules.  You haven't come up with any set of rules
that would not either _mandate_ the behavior that constitutes issue 34
or would result in worse artifacts.

Computer problems cannot be solved with linguistics, only with logic.

-- 
David Kastrup

Re: \stopStaff \startStaff bug

p.s.

> In this case (as with so many!) the problem isn't moment-bleed, it's 
> context-bleed: the grace music doesn’t apply to the lower staff, and thus 
> shouldn’t be included in decision-making there; likewise, the clef doesn’t 
> apply to the upper staff, and so shouldn’t be included in the decision-making 
> there.

By “decision-making” here, I mean the “what grobs need to appear in each 
context” decisions, not the horizontal spacing decisions that would [at least 
for a human engraver] come after that.

— Kieren

Re: \stopStaff \startStaff bug

Kieren MacMillan  writes:

> Hi Jean,
>
>> That sounds like you want to make all zero-length events happen
>> before the grace by default, but that is not always desirable,
>> as \once \set/\override shows.
>
> I would say the exact opposite: by default, all zero-length events
> should happen between the grace music and the restarting of real time
> (i.e., “after” the grace and “before” the real moment) — so the order
> would be
>
>0. music before moment M
>[regular time stops at “the limit of M-minus-m as m approaches zero”]
>[liminal space begins]
>1. zero-length events connected with grace music
>2. grace music
>[liminal space ends]
>[moment M finally arrives]
>3. zero-length events connected with post-grace music
>4. post-grace music
>
> The only “handwavy” thing I see about my approach is exactly how to
> code the “connected with” in #1… but given the fact that we have slur
> ids and the like, I can’t imagine that’s unsolveable.

So basically you are arguing to keep issue #34 as-is except for
handwaving, but then there are other completely unrelated hard things.

Uh, that's sort of a populist approach to the problem.  It works for
convincing human users but does not map well into code intended for
computers.

-- 
David Kastrup

Re: \stopStaff \startStaff bug

Hi Jean,

> Um, that is exactly the current default. And it is what makes
> 
> \version "2.24.0"
> 
> <<
>   \new Staff { \grace c'8 c'1 }
>   \new Staff {
> \clef bass % zero-length => after graces
> c'1
>   }
> >>
> 
> return output that most users are not expecting.

In this case (as with so many!) the problem isn't moment-bleed, it's 
context-bleed: the grace music doesn’t apply to the lower staff, and thus 
shouldn’t be included in decision-making there; likewise, the clef doesn’t 
apply to the upper staff, and so shouldn’t be included in the decision-making 
there.

a.k.a. This still isn’t evidence that disproves my theory of how things 
could/should work.

Cheers,
Kieren.

Re: \stopStaff \startStaff bug

Jean Abou Samra  writes:

> Le 07/01/2023 à 17:11, Kieren MacMillan a écrit :
>> Could you explain this a bit more, please? This is a position I’ve
>> never quite understood about Issue #34: I would love to see an input
>> where I can’t determine the output with certainty just from the
>> input.
>
>
> Just take the example I gave earlier and remove the grace skips.
>
> \version "2.24.0"
>
> <<
>   \new Staff { \grace { c'8 d'8 } c'1 }
>   \new Staff {
>     \once \override Staff.TimeSignature.color = "red"
>     \once \override NoteHead.color = "red"
>     c'1
>   }
>>>
>
>
> (looks like the staves are swapped if you remove \new Staff...).
>
> Do the overrides occur before the graces?

Yes.

> In that case, the NoteHead one has no effect, because \once applies to
> the next time step only, and the next time step is for a grace note
> another voice.

The recovery action of \once should likely occur after the next _local_
timestep.

> Do they occur after?  In that case, the TimeSignature one has no
> effect, because the TimeSignature grob was created before the graces.
> The latter is the currently chosen interpretation.

With that interpretation, \once \override Staff.NoteHead.color would
color _all_ grace notes.  An alternative would be to try to involve
\context ... constructs in the grace fixup decisions, in which case
NoteHead.color and Staff.NoteHead.color would lead to different timings
of the result.

> So what do you do for an arbitrary \once \override? Especially if
> there is a Scheme engraver that might decide to create this grob at
> any time?

\once \override is not a grob.

-- 
David Kastrup

Re: \stopStaff \startStaff bug


Le 07/01/2023 à 17:50, Kieren MacMillan a écrit :

Hi Jean,


That sounds like you want to make all zero-length events happen
before the grace by default, but that is not always desirable,
as \once \set/\override shows.

I would say the exact opposite: by default, all zero-length events should 
happen between the grace music and the restarting of real time (i.e., “after” 
the grace and “before” the real moment) — so the order would be




Um, that is exactly the current default. And it is what makes

\version "2.24.0"

<<
  \new Staff { \grace c'8 c'1 }
  \new Staff {
    \clef bass % zero-length => after graces
    c'1
  }
>>

return output that most users are not expecting.



OpenPGP_signature
Description: OpenPGP digital signature

Re: \stopStaff \startStaff bug

Hi Jean,

> That sounds like you want to make all zero-length events happen
> before the grace by default, but that is not always desirable,
> as \once \set/\override shows.

I would say the exact opposite: by default, all zero-length events should 
happen between the grace music and the restarting of real time (i.e., “after” 
the grace and “before” the real moment) — so the order would be

   0. music before moment M
   [regular time stops at “the limit of M-minus-m as m approaches zero”]
   [liminal space begins]
   1. zero-length events connected with grace music
   2. grace music
   [liminal space ends]
   [moment M finally arrives]
   3. zero-length events connected with post-grace music
   4. post-grace music

The only “handwavy” thing I see about my approach is exactly how to code the 
“connected with” in #1… but given the fact that we have slur ids and the like, 
I can’t imagine that’s unsolveable.

Cheers,
Kieren.

Re: \stopStaff \startStaff bug

Hi Jean,

> Just take the example I gave earlier and remove the grace skips.
> 
> \version "2.24.0"
> <<
>   \new Staff { \grace { c'8 d'8 } c'1 }
>   \new Staff {
> \once \override Staff.TimeSignature.color = "red"
> \once \override NoteHead.color = "red"
> c'1
>   }
> >>
> Do the overrides occur before the graces?

No: “obviously” (to me), all \once \override or \tweak commands are attached to 
the moment they occur in, not to some “liminal space” created by another 
context. This example doesn’t convince me: I can still easily find a single 
rule that covers this case [as I understand it] and the alternative [given 
clear documentation/instructions on how to apply the override before the grace 
music].

In my mind, grace time exists like the dialogue over a barline-with-fermata in 
a musical or opera: If you say that the downbeat of the next measure is spoken 
by Frank, that doesn’t retroactively change the dialogue over the barline to be 
spoken by Frank. (It's a twisted analogy, but it’s essentially what you’re 
suggesting.)

Cheers,
Kieren.

Re: \stopStaff \startStaff bug


Le 07/01/2023 à 17:17, David Kastrup a écrit :

I disagree.  We have grace fixups in sequential music that do this
(zero-length events before grace music are executed before the grace)
and the same reasonably could be done with simultaneous music.  That's
more complex, but not terribly so.  Some of the restructuring by Dan
might provide a better template to work with than previously.




That sounds like you want to make all zero-length events happen
before the grace by default, but that is not always desirable,
as \once \set/\override shows.



OpenPGP_signature
Description: OpenPGP digital signature

Re: \stopStaff \startStaff bug


Le 07/01/2023 à 17:11, Kieren MacMillan a écrit :

Could you explain this a bit more, please? This is a position I’ve never quite 
understood about Issue #34: I would love to see an input where I can’t 
determine the output with certainty just from the input.



Just take the example I gave earlier and remove the grace skips.

\version "2.24.0"

<<
  \new Staff { \grace { c'8 d'8 } c'1 }
  \new Staff {
    \once \override Staff.TimeSignature.color = "red"
    \once \override NoteHead.color = "red"
    c'1
  }
>>


(looks like the staves are swapped if you remove \new Staff...).

Do the overrides occur before the graces? In that case,
the NoteHead one has no effect, because \once applies
to the next time step only, and the next time step is
for a grace note another voice. Do they occur after?
In that case, the TimeSignature one has no effect, because
the TimeSignature grob was created before the graces.
The latter is the currently chosen interpretation.

So what do you do for an arbitrary \once \override? Especially
if there is a Scheme engraver that might decide to create this
grob at any time?



OpenPGP_signature
Description: OpenPGP digital signature

Re: \stopStaff \startStaff bug

Jean Abou Samra  writes:

> Le 07/01/2023 à 16:48, Kieren MacMillan a écrit :
>> Hi all,
>>
>>> [  It sometimes makes me wonder if we need a concept of "infinitesimal
>>> time", to allow disambiguating  ]
>>>
>>> Yes, the concept of 0-cycles, that can be allowed to execute in
>>> order for decisions to be made at the end of the timestep once all
>>> the 0-cycles have completed, seems like a good idea.
>> That might even be a liminal space in which the infamous Grace Music
>> Bug™ could be handled grace-fully…?
>
>
>
> Actually, that is what originally made me muse about this ...
>
> Issue #34 is, in my opinion, a perfectly unsolvable problem, because
> it's asking LilyPond to guess things that can't be determined with
> certainty from the user input, and it is practically impossible in
> general to guess these without reading the user's mind.

I disagree.  We have grace fixups in sequential music that do this
(zero-length events before grace music are executed before the grace)
and the same reasonably could be done with simultaneous music.  That's
more complex, but not terribly so.  Some of the restructuring by Dan
might provide a better template to work with than previously.

-- 
David Kastrup

Re: \stopStaff \startStaff bug

Hi Jean,

>> That might even be a liminal space in which the infamous Grace Music Bug™ 
>> could be handled grace-fully…?
> Actually, that is what originally made me muse about this ...

“Great minds think alike…”  ;)

> Issue #34 is, in my opinion, a perfectly unsolvable problem, because
> it's asking LilyPond to guess things that can't be determined with
> certainty from the user input, and it is practically impossible in
> general to guess these without reading the user's mind.

Could you explain this a bit more, please? This is a position I’ve never quite 
understood about Issue #34: I would love to see an input where I can’t 
determine the output with certainty just from the input.

Thanks,
Kieren.

Re: \stopStaff \startStaff bug


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

Hi all,


[  It sometimes makes me wonder if we need a concept of "infinitesimal
time", to allow disambiguating  ]

Yes, the concept of 0-cycles, that can be allowed to execute in order for 
decisions to be made at the end of the timestep once all the 0-cycles have 
completed, seems like a good idea.

That might even be a liminal space in which the infamous Grace Music Bug™ could 
be handled grace-fully…?




Actually, that is what originally made me muse about this ...

Issue #34 is, in my opinion, a perfectly unsolvable problem, because
it's asking LilyPond to guess things that can't be determined with
certainty from the user input, and it is practically impossible in
general to guess these without reading the user's mind. Therefore,
my preferred way of handling it would be to add a command sparing
the need to compute the duration of the grace group, as a way
to replace grace skips.

<<
  { \grace { c'8 d'8 } c'1 }
  {
    \once \override Staff.TimeSignature.color = "red"
    \grace s4 % => \dt  ???
    \once \override NoteHead.color = "red"
    c'1
  }
>>


If we additionally require the user to add \dt (or grace
skips) when there is such an ambiguity, by emitting a
warning/error in such cases, there will be no confusion for
users, and the problem will be kind of solved, even if not
in the way that most people would like but is in fact
hardly possible.

Again: implementation handwaving, and I'm definitely not
going to look at this anytime soon.

Best,
Jean



OpenPGP_signature
Description: OpenPGP digital signature

Re: \stopStaff \startStaff bug

Hi all,

> [  It sometimes makes me wonder if we need a concept of "infinitesimal
> time", to allow disambiguating  ]
> 
> Yes, the concept of 0-cycles, that can be allowed to execute in order for 
> decisions to be made at the end of the timestep once all the 0-cycles have 
> completed, seems like a good idea.

That might even be a liminal space in which the infamous Grace Music Bug™ could 
be handled grace-fully…?

Cheers,
Kieren.

Re: problems with release 2.24 on iMac M1 with Ventura 13.0.1

2023-01-07 Thread Mario Bolognani

Sorry, 

using: "/Users/mariobol/Library/CloudStorage/Dropbox/ M U S I C 
A/lilypond-2.24.0/bin/convert-ly" -e /Users/mariobol/Desktop/Scores/*.ly

the updated files are in Scores!

Best,

Mario

Mario Bolognani
mario.bologn...@gmail.com



> Il giorno 7 gen 2023, alle ore 16:20, Mario Bolognani 
>  ha scritto:
> 
> Yes, you’re right Jean, 
> 
> using Scores in Desktop you can update all your files in batch mode. One more 
> question: the updated files remain in Terminal and the files in Scores are 
> not updated… Possibly another Terminal command is necessary?
> 
> Many thanks for your very useful suggestions
> 
> Mario
> 
> Mario Bolognani
> mario.bologn...@gmail.com
> 
> 
> 
>> Il giorno 7 gen 2023, alle ore 00:46, Jean Abou Samra  
>> ha scritto:
>> 
>> Le 06/01/2023 à 22:22, Mario Bolognani a écrit :
>>> Thanks a lot Jean, apparently with Terminal convert.ly operates correctly, 
>>> but of course this is not a practical procedure for frequent use.
>> 
>> 
>> 
>> If you start using the command line more, you will find that it is
>> actually incredibly practical for more than you would have imagined.
>> 
>> For example, if you want to do a batch upgrade of all .ly files in
>> a directory, say "Scores" on your desktop, while making backups of
>> the unconverted sources just in case, it is as easy as
>> 
>> "/Users/mariobol/Library/CloudStorage/Dropbox/ M U S I C 
>> A/lilypond-2.24.0/bin/convert-ly" /Users/mariobol/Desktop/Scores/*.ly
>> 
>> Not to say that I wouldn't like Frescobaldi to work better on macOS,
>> of course.
>> 
>> Best,
>> Jean
>> 
>

Re: problems with release 2.24 on iMac M1 with Ventura 13.0.1


Le 07/01/2023 à 16:20, Mario Bolognani a écrit :

Yes, you’re right Jean,

using Scores in Desktop you can update all your files in batch mode. 
One more question: the updated files remain in Terminal and the files 
in Scores are not updated… Possibly another Terminal command is necessary?




This is the correction I sent after my previous email: in order to
make convert-ly edit the original files instead of outputting all
the LilyPond code on the terminal, you need to add the "-e" option
between "/.../convert-ly" and "/.../Desktop/Scores/".

(Don't fear, it will make backups of the original files, just in case
something went wrong.)

Running

"/.../convert-ly" --help

will give you a list of all ways you can tweak convert-ly's behavior
from the command line.



OpenPGP_signature
Description: OpenPGP digital signature

Re: problems with release 2.24 on iMac M1 with Ventura 13.0.1

2023-01-07 Thread Mario Bolognani

Yes, you’re right Jean, 

using Scores in Desktop you can update all your files in batch mode. One more 
question: the updated files remain in Terminal and the files in Scores are not 
updated… Possibly another Terminal command is necessary?

Many thanks for your very useful suggestions

Mario

Mario Bolognani
mario.bologn...@gmail.com



> Il giorno 7 gen 2023, alle ore 00:46, Jean Abou Samra  ha 
> scritto:
> 
> Le 06/01/2023 à 22:22, Mario Bolognani a écrit :
>> Thanks a lot Jean, apparently with Terminal convert.ly operates correctly, 
>> but of course this is not a practical procedure for frequent use.
> 
> 
> 
> If you start using the command line more, you will find that it is
> actually incredibly practical for more than you would have imagined.
> 
> For example, if you want to do a batch upgrade of all .ly files in
> a directory, say "Scores" on your desktop, while making backups of
> the unconverted sources just in case, it is as easy as
> 
> "/Users/mariobol/Library/CloudStorage/Dropbox/ M U S I C 
> A/lilypond-2.24.0/bin/convert-ly" /Users/mariobol/Desktop/Scores/*.ly
> 
> Not to say that I wouldn't like Frescobaldi to work better on macOS,
> of course.
> 
> Best,
> Jean
>

Re: \stopStaff \startStaff bug

2023-01-07 Thread ebenezer

[  It sometimes makes me wonder if we need a concept of "infinitesimal
time", to allow disambiguating  ]

Yes, the concept of 0-cycles, that can be allowed to execute in order 
for decisions to be made at the end of the timestep once all the 
0-cycles have completed, seems like a good idea.

I imagine this would require a change to the underlying model of 
Lilypond (also, does Scheme support the concept? Does it have to?) which 
sounds like an implementor's nightmare, but may be LP is structured well 
enough that it is not too awkward - I'm not au fait with LP's internals 
so I don't know the ramifications of "seems like a good idea".

On 2023-01-07 13:27, Jean Abou Samra wrote:

Le 06/01/2023 à 00:37, Lukas-Fabian Moser a écrit :
The Staff_symbol_engraver is not really equipped to deal with 
multiple \startStaff / \stopStaff events at the same point of time.

I would not call the current Staff_symbol_engraver behavior a bug,
but a feature.

You will see that your engraver prevents this from working:

{
  c'1
  \stopStaff
  \once \override Staff.StaffSymbol.color = "red"
  \startStaff
  c'1
}

Ok, this one could be handled by restarting the current staff symbol,
if any, when "\startStaff count = \stopStaff count", instead of keeping
the current one. Now, what about

redStaff = {
  \stopStaff
  \once \override Staff.StaffSymbol.color = "red"
  \startStaff
}

{
  c'1
  \redStaff
  c'
  \stopStaff
  c'1
  \redStaff
  c'1
}

The current, debatable but sometimes useful behavior is that the
\redStaff is enough to start a new staff symbol while there is none.
With your engraver, an extra \startStaff is needed at that point.

There is no simple silver bullet for conflicting events at the
same moment.

It sometimes makes me wonder if we need a concept of "infinitesimal
time", to allow disambiguating

<<
  %% Stop the current one and start a new one, or start a new one
  %% and end it immediately?
  { ... \startStaff ... }
  { ... \stopStaff  ... }
>>

by writing something like

<<
  { ... \startStaff \dt ... }
  { ... \dt \stopStaff  ... }
>>

or

<<
  { ...\dt \startStaff  ... }
  { ... \stopStaff \dt  ... }
>>

but this is very handwaving and how to make it usable
and map it to sane internals is pretty unclear to me.

Best,
Jean

Re: LilyPond 2.24.0 released!

2023-01-07 Thread Benjamin Tordoff

A bit late, I know, but I finally got round to rebuilding all of my scores 
(141) and parts (1623) with the new release. Two scores had errors for things 
that were previously warnings but that I had been ignoring. These were trivial 
to update and now work fine. Everything else worked like a charm and the output 
I've checked so far all looks great. 

Many thanks to everyone involved for all your hard work over many years, it is 
greatly appreciated.

Ben

Re: \stopStaff \startStaff bug


Le 06/01/2023 à 00:37, Lukas-Fabian Moser a écrit :
The Staff_symbol_engraver is not really equipped to deal with multiple 
\startStaff / \stopStaff events at the same point of time.




I would not call the current Staff_symbol_engraver behavior a bug,
but a feature.

You will see that your engraver prevents this from working:

{
  c'1
  \stopStaff
  \once \override Staff.StaffSymbol.color = "red"
  \startStaff
  c'1
}

Ok, this one could be handled by restarting the current staff symbol,
if any, when "\startStaff count = \stopStaff count", instead of keeping
the current one. Now, what about

redStaff = {
  \stopStaff
  \once \override Staff.StaffSymbol.color = "red"
  \startStaff
}

{
  c'1
  \redStaff
  c'
  \stopStaff
  c'1
  \redStaff
  c'1
}


The current, debatable but sometimes useful behavior is that the
\redStaff is enough to start a new staff symbol while there is none.
With your engraver, an extra \startStaff is needed at that point.

There is no simple silver bullet for conflicting events at the
same moment.

It sometimes makes me wonder if we need a concept of "infinitesimal
time", to allow disambiguating

<<
  %% Stop the current one and start a new one, or start a new one
  %% and end it immediately?
  { ... \startStaff ... }
  { ... \stopStaff  ... }
>>

by writing something like

<<
  { ... \startStaff \dt ... }
  { ... \dt \stopStaff  ... }
>>

or

<<
  { ...    \dt \startStaff  ... }
  { ... \stopStaff \dt  ... }
>>

but this is very handwaving and how to make it usable
and map it to sane internals is pretty unclear to me.

Best,
Jean



OpenPGP_signature
Description: OpenPGP digital signature

Re: Conflict between articulate.ly and \accacciatura in 2.24.0