Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]
Hi David, > my own take on what that means would not have been to abolish > grace time: it's still useful for identifying things. But rather to > reduce NoteColumn/MusicalColumn sharing/alignment during grace time to > being just per-Staff, or possibly as option per-Voice. That would > allow, for special cases, to still blow it up back to being per Score. I agree that would be optimal. Cheers, Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info
Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]
Kieren MacMillan writes: > Hi David (et al.), > >> I don't think grace notes are usually synchronized optically. > > According to our recent "live-from-London" keynote speaker… ;) > > … you are correct — in fact, in one example, she shows how grace > groups [of different "sizes"] on two different staves can be > compressed [to the right] to be closer to the principal note/beat, > thus "ruining" any optical synchronization between the staves. Frankly, my own take on what that means would not have been to abolish grace time: it's still useful for identifying things. But rather to reduce NoteColumn/MusicalColumn sharing/alignment during grace time to being just per-Staff, or possibly as option per-Voice. That would allow, for special cases, to still blow it up back to being per Score. One thing I find irritating about grace time is what it does graphically and in midi to an appoggiatura. Those are usually supposed to come on-time, have at _least_ the nominal duration and steal time from the _next_ rather than the previous note. -- David Kastrup My replies have a tendency to cause friction. To help mitigating damage, feel free to forward problematic posts to me adding a subject like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]
Hi David (et al.), > I don't think grace notes are usually synchronized optically. According to our recent "live-from-London" keynote speaker… ;) … you are correct — in fact, in one example, she shows how grace groups [of different "sizes"] on two different staves can be compressed [to the right] to be closer to the principal note/beat, thus "ruining" any optical synchronization between the staves. Cheers, Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info
Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]
Han-Wen Nienhuys writes: > Unfortunately, it's not obvious where to insert the skips. Consider this > > staff1 : grace 16th, whole note > > staff2 : X, whole note > > now, if X is a \clef, you probably want to insert the skip after the X, but > if X is a \once \override for the NoteHead, adding a skip after X will make > it inoperable. > > I fear this is essentially unsolvable in the current model. > > I think the right solution would be to kill grace timing altogether, and > initiate some sort special "embedded" engraving pass that creates the Grace > grobs all at once. > > That would have another downside: if we construct the grace note grobs in a > special pass, there is nothing to synchronize them across staves. You could > have two-handed piano music where the left and right hand do grace notes in > a synchronized way. I don't if that exists in practice, but it is one of > the reasons for the current approach. I don't think grace notes are usually synchronized optically. I may be wrong. -- David Kastrup
Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]
Han-Wen Nienhuys ezt írta (időpont: 2020. febr. 8., Szo 21:44): > > > If we construct the grace note grobs in a > special pass, there is nothing to synchronize them across staves. You could > have two-handed piano music where the left and right hand do grace notes in > a synchronized way. I don't if that exists in practice, but it is one of > the reasons for the current approach. > IIRC the flower motif of the Turangalila symphony is notated just like that. It's a simple note-for-note example; I'll try to find more complex examples. p >
Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]
Am 08.02.20 um 21:44 schrieb Han-Wen Nienhuys:
I think the right solution would be to kill grace timing altogether, and
initiate some sort special "embedded" engraving pass that creates the Grace
grobs all at once.
That would have another downside: if we construct the grace note grobs in a
special pass, there is nothing to synchronize them across staves. You could
have two-handed piano music where the left and right hand do grace notes in
a synchronized way. I don't if that exists in practice, but it is one of
the reasons for the current approach.
I would expect that synchronized grace notes do exist. But more often
than not, at least one solitary grace note is meant to happen "some
infinitesimal amount of time before the main note", without a need to
keep track of (so-to-say) different lengths of infinitesimal moments
across voices/staves.
Hence, in combination with accidentals, the current approach leads to
ugly things like
\version "2.19.82"
<<
\new Staff { \grace a'8 gis'2 }
\new Staff { \grace dis'8 e'2 }
>>
(which I encountered quite a lot when engraving, for instance, examples
from Mozart chamber music).
My standard workaround is to allow LilyPond to use two different points
in grace time:
\version "2.19.82"
<<
\new Staff { \grace a'8 gis'2 }
\new Staff { \grace dis'8*1/2 e'2 }
>>
But that's also not ideal, firstly from a semantic point of view,
secondly because the visual outcome depends on the chosen factor, while
I basically want Lily to put the grace not "as close as
possible/graphically sensible" to the main note.
Best
Lukas
Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]
On Fri, Feb 7, 2020 at 2:46 PM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi all, > > Here’s the brainstorm I’ve currently got going: > > Issue #34, a.k.a. the grace note bug, is one of Lilypond’s > longest-standing and most newbie-unfriendly issues. It doesn’t appear in > single-staff scores, obviously — only in multi-staff scores where one staff > has a grace note [in the note code] and one or more other staves don’t. > > So… > > Can Someone™ write a Scheme engraver that listens for grace events and > automagically adds grace skips of equal duration at the same moment in all > other staves of a given score? *Intuitively*, \consist-ing that engraver > into a score sounds to me like the perfect (Band-Aid™?) solution, modulo > what is apparently a very difficult and/or time-consuming recoding of some > deep fundamentals in Lilypond’s timing codebase. > > Let me know if I’m just talking nonsense. > If not, let me know how I can help make this "fix" a reality > Unfortunately, it's not obvious where to insert the skips. Consider this staff1 : grace 16th, whole note staff2 : X, whole note now, if X is a \clef, you probably want to insert the skip after the X, but if X is a \once \override for the NoteHead, adding a skip after X will make it inoperable. I fear this is essentially unsolvable in the current model. I think the right solution would be to kill grace timing altogether, and initiate some sort special "embedded" engraving pass that creates the Grace grobs all at once. That would have another downside: if we construct the grace note grobs in a special pass, there is nothing to synchronize them across staves. You could have two-handed piano music where the left and right hand do grace notes in a synchronized way. I don't if that exists in practice, but it is one of the reasons for the current approach. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]
Am Fr., 7. Feb. 2020 um 14:46 Uhr schrieb Kieren MacMillan : > > Hi all, > > Here’s the brainstorm I’ve currently got going: > > Issue #34, a.k.a. the grace note bug, is one of Lilypond’s longest-standing > and most newbie-unfriendly issues. It doesn’t appear in single-staff scores, > obviously — only in multi-staff scores where one staff has a grace note [in > the note code] and one or more other staves don’t. > > So… > > Can Someone™ write a Scheme engraver that listens for grace events and > automagically adds grace skips of equal duration at the same moment in all > other staves of a given score? *Intuitively*, \consist-ing that engraver into > a score sounds to me like the perfect (Band-Aid™?) solution, modulo what is > apparently a very difficult and/or time-consuming recoding of some deep > fundamentals in Lilypond’s timing codebase. > > Let me know if I’m just talking nonsense. > If not, let me know how I can help make this "fix" a reality. > > Thanks, > Kieren. > > > Kieren MacMillan, composer (he/him/his) > ‣ website: www.kierenmacmillan.info > ‣ email: i...@kierenmacmillan.info > > Hi Kieren, although I did not try, I can't imagine an engraver could work. Though, maybe checkout the link given here https://sourceforge.net/p/testlilyissues/issues/34/?page=1=25#2eca Cheers, Harm
Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]
Kieren MacMillan writes:
> Hi all,
>
> Here’s the brainstorm I’ve currently got going:
>
> Issue #34, a.k.a. the grace note bug, is one of Lilypond’s
> longest-standing and most newbie-unfriendly issues. It doesn’t appear
> in single-staff scores, obviously — only in multi-staff scores where
> one staff has a grace note [in the note code] and one or more other
> staves don’t.
>
> So…
>
> Can Someone™ write a Scheme engraver that listens for grace events and
> automagically adds grace skips of equal duration at the same moment in
> all other staves of a given score? *Intuitively*, \consist-ing that
> engraver into a score sounds to me like the perfect (Band-Aid™?)
> solution, modulo what is apparently a very difficult and/or
> time-consuming recoding of some deep fundamentals in Lilypond’s timing
> codebase.
>
> Let me know if I’m just talking nonsense.
> If not, let me know how I can help make this "fix" a reality.
Well, the problem is that there is no "grace event" but a grace iterator.
Now this this characterization is not entirely true any more since
commit 99a85ca39f3a7a6f717ba06a48ef0ba70f842177
Author: David Kastrup
Date: Wed Oct 1 19:39:08 2014 +0200
Issue 630/4: Let Grace_engraver react mostly to GraceChange events
When GraceChange events are not available, this reverts to grace processing
at initialization or at the engraver's process_music call.
which is used for the fine-grained synchronisation required for having
\override ... \grace { \override ...
decide in which order to execute overrides that have different
consequences in the \grace construct in spite of being executed at the
same "musical time" as the overrides outside. However, those
GraceChange events are not likely amenable for fixing issue 34, in
particular since the case alluded to in the commit message where they
are not yet operative is _exactly_ the issue 34 case.
Basically what I think is needed is the Sequential_iterator having a
means of conveying information about its grace_fixup structures to the
Simultaneous_iterator. The various approaches I have experimented with
occasionally over the years have not worked for that, sometimes without
me able to understand why.
--
David Kastrup
