Re: \stopStaff \startStaff bug

[Jean Abou Samra]

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