"m...@mikesolomon.org" <m...@mikesolomon.org> writes: > My goal is not to prepend an extra mechanism because the current one > fails.
It does not really matter what you call your goal with respect to issue 34 as long as this is going to be what you are doing. With respect to graces, we actually need different mechanisms for typesetting and midi as far as I can see. Midi happens in absolute time, and grace notes need to get expanded into the appropriate time, and then sorted into time-linearity again. In contrast, grace notes in typesetting are usually _not_ aligned. An appoggiatura comes _on_ the beat, with the main note following it without additional spacing, acciaccature come _before_ the beat. We should really only have one NoteColumn per _main_ time (and not on grace times), and in the case of appoggiature, it should align on the appoggiatura itself, whereas for normal grace notes and acciaccature, it should align on the main note. In either case, grace notes and main notes should be next to each other without doing _any_ NoteColumn kind of alignment for vertically aligning material within the grace timing. Visual grace alignment is really a thing that should be per-voice. It may be nice to have a "Grace_alignment_engraver" which you can call in at higher level such as Staff optionally (to synchronize graces for potentially multi-voice instruments). But by default I don't think they should be aligned. > My goal is to come up with a systematic way to automate choices before > information gets passed to the engravers. The most problematic > engravers, in my opinion, are currently the ones that try to do this > type of automation task: Auto_beam, Completion_note, and > Completion_rest. This is because they cannot peak ahead in time and > go backwards, resulting in their either making poor engraving choices > or issuing events later in time, which causes problems for the > identification of cross-staff grobs. The solution is to come up with > a stable Scheme object - MusicFilter (or whatever) - and chain these > things together, passing the input stream through them before the > engraver stage. That's nice, but issue 34 is the wrong motivation for it. Even though it is conceivable that one might _redesign_ the grace treatment using it at some point of time. But what you are currently thinking of (and what is the only thing one could reasonably hope to do in such a short time frame) is patching it up. And that's really going to turn a buggy complex mess into a more complex buggy mess. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
