Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(1470)

Issue 581600043: Issue 5740: Add \post to defer context actions to end of time step

Can't Edit
Can't Publish+Mail
Start Review
Created:
5 months ago by Dan Eble
Modified:
4 months, 1 week ago
CC:
lilypond-devel_gnu.org
Visibility:
Public.

Description

https://sourceforge.net/p/testlilyissues/issues/5740/ 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?

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+234 lines, -21 lines) Patch
A input/regression/set-once-post.ly View 1 chunk +42 lines, -0 lines 0 comments Download
A input/regression/set-post.ly View 1 chunk +23 lines, -0 lines 0 comments Download
M lily/apply-context-iterator.cc View 1 chunk +11 lines, -4 lines 0 comments Download
M lily/context.cc View 5 chunks +67 lines, -7 lines 0 comments Download
M lily/context-scheme.cc View 1 chunk +13 lines, -0 lines 0 comments Download
M lily/global-context.cc View 2 chunks +20 lines, -4 lines 0 comments Download
M lily/include/context.hh View 4 chunks +10 lines, -1 line 0 comments Download
M lily/include/global-context.hh View 1 chunk +9 lines, -1 line 0 comments Download
M lily/include/lily-imports.hh View 1 chunk +1 line, -0 lines 0 comments Download
M lily/lily-imports.cc View 1 chunk +1 line, -0 lines 0 comments Download
M lily/property-iterator.cc View 4 chunks +6 lines, -2 lines 0 comments Download
M ly/music-functions-init.ly View 1 chunk +24 lines, -0 lines 0 comments Download
M scm/define-context-properties.scm View 2 chunks +6 lines, -2 lines 0 comments Download
M scm/define-music-properties.scm View 1 chunk +1 line, -0 lines 0 comments Download

Messages

Total messages: 11
thomasmorley651
Hi Dan, I've difficulties to understand what this is about. And my lack of C++-knowledge ...
5 months ago (2020-02-05 23:11:39 UTC) #1
hanwenn
I haven't looked in detail at the code, but I couldn't work out why you ...
5 months ago (2020-02-06 09:28:20 UTC) #2
Dan Eble
The reviewers are turning the first question I asked around and asking it back to ...
5 months ago (2020-02-06 14:29:55 UTC) #3
benko.pal
On 2020/02/06 14:29:55, Dan Eble wrote: > The reviewers are turning the first question I ...
5 months ago (2020-02-07 08:45:53 UTC) #4
hanwenn
On 2020/02/06 14:29:55, Dan Eble wrote: > The reviewers are turning the first question I ...
5 months ago (2020-02-07 09:19:03 UTC) #5
dak
On 2020/02/07 09:19:03, hanwenn wrote: > David mentions \cadenzaOff in the issue tracker. I think ...
5 months ago (2020-02-07 12:34:38 UTC) #6
hanwenn
On Fri, Feb 7, 2020 at 1:34 PM <dak@gnu.org> wrote: > On 2020/02/07 09:19:03, hanwenn ...
5 months ago (2020-02-07 12:58:07 UTC) #7
Dan Eble
On 2020/02/07 09:19:03, hanwenn wrote: > On 2020/02/06 14:29:55, Dan Eble wrote: > More code ...
5 months ago (2020-02-07 15:43:30 UTC) #8
dak
On 2020/02/07 15:43:30, Dan Eble wrote: > On 2020/02/07 09:19:03, hanwenn wrote: > > On ...
5 months ago (2020-02-07 16:00:48 UTC) #9
hanwenn
On Fri, Feb 7, 2020 at 4:43 PM <nine.fierce.ballads@gmail.com> wrote: > On 2020/02/07 09:19:03, hanwenn ...
5 months ago (2020-02-07 16:03:38 UTC) #10
Dan Eble
4 months, 1 week ago (2020-03-06 03:21:01 UTC) #11
On 2020/02/07 12:34:38, dak wrote:
But it has
> evaded me to find a way of expressing "end cadenza and bar".  The best I could
> do so far could be expressed as
> 
> \cadenzaOffAfter =
> #(define-music-function (last-note) (ly:music?)
>    #{ \partial #(ly:music-duration 1 0 (ly:moment-main (ly:music-length
> lastnote)))
>       #last-note
>    #})
> 
> But that's really somewhat inconvenient.

I spent a little time looking at \cadenzaOff and I think there might be some
hope for shaping \post into something helpful.  Currently, when we write this:

    a1 \cadenzaOff | b2

we get the property change during the timestep in which b2 starts.  Part of the
reason that using this to create a new measure at the end of a cadenza is
ineffective is that this change to the "timing" property comes after certain
translators have already inspected "timing" at the beginning of the timestep and
behaved as if the cadenza continues.  If we could move the property change back
to the end of the previous time step, I think it would help.

The initial proposal for \post queues up a property change for the end of the
current time step.  What if \post instead queued up the property change for "as
late as possible before time t" where t is derived from the preceding note (or
chord, rest, or skip), i.e.,

    a1 \post \cadenzaOff | b2

would change the "timing" property at the instant that a ends, which is before b
begins.  Where one wants to deal with the current time step, s1*0 \post \set ...
would probably be a way.  Does it seem that it would be worth toying with that?

P.S. Does anyone happen to know if the edition engraver has trouble referencing
points in a cadenza?
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b