Menu
▾
▴
2 Attachments
#1609 unpredictable change of voicing in partcombine-midi.ly
Originally created by: *anonymous
Originally created by: percival.music.ca@gmail.com
While investigating the midi regtest "instability", I've extracted the following. It's not quite yet Tiny, but I've spent the time I want to spend on it today, so hopefully somebody can pick it up and turn it into an actual Tiny example.
Output generated from 2.13.57 GUB and git master + metadata patch, but I really doubt that the patch did anything.
\version "2.13.57"
% it seems like you need both the _heads_ and _rest_ ?
\layout {
\context {
\Voice
\remove "Note_heads_engraver"
\consists "Completion_heads_engraver"
\remove "Rest_engraver"
\consists "Completion_rest_engraver"
}
}
\score {
\new Staff <<
\new Voice {
\voiceOne
[r1]
}
\new Voice \relative c {
\voiceFour
c'4 d e f
}
\new Voice {
\voiceTwo
[r1]
}
\new Voice {
\voiceThree
[r1]
}
>>
\layout {}
\midi {}
}
Originally posted by: k-ohara5...@oco.net
The completion- engravers are not essential, it is simply the fact that LilyPond does not have a rule to place simultaneous rests with a note of different durations (see issue 1547). Smaller example, which produces different output depending on whether the file is alone on the command line or second in a list of .ly files:
\version "2.12.3"
\new Staff <<
\new Voice {
\voiceOne
[r1] [r1]
}
\new Voice {
\voiceThree
c'2 e' g' b'
}
\new Voice {
\voiceTwo
[r1] [r1]
}
>>
Originally posted by: k-ohara5...@oco.net
The troublesome regtest, midi/partcombine.ly, sets two voices in \partcombine, which produces four voices in the midi output, each on their own track :
Solo (either soloI or soloII)
Unison
Divisi One
Divisi Two
and then midi2ly reads these four voices and correctly places them in one Staff.
The only problem is that the midi2ly output requires something that current LilyPond does not typeset consistently: three rests simultaneous with notes of different duration.
However, the silent voices automatically produced by partcombine should not have rests; they should have skips, which is midi2ly option --skip. Trivial patch at
<http://codereview.appspot.com/4433044/>
Originally posted by: percival.music.ca@gmail.com
Not tested yet, but I'm very happy to see that a simple patch like that can fix it.
Labels: Patch-new
Originally posted by: ColinPKC...@gmail.com
Applies cleranly to 2.13.61 and partcombine-midi shows the rests no longer there.
Labels: -Patch-new Patch-review
Originally posted by: k-ohara5...@oco.net
Regtest change pushed in 6afd86a9b, to appear in 2.15.0
Note that the pushed change only prevents a regression test from generating a .ly file that produces varying typeset output. This problem was, I think, the critical aspect of this issue.
As the examples above illustrate, placement of such rests still changes unpredictably. The score in example 2 produces different output with the two command lines
lilypond test.ly
lilypond test.ly test.ly
while version 2.12.3 produces the same output in either case. Both versions produce a warning "too many colliding rests". See also issue 1547 and issue 384.
Originally posted by: k-ohara5...@oco.net
The variation in position of the rests appeared somewhere between 2.13.48 and .54
Originally posted by: percival.music.ca@gmail.com
Let's make this one specifically about partcombine-midi.ly, and issue 1618 about the general unpredictability of rest placement.
The fix to partcombine-midi should be applied to stable/2.14.
Summary: unpredictable change of voicing in partcombine-midi.ly
Labels: -Patch-review fixed_2_15_0
Status: Started
Originally posted by: Carl.D.S...@gmail.com
(No comment was entered for this change.)
Labels: backport
Status: Fixed
Originally posted by: jan.nieuwenhuizen
I'm not especially thrilled by the use of this "--skip" option.
Sure, it fixes the undetermined behaviour of rest placement,
because with --skip no rests are placed.
This makes the partcombine regtest next to useless, as we
probably want to see rests in other voices when using
partcombine.
So, while this may be slightly better than removing
the partcombine regtest altogether, and I'm glad that
we have our regression test suite running again,
we still need this undefined rest behaviour fixed,
and after that, this --skip option should be removed
again.
Originally posted by: k-ohara5...@oco.net
We really do want --skip in this case, or at least I do, because \partcombine creates four voices from the two voices input.
Here are typesets of the original partcombine.ly, and the reconstruction from its midi file by midi2ly, first using skip and then hand-editing to work around the rest-collision issue.
Originally posted by: Carl.D.S...@gmail.com
Backported
Labels: -backport fixed_2_13_61
Originally posted by: brownian.box@gmail.com
Please help! -- how to verify this?
May i use code @comment1 ?
Originally posted by: k-ohara5...@oco.net
> Please help! -- how to verify this?
Good point.
The core program did not change, so you cannot verify on the released build.
The fix changed only the regression tests, so verifying involves running the regression test. I'll adjust the Type.
I should not verify myself because I prepared the patch.
Labels: -Type-Defect Type-Scripts
Originally posted by: k-ohara5...@oco.net
Well, usually I should not verify my own fix,
but since this fix did not change the program itself, having it stay on the list to verify is only a distraction.
Status: Verified