lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: \stopStaff \startStaff bug


From: ebenezer
Subject: Re: \stopStaff \startStaff bug
Date: Sat, 7 Jan 2023 14:42:49 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

[  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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]