Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?

Trevor Bača-2
Hi,

For many years, one of the clearest functional gaps in LilyPond was the
limitation that voices allow only a single text spanner at a time. Very
many scores of recent decades notate two musical parameters changing at the
same time: a passage of string music moving ponticello -> tasto while at
the same time decreasing from vibrato molto -> non vibrato, for example.
Arrowed lines are the nearly universal way of notating such things,
available in LilyPond as text spanners; but to allow for what now counts as
newly emerged common practice, an arbitrary number of text spanners need to
be allowed per voice.

Lily users have asked for the feature for a long time. Here's an example
from 2009:

http://lists.gnu.org/archive/html/lilypond-user/2009-11/msg00031.html

By 2015, the idea of spanner-id had been added to LilyPond to allow for
this type of functionality. But despite the name of the property ("will
spanner-id allow for ALL types of spanner to overlap?"), integration first
centered on slurs and phrasing slurs. Here's a thread from 2015 with David
K. working to allow an input syntax for those first two types of spanner:

http://lists.gnu.org/archive/html/lilypond-user/2015-10/msg00157.html

At that same time in 2015, however, David N. had in fact rewritten Lily's
Text_spanner_engraver to integrate spanner-id, and hence supply the missing
functionality. David N.'s attachment (given later in the same thread listed
above) gives the necessary code:

http://lists.gnu.org/archive/html/lilypond-user/2015-10/msg00545.html

Last year, in May 2018, I finally integrated David N.'s
alternateTextSpannerEngraver into my own work, using it to replace Lily's
default Text_spanner_engraver completely. The results have been extremely
good: *David N.'s alternateTextSpannerEngraver performs exactly the same as
the current Text_spanner_engraver but with the additional flexibility of
being able to define (and use) arbitrarily many types of text spanner in a
single voice.*

So, it looks like David N.'s alternateTextSpannerEngraver supplies a piece
of functionality that's been missing in LilyPond since inception, which is
fantastic.

Question: is it now possible to replace Text_spanner_engraver with David
N.'s extended implementation, in a coming public release of LilyPond?


Trevor.

--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?

James Lowe-3
Hello Trevor,

On Tue, 12 Feb 2019 16:45:35 -0600, Trevor Bača <[hidden email]> wrote:


>
> Question: is it now possible to replace Text_spanner_engraver with David
> N.'s extended implementation, in a coming public release of LilyPond?
>
>
> Trevor.
>


If you have a patch based on current master I can at least test that for you.]

James



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?

Trevor Bača-2
On Wed, Feb 13, 2019 at 4:58 AM James Lowe <[hidden email]> wrote:

> Hello Trevor,
>
> On Tue, 12 Feb 2019 16:45:35 -0600, Trevor Bača <[hidden email]>
> wrote:
>
>
> >
> > Question: is it now possible to replace Text_spanner_engraver with David
> > N.'s extended implementation, in a coming public release of LilyPond?
> >
> >
> > Trevor.
> >
>
>
> If you have a patch based on current master I can at least test that for
> you.]
>
> James
>

Hi James,

I have no patch.

Could somebody else possibly provide James a patch of David N.'s
alternateTextSpannerEngraver?

Trevor.


--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?

David Kastrup
David Nalesnik <[hidden email]> writes:

> On Wed, Feb 13, 2019 at 7:49 AM Trevor Bača <[hidden email]> 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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?

David Kastrup
David Nalesnik <[hidden email]> writes:

> David,
>
> On Wed, Feb 13, 2019 at 8:35 AM David Kastrup <[hidden email]> wrote:
>>
>> David Nalesnik <[hidden email]> writes:
>>
>> > On Wed, Feb 13, 2019 at 7:49 AM Trevor Bača <[hidden email]> 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++?
>>
> Ah, OK, thanks for the update.  I must be thinking of a past state of affairs.

commit df854ae456ad2e57139ddcb345760b4c321e1cbb
Author: David Kastrup <[hidden email]>
Date:   Sat Jan 28 01:16:54 2017 +0100

    Issue 1375/3: Register scheme engravers
   
    This registers Measure_counter_engraver and Span_stem_engraver
    to make them documented and callable like C++ engravers.

commit 6887546c5caf87cdc94252c020f39b43a57bf057
Author: David Kastrup <[hidden email]>
Date:   Tue Jun 16 14:14:27 2015 +0200

    Issue 1375/2: Create Translator_creator class
   
    Previously, translators were created by copying from a context-less
    instantiation of the translator containing its documentation.  This had
    several unpleasant consequences, the most problematic likely being the
    inability to register Scheme engravers because their documentation would
    be identical to all other Scheme engravers.
   
    A new Translator_creator class takes over the task of creating
    Translator instances when called with a context argument.
   
    As a result of joining the mechanisms for Scheme engravers and C++
    engravers, ly:translator-name and ly:translator-description are
    reimplemented in a manner resembling object properties.

commit 6d1c5d25389afa6dbbfb4722df3732e764cbbf2e
Author: David Kastrup <[hidden email]>
Date:   Fri Jan 27 13:27:03 2017 +0100

    Issue 1375/1: Let Translator constructor take a Context argument
   
    This is the first step towards constructing rather than cloning translators
    when creating contexts.  On its own, it does not make sense, but the change
    is large and mostly mechanical, so keeping it separate from the actually
    difficult parts makes sense.

This is not even yesteryear's news but yonderyesteryear's news.  Not
that 2 years are a lot of time at the current development speed.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel