Re: For those who need new features and bug fixes...

[David Kastrup]

"address@hidden" <address@hidden> 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