Re: Carry multi-measure rests across voices in \partcombine (issue 265410043 by address@hidden)

[dak]

On 2015/10/10 00:36:04, Dan Eble wrote:
> On 2015/10/09 06:55:02, dak wrote:

> > We don't pass Moment by reference.  It's a simple scalar type and
references
> > reached via unsmob are rarely guaranteed to survive for long.

> I'll change it to pass by value, though I don't understand why passing
> by reference is a problem.  When passed by value, the Moment will only
> survive for the duration of the call.  Do you mean that a Moment
> passed by reference might not survive even that long?

If garbage collection happens because of an allocation in that call, yes
that may happen.  With get_property there is a good chance that a
callback call will be _cached_ in which case the caching will provide
protection from garbage protection.  But that's rather hand-wavy.

> Moments are 40 bytes (in Lilydev 3) which seems a bit large to pass by
> value, but I'm speaking from experience that mostly involves limited
> memory or high performance.


> > Why not keep the code for dealing with this in the part combiner and
make the
> > Multi_measure_rest_engraver just do what is expected from it?

> Can you be more specific?  The first interpretation that comes to my
> mind is that you want the part combiner to rewrite multi-measure rest
> events in the input so that they are divided at the moments where the
> parts need to be swapped to other voice contexts.  Then the MMR
> engraver would need to do nothing special.  The PC iterator would not
> even need to "kill" MMRs because they would already be the right
> length.  But rewriting the input parts would be a significant change.

But a change happening at an obvious place and not relying on some
behind-the-scenes magic in a place where it's sort of unexpected.

> > It seems like a strange deal to maintain an engraver-specific
property in a
> > context property.  Most of the time, such variables are kept inside
the
> > engraver.

> Can you provide an example of an iterator getting state from an
engraver?

Should it be getting state from an engraver?  To answer your question
literally (I doubt that this example makes a lot of sense for your
application) Grace_engraver is an example of an engraver talking with an
iterator though in that case the purpose is to synchronize engraver
action to iterator action (iterators fire in well-defined order even
when at the same time step, and that's needed here).

Having an iterator look at context properties is a so-so communication
path, and part of the reason is that changes and inspection happening at
the same time step render things tricky.

> > Stupid question: would the partcombiner work better by having a
context
> > PartCombinePart accepted by Voice, and then we use \change Voice =
"soloII"
> and
> > similar in the two original parts?  Or would it make more sense to
put
> something
> > like PartCombinePart between Staff and Voice and run the original
stuff in
> > Voice, using \change PartCombinePart = "soloII" and so on?  One of
those might
> > lead to a reasonably natural way of dealing with slurs and stuff.

> I experimented with those ideas several months ago and could not find
> a reasonable solution.

I have to think about what you wrote here.  This was just labelled "food
for thought" and if there are only some "oh, all that would be needed to
make this work would be if LilyPond did $x" impediments, it might be
worth in the long run to let it do $x.  However, this is not immediately
pertinent to this review, it just made me think of it.




https://codereview.appspot.com/265410043/