"Dan Eble" <e...@users.sourceforge.net> writes:

> The implementation of \post is similar to the way \once reverts an
> effect at the end of the time step.  In fact, I first implemented it
> the same way for the sake of simplicity; but after testing, I decided
> to complicate it.  \once reversions naturally occur in reverse order,
> but it seems more natural for \post actions to run in the order given
> in the ly code.  It also seems more natural for all \once reversions
> to precede all \post actions regardless of their order in the ly code.
> Because of those differences, they are handled separately.

Does it work like once, setting a property on a stream event?  That
would seem important for quoted music and the part combiner.

>
> TODOs and questions:
>
> * Is \post per se worthy to be merged, or should I wait until the
>   whole group of post-increment features is ready, which is possibly
>   much later or never?  It would be easier for me to finish \post and
>   merge it so that I have less to rebase on a regular basis.  Can you
>   think of places that \post would be useful right now?
>
> * Test coverage is insufficient.  I've provided a few cases to show
>   the basic idea.
>
> * Are there editor configs that I need to update to say that \post is
>   a built-in command?  Other similar things?
>
> * Should this be called \post, \atEndOfTimeStep, or something else?

Not yet have a good feeling for it.  One application I can think of may
be the end of a \cadenza coinciding with a new bar start.  \partial 0*1
does not work for that and it's super awkward to get this to work.
Maybe that tool could help?

-- 
David Kastrup


---

** [issues:#5740] Add \post to defer context actions to end of time step**

**Status:** Started
**Created:** Wed Feb 05, 2020 08:11 PM UTC by Dan Eble
**Last Updated:** Wed Feb 05, 2020 08:15 PM UTC
**Owner:** Dan Eble


I've carved this off of some experimental work that allows expressing
in ly code the post-increment of a context property without
sensitivity to the number of times the music that requests it is
iterated.  That is something that the rehearsal-mark engraver does,
and I believe it can only be done currently by an engraver/performer.

The implementation of \post is similar to the way \once reverts an
effect at the end of the time step.  In fact, I first implemented it
the same way for the sake of simplicity; but after testing, I decided
to complicate it.  \once reversions naturally occur in reverse order,
but it seems more natural for \post actions to run in the order given
in the ly code.  It also seems more natural for all \once reversions
to precede all \post actions regardless of their order in the ly code.
Because of those differences, they are handled separately.

TODOs and questions:

* Is \post per se worthy to be merged, or should I wait until the
  whole group of post-increment features is ready, which is possibly
  much later or never?  It would be easier for me to finish \post and
  merge it so that I have less to rebase on a regular basis.  Can you
  think of places that \post would be useful right now?

* Test coverage is insufficient.  I've provided a few cases to show
  the basic idea.

* Are there editor configs that I need to update to say that \post is
  a built-in command?  Other similar things?

* Should this be called \post, \atEndOfTimeStep, or something else?

https://codereview.appspot.com/581600043


---

Sent from sourceforge.net because testlilyissues-a...@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/testlilyissues/issues/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/testlilyissues/admin/issues/options.  Or, if this is 
a mailing list, you can unsubscribe from the mailing list.
_______________________________________________
Testlilyissues-auto mailing list
testlilyissues-a...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
  • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
    • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
    • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
    • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
    • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
    • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
    • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
    • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development

Reply via email to