Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ballads@gmail.com)

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

Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ballads@gmail.com)

Thomas Morley-2
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/

Reply | Threaded
Open this post in threaded view
|

Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ballads@gmail.com)

Han-Wen Nienhuys-3
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/

Reply | Threaded
Open this post in threaded view
|

Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ballads@gmail.com)

nine.fierce.ballads
In reply to this post by Thomas Morley-2
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



Reply | Threaded
Open this post in threaded view
|

Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ballads@gmail.com)

benko.pal
In reply to this post by Thomas Morley-2
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 <tweak1> \post \once \set <tweak2> \post \set <tweak3>
<note1> <note2> ...

meant

\set <tweak1>
<note1>
\set <tweak2>
<note2>
\set <tweak3>
...


but as the new set-once-post.ly regtest shows, this is not how it works
with this patch.

https://codereview.appspot.com/581600043/

Reply | Threaded
Open this post in threaded view
|

Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ballads@gmail.com)

Han-Wen Nienhuys-3
In reply to this post by Thomas Morley-2
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/

Reply | Threaded
Open this post in threaded view
|

Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ballads@gmail.com)

David Kastrup
In reply to this post by Thomas Morley-2
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/

Reply | Threaded
Open this post in threaded view
|

Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ballads@gmail.com)

Han-Wen Nienhuys-3
On Fri, Feb 7, 2020 at 1:34 PM <[hidden email]> 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 - [hidden email] - http://www.xs4all.nl/~hanwen
Reply | Threaded
Open this post in threaded view
|

Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ballads@gmail.com)

nine.fierce.ballads
In reply to this post by Thomas Morley-2
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/

Reply | Threaded
Open this post in threaded view
|

Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ballads@gmail.com)

David Kastrup
In reply to this post by Thomas Morley-2
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/

Reply | Threaded
Open this post in threaded view
|

Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ballads@gmail.com)

Han-Wen Nienhuys-3
In reply to this post by nine.fierce.ballads
On Fri, Feb 7, 2020 at 4:43 PM <[hidden email]> 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 - [hidden email] - http://www.xs4all.nl/~hanwen