lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can alternateTextSpannerEngraver now completely replace Text_spanner


From: Trevor Bača
Subject: Re: Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?
Date: Wed, 13 Feb 2019 09:05:17 -0600

On Wed, Feb 13, 2019 at 8:35 AM David Kastrup <address@hidden> wrote:

> David Nalesnik <address@hidden> writes:
>
> > On Wed, Feb 13, 2019 at 7:49 AM Trevor Bača <address@hidden>
> wrote:
> >>
> >> Could somebody else possibly provide James a patch of David N.'s
> >> alternateTextSpannerEngraver?
> >>
> >> Trevor.
> >
> > The issue which would come up is that it is written in Scheme, rather
> > than C++.  This has implications for documentation.
>
> It does?  What kind of documentation cannot be achieved in Scheme that
> would be possible in C++?
>
> Here is some page from the Internals reference:
>
>     File: lilypond-internals.info,  Node: Merge_rests_engraver,  Next:
> Metronome_mark_engraver,  Prev: Mensural_ligature_engraver,  Up: Engravers
> and Performers
>
>     2.2.71 Merge_rests_engraver
>     ---------------------------
>
>     Engraver to merge rests in multiple voices on the same staff.  This
>     works by gathering all rests at a time step.  If they are all of the
>     same length and there are at least two they are moved to the correct
>     location as if there were one voice.
>
>        Properties (read)
>
>          ‘suspendRestMerging’ (boolean)
>               When using the Merge_rest_engraver do not merge rests when
>               this is set to true.
>
>        ‘Merge_rests_engraver’ is not part of any context.
>
>
> This is an engraver written in Scheme.
>
> --
> David Kastrup
>

Thank you both (David and David) so much for engaging on this last step!
Truly wonderful; and if I can just chime in one last time while you are
thinking through the problem: I *think* (not 100% certain, but close to it)
that the ideal final implementation path would be not just to add
alternateTextSpannerEngraver as, say, Alternate_text_spanner_engraver, but
rather to *replace* the existing Text_spanner_engraver with (the
implementation of) alternateTextSpannerEngraver. I think this was clear in
my previous mail, but I just wanted to insert one last time here as the
question of Scheme-vs-C++ final resting spot gets considered.


Trevor.


-- 
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca


reply via email to

[Prev in Thread] Current Thread [Next in Thread]