[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Carry multi-measure rests across voices in \partcombine (issue 26541

From: dak
Subject: Re: Carry multi-measure rests across voices in \partcombine (issue 265410043 by address@hidden)
Date: Fri, 09 Oct 2015 06:55:01 +0000
File lily/ (right):
lily/ void start_mmrest (Context *c, const
Moment &length);
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.
lily/ ev->set_property ("length",
A multi-measure rest event having a length (which is a cache of the
"duration" converted to a Moment) but not a duration is very, very,
lily/ {
Setting "duration" to SCM_EOL is just wrong.  Instead of setting lengths
(assuming that a Moment is all you have available), you should use
make-duration-of-length or similar in order to get a useful "duration"
lily/ Moment *rem = unsmob<Moment>
(c->get_property ("multiMeasureRestBusy"));
Please use robust_scm2moment here.
File ly/ (right):
ly/ %% by the part combiner.
Ugh.  It would appear that multi-measure rest splitting (or other rest
splitting) is only needed in the part combiner so why does it make sense
to add all this complication to the Multi_measure_rest_engraver and let
it idle in NullVoice?

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?
File scm/define-context-properties.scm (right):
scm/define-context-properties.scm:480: (multiMeasureRestBusy ,ly:moment?
"Remaining multi-measure rest duration.")
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.

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.

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

Just some food for thought.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]