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

[nine . fierce . ballads]

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?

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.


> 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?


> 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.  (That's not to say one doesn't exist.)  A
problem with having a new context below Voice is that things
expecting Bottom to be Voice would work differently.  A problem with
having a new context above Voice is that you start wanting to move
engravers from Voice to it (as I recall), and it basically becomes
what Voice was, and Voice serves a different purpose inside
\partcombine than outside.  I don't remember any of the other issues;
I'd have to review my files and the mail archives.


> The reason I am asking in this context is that I think that you use
> multiMeasureRestBusy for transplanting the internal state of a
> Multi_measure_rest_engraver, and it may be expedient to instead
transplant the
> whole engraver by an appropriate use of context hierarchy.

I'll accept it as food for thought.  I am not optimistic that it will
lead to a solution that is easier to understand.

Thanks for the review.


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