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.
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,
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 opini
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 o
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
>> wo
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
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
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 mu
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
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 g
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
assum
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_
>> t
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?
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 use
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 de
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 betwe
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 wit
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.
>
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
ha
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
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 over
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 o
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 earlie
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 decision
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 as
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
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
[ 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 im
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 engra
Hi Tomasz,
Am 05.01.23 um 13:16 schrieb Tomasz Bauć:
I also checked version without the Scheme:
\stopStaff
\repeat unfold 9 {s8}
\startStaff
\stopStaff
\repeat unfold 3 {s8}
\startStaff
\stopStaff
\repeat unfold 11 {s8}
\startStaff
(Please always give compl
30 matches
Mail list logo
