Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)
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?
https://codereview.appspot.com/581600043/
Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)
On Fri, Feb 7, 2020 at 4:43 PM wrote:
> On 2020/02/07 09:19:03, hanwenn wrote:
> > On 2020/02/06 14:29:55, Dan Eble wrote:
> > More code means more maintenance liability, so unless
> > it either solves a problem, or it simplifies the existing system, it
> would be a
> > net negative.
>
> You're preaching to the choir.
>
Thanks; sorry for the lecture.
> I would really like the problem defined before we try solving it.
> [...]
> > I hope I am not demoralizing you
>
> It's a good thing you threw in that last part, because from over here it
> was sounding rather like you resented my posting this for review. I'll
> try to keep my reply descriptive.
>
I was confused by the review, because it both claims to be experimental
("maybe never"), but also asks questions that are only relevant if this is
going to be a bona fide feature (editor configs, naming). The latter part
motivated the lecture.
I have seen that mailing-list discussions on detailed design--even for
> features people recognize they need, but especially for those they
> don't--do not go far or fast. I suppose it's because few people have
> the level of familiarity, the current interest, or the time to devote to
> written communication on those topics. I'm not blaming them; it's just
> my diagnosis. Posting a review gives them something concrete to comment
> on, and that gets a discussion going.
>
> I have the sense that most of my successful contributions have gone this
> way. Is this approach as effective as one that might be taken by a
> professional software development team? No, but my code is in LilyPond.
> Are the factors that make this the most effective approach in this
> context going to change? Not likely.
>
You have a good point, but hopefully, I will be able to make enough time to
comment on technical feasibility so design questions can get better answers
henceforth.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)
On 2020/02/07 15:43:30, Dan Eble wrote: > On 2020/02/07 09:19:03, hanwenn wrote: > > On 2020/02/06 14:29:55, Dan Eble wrote: > > More code means more maintenance liability, so unless > > it either solves a problem, or it simplifies the existing system, it would be > a > > net negative. > > You're preaching to the choir. > > > I would really like the problem defined before we try solving it. > [...] > > I hope I am not demoralizing you > > It's a good thing you threw in that last part, because from over here it was > sounding rather like you resented my posting this for review. I'll try to keep > my reply descriptive. > > I have seen that mailing-list discussions on detailed design--even for features > people recognize they need, but especially for those they don't--do not go far > or fast. I suppose it's because few people have the level of familiarity, the > current interest, or the time to devote to written communication on those > topics. I'm not blaming them; it's just my diagnosis. Posting a review gives > them something concrete to comment on, and that gets a discussion going. > > I have the sense that most of my successful contributions have gone this way. > Is this approach as effective as one that might be taken by a professional > software development team? No, but my code is in LilyPond. Are the factors > that make this the most effective approach in this context going to change? Not > likely. > > > I hope I am not demoralizing you > > Well, it's a dilemma: friction either way. I spent an hour composing this > reasoned reply. What I was hoping for was any of the following kinds of > feedback. Looking past the little lecture on process, I see some of them > starting to come through; so, thank you. > > 1. pointers to potential applications (thanks, David et al.) > 2. The implementation looks sane, but I can't think of a place we would use this > currently. I think you should ping us when your experiments with it are more > mature. > 3. I haven't looked at the implementation, but I can't think of a place we would > use this currently. I think you should ping us when your experiments are more > mature. > 4. You can approximate this already with X; would that work for you? > 5. Speaking as a user, I'm not sure where I'd apply this, but calling it X would > be more appropriate. > 6. This is fantastic! I've been working around not having this for decades! Well, the problem is that this triggers some actions at a comparatively obscure time. As Han-Wen quite correctly states, that doesn't seem like something an end-user might need, and as omnipotent developers, if we needed that kind of functionality in some specific purpose, we could access it in C++. But that doesn't mean that it might not solve some task that a power-user, the growing breed of users working wonders in Scheme, might solve as part of a larger package. Would any such task benefit from clearer or different semantics? It's really hard to know. https://codereview.appspot.com/581600043/
Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)
On 2020/02/07 09:19:03, hanwenn wrote: > On 2020/02/06 14:29:55, Dan Eble wrote: > More code means more maintenance liability, so unless > it either solves a problem, or it simplifies the existing system, it would be a > net negative. You're preaching to the choir. > I would really like the problem defined before we try solving it. [...] > I hope I am not demoralizing you It's a good thing you threw in that last part, because from over here it was sounding rather like you resented my posting this for review. I'll try to keep my reply descriptive. I have seen that mailing-list discussions on detailed design--even for features people recognize they need, but especially for those they don't--do not go far or fast. I suppose it's because few people have the level of familiarity, the current interest, or the time to devote to written communication on those topics. I'm not blaming them; it's just my diagnosis. Posting a review gives them something concrete to comment on, and that gets a discussion going. I have the sense that most of my successful contributions have gone this way. Is this approach as effective as one that might be taken by a professional software development team? No, but my code is in LilyPond. Are the factors that make this the most effective approach in this context going to change? Not likely. > I hope I am not demoralizing you Well, it's a dilemma: friction either way. I spent an hour composing this reasoned reply. What I was hoping for was any of the following kinds of feedback. Looking past the little lecture on process, I see some of them starting to come through; so, thank you. 1. pointers to potential applications (thanks, David et al.) 2. The implementation looks sane, but I can't think of a place we would use this currently. I think you should ping us when your experiments with it are more mature. 3. I haven't looked at the implementation, but I can't think of a place we would use this currently. I think you should ping us when your experiments are more mature. 4. You can approximate this already with X; would that work for you? 5. Speaking as a user, I'm not sure where I'd apply this, but calling it X would be more appropriate. 6. This is fantastic! I've been working around not having this for decades! https://codereview.appspot.com/581600043/
Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)
On Fri, Feb 7, 2020 at 1:34 PM wrote:
> On 2020/02/07 09:19:03, hanwenn wrote:
>
> > David mentions \cadenzaOff in the issue tracker. I think you could fix
> the
> > behavior inside the Timing_engraver without requiring a new construct
> (although,
> > if we did this, we'd probably upset bar numbering across existing
> scores.)
>
> I think I tried. At any rate, I was not proposing to change existing
> \cadenzaOff functionality since that has clearly defined semantics. 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
>#})
>
it depends on what precisely it you want to achieve if you want with "end
cadenza and bar".
Looking at timing-translator.cc, the easiest hack would be to set
measurePosition to measureLength - duration-of-note. This means you have to
execute some scheme to retrieve the measureLength at the time. But it might
be fragile if you meddle with timing if there are multiple staves.
If changing C++ (which the change under review also does) is on the table,
it would probably be easier to simply detect the 'timing going from #f to
#t and reset measurePosition directly in C++.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)
On 2020/02/07 09:19:03, hanwenn wrote:
> David mentions \cadenzaOff in the issue tracker. I think you could fix
the
> behavior inside the Timing_engraver without requiring a new construct
(although,
> if we did this, we'd probably upset bar numbering across existing
scores.)
I think I tried. At any rate, I was not proposing to change existing
\cadenzaOff functionality since that has clearly defined semantics. 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 hope I am not demoralizing you; by getting this working, you show
mastery of
> advanced LilyPond internals, which is a great achievement!
https://codereview.appspot.com/581600043/
Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)
On 2020/02/06 14:29:55, Dan Eble wrote: > The reviewers are turning the first question I asked around and asking it back > to me. I don't know if this is useful without other stuff I've been working on. > That's why I've posted it for review. I thought that you (well, mainly I > thought that David K.) might know of some corner of LilyPond where delaying a > \set (or similar thing) until the end of the current time step would be useful. Sorry for turning the question back, but I would really like the problem defined before we try solving it. More code means more maintenance liability, so unless it either solves a problem, or it simplifies the existing system, it would be a net negative. The description says: change something at the end of the timestep. For almost all properties (and in particular for the fingeringOrientations which your example uses), changing it at the end of the current timestep is equivalent to changing it at the start of the next, which is functionality we already have. Also, if you really wanted this, couldn't you embed the property in a Music expression, and then have an engraver catch that expression, and then execute the property assignment at its stop_translation_timestep() ? You could even do that in a scheme engraver. David mentions \cadenzaOff in the issue tracker. I think you could fix the behavior inside the Timing_engraver without requiring a new construct (although, if we did this, we'd probably upset bar numbering across existing scores.) I hope I am not demoralizing you; by getting this working, you show mastery of advanced LilyPond internals, which is a great achievement! https://codereview.appspot.com/581600043/
Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)
On 2020/02/06 14:29:55, Dan Eble wrote: > The reviewers are turning the first question I asked around and asking it back > to me. I don't know if this is useful without other stuff I've been working on. > That's why I've posted it for review. I thought that you (well, mainly I > thought that David K.) might know of some corner of LilyPond where delaying a > \set (or similar thing) until the end of the current time step would be useful. I remember very faintly (incorrectly???) that many years ago I had a problem of doing something at the last point in time, as points of time could be deduced only from the beginning of durations, not from the end of those; if that is so (or if there are cases when determining a point of time is more natural as the end of a duration than as the beginning of another one), \post is definitely useful. Another conceivable meaning is, used together with \once: "tweak something, and when it finished, tweak something else" (may perhaps be useful when pasting music from tiny fragments or using a complex hierarchy of music functions). This meaning would perhaps be - expressed better with \next (or \then? is it reserved?) than \post; - supported better if \once and \post could be iterated like if .. else if .. else, i.e. if \once \set \post \once \set \post \set ... meant \set \set \set ... but as the new set-once-post.ly regtest shows, this is not how it works with this patch. https://codereview.appspot.com/581600043/
Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)
Reviewers: thomasmorley651, hanwenn, Message: The reviewers are turning the first question I asked around and asking it back to me. I don't know if this is useful without other stuff I've been working on. That's why I've posted it for review. I thought that you (well, mainly I thought that David K.) might know of some corner of LilyPond where delaying a \set (or similar thing) until the end of the current time step would be useful. 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? Please review this at https://codereview.appspot.com/581600043/ Affected files (+234, -21 lines): A input/regression/set-once-post.ly A input/regression/set-post.ly M lily/apply-context-iterator.cc M lily/context.cc M lily/context-scheme.cc M lily/global-context.cc M lily/include/context.hh M lily/include/global-context.hh M lily/include/lily-imports.hh M lily/lily-imports.cc M lily/property-iterator.cc M ly/music-functions-init.ly M scm/define-context-properties.scm M scm/define-music-properties.scm
Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)
I haven't looked in detail at the code, but I couldn't work out why you want to add this, and that is probably the most important piece of information to decide how to best go about implementing it. >From a cursory reading, you want to set a context property at a specific point in the engraver mechanics, is that right? Could you add a couple of situations where this is useful? The description of the feature sounds very interlinked with details of the engraving process, which makes it suspect as a user-level feature. If we write a description of this in the manual, how many people will there be that understand what the "end of time step" means? If this is intended for advanced usage, shouldn't we rather think of a way to expose this as a Scheme programming construct? I'm also a little worried that this is making change to central places (eg. global-context.cc), whereas I would expect a niche feature to only make changes to niches in the code base. https://codereview.appspot.com/581600043/
Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)
Hi Dan, I've difficulties to understand what this is about. And my lack of C++-knowledge hinders my to deduce it. Could you give a ly-code-example which is not possible with current possibilities or where using current possibilities leads to some uglyness? https://codereview.appspot.com/581600043/
