Menu
▾
▴
#1321 Enhancement: add partcombineUp and partcombineDown functions
Originally created by: *anonymous
Originally created by: v.villenave
Originally owned by: dak@gnu.org
This feature request was posted by Mark on -devel a while back:
http://lists.gnu.org/archive/html/lilypond-devel/2010-03/msg00089.html
"""
While answering a question on -user, I found what looks like
an easily-solvable (?) limitation with /partcombine. The
part-combiner.scm file is a little beyond me, but am I right
in thinking that /partcombine uses the equivalent of
/voiceOne and /voiceTwo when redistributing the notes?
If that's true, then the proposed functions would use:
partcombineUp (voiceOne + voiceThree)
partcombineDown (voiceTwo + voiceFour)
This would allow combinations of 3 or even 4 voices to share
a common staff while taking advantage of the partcombine
functionality. Would this be a trivial extension or is it
more complicated than that?
"
Originally posted by: bordage....@gmail.com
Potential fix :
http://codereview.appspot.com/4514042/
This is more a draft than anything else.
It doesn't work properly with four voices :
<< \partcombineUp \one \two \partcombineDown \three \four >>
But this works great :
soprano = { d''2 f'' g'' }
alto = { a' c''4 d'' e''2 }
basso = { d'4 e' f' g' g'2 }
\new Staff << \partcombineUp \soprano \alto \\ \basso >>
Regards,
Bertrand
Originally posted by: k-ohara5...@oco.net
Issue 1842 has been merged into this issue.
Originally posted by: k-ohara5...@oco.net
(No comment was entered for this change.)
Labels: Patch-new
Status: Started
Originally posted by: pkx1...@gmail.com
When I try to patch to current tree (27 Aug) I get
--snip--
patching file lily/part-combine-iterator.cc
Hunk #2 succeeded at 138 with fuzz 1.
Hunk #4 FAILED at 390.
Hunk #5 FAILED at 412.
2 out of 5 hunks FAILED -- saving rejects to file lily/part-combine-iterator.cc.rej
patching file ly/music-functions-init.ly
Hunk #1 succeeded at 762 (offset 29 lines).
patching file scm/part-combiner.scm
jlowe@jlowe-lilybuntu2:~/lilypond-git$
--snip--
Make succeeds though, and reg tests pass too.
So I have set this patch to 'review' as I don't know the significance of these patch messages.
Labels: -Patch-new Patch-review
Owner: bordage....@gmail.com
Originally posted by: percival.music.ca@gmail.com
fuzz is fine. FAILED is not.
Labels: -Patch-review Patch-needs_work
Originally posted by: percival.music.ca@gmail.com
new patch needs checking
Labels: -Priority-Low -Patch-needs_work Patch-new
Originally posted by: pkx1...@gmail.com
passes make and reg tests
Originally posted by: pkx1...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-new Patch-review
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-countdown
Originally posted by: ColinPKC...@gmail.com
Counted down to 20110928
Labels: -Patch-countdown Patch-push
Originally posted by: bordage....@gmail.com
Pushed as [rbb7cac7b276bd7d1335523f3be8df815cf894ece].
Labels: -Patch-push fixed_2_15_14
Status: Fixed
Originally posted by: k-ohara5...@oco.net
Doesn't work if one \partcombineUp|Down has a solo section.
A solo section in \partcombineDown fails to get down stems.
soprano = { d''2 f'' g'' }
tenor = { [r1] c''2 }
basso = { d'4 e' f' g' g'2 }
\new Staff << \soprano \\ \partcombineDown \tenor \basso >>
Originally posted by: pkx1...@gmail.com
Should we have a new tracker or re-open this?
Originally posted by: k-ohara5...@oco.net
Probably best to keep this as a 'Started' enhancement request, then.
Labels: -fixed_2_15_14
Status: Started
Originally posted by: dak@gnu.org
Issue 1321: Enhancement: add partcombineUp and partcombineDown functions
This is actually a reimplementation on the basis of context mods. It
makes \partcombine itself quite more flexible, though I am less than
enthused about the utility of \partcombineUp and \partcombineDown.
They are more or less unnecessary now.
This also renders issue 3534 moot.
http://codereview.appspot.com/13242056
Labels: Patch-new
Owner: dak@gnu.org
Originally posted by: dak@gnu.org
(No comment was entered for this change.)
Cc: markpole...@gmail.com
Originally posted by: pkx1...@gmail.com
Passes make, make check and a full make doc.
Reg test diffs attached
Labels: -Patch-new Patch-review
Originally posted by: dak@gnu.org
Huh. The regtest diffs are tricky.
The first diff results from the old code stating:
/* Mimic all settings of voiceOne/voiceTwo for the two separate voices...*/
/* FIXME: Is there any way to use the definition of \voiceOne/\voiceTwo
directly??? */
char const *syms[]
=
{
"Stem",
"DynamicLineSpanner",
"Tie",
"Dots",
"Rest",
"Slur",
"TextScript",
"Script",
0
};
and the new code relying on \voiceOne/\voiceTwo which have
(define direction-polyphonic-grobs
'(AccidentalSuggestion
DotColumn
Dots
Fingering
LaissezVibrerTie
LigatureBracket
MultiMeasureRest
PhrasingSlur
RepeatTie
Rest
Script
Slur
Stem
TextScript
Tie
TupletBracket
TrillSpanner))
notably _not_ including DynamicLineSpanner. It's easy for the user now to add an override for DynamicLineSpanner if desired. Since the look is somewhat on the unusual side, I'd almost lean towards not doing this automatically.
As for the second regtest change, this is due to me using \voiceOne/\voiceTwo for \partcombine (while the old code used the equivalent of \voiceOne/\voiceFour which makes only limited sense to me so I'll stay off it for now), and \voiceOne/\voiceThree for \partcombineUp (matching the old code) and \voiceTwo/\voiceFour for \partcombineDown while the old code uses \voiceFour/\voiceTwo here.
The idea for the latter is probably to shift the inner voices. Since there is explicit code in the old partcombiner for swapping the choice of shifts, this would appear intentional, leading to the typical order \voiceOne/\voiceThree/\voiceFour/\voiceTwo from top to bottom in four-voice polyphony. Talk about intuitive. Maybe we should at some point of time at least swap the definitions of \voiceTwo and \voiceFour.
So I'll switch the voice order for \partcombineDown around.
Labels: -Patch-review Patch-needs_work
Originally posted by: dak@gnu.org
swap \voiceTwo and \voiceFour for \partcombineDown
http://codereview.appspot.com/13242056
Labels: -Patch-needs_work Patch-new
Originally posted by: dak@gnu.org
Regarding the first part of comment #18: the list of directional grobs for the part combiner was introduced with commit
commit [rb5c032a34d103966f81ecaad177b63cd649719ed]
Author: Han-Wen Nienhuys <hanwen@xs4all.nl>
Date: Wed Jan 28 00:01:48 2004 +0000
* scm/music-functions.scm (determine-split-list): bugfix: only use
new-active for both voices if both indexes advance. This fixes the
biggest outstanding problem with new-pc.
* lily/new-part-combine-iterator.cc (construct_children): set more
directions.
as
+ char const * syms[] = {
+ "Stem",
+ "DynamicLineSpanner",
+ "Tie",
+ "Dots",
+ "Slur",
+ "TextScript",
+ "Script",
+ 0
+ };
At that point of time, the directional grobs in music-functions.scm were only
(define direction-polyphonic-grobs
'(Tie Slur Script TextScript Stem Dots DotColumn))
so it would appear that (apart from the missing DotColumn) the list quite intentionally included DynamicLineSpanner explicitly, surpassing what is in \voiceOne.
The comment
/* Mimic all settings of voiceOne/voiceTwo for the two separate voices...*/
/* FIXME: Is there any way to use the definition of \voiceOne/\voiceTwo
directly??? */
was added only as part of
commit [rb5603acc6faf05c541353bf2154d73986e2bee0b]
Author: Reinhold Kainhofer <reinhold@kainhofer.com>
Date: Sun Sep 26 20:39:33 2010 +0200
Part-combine: The two separate voices also need proper settings for MultiMeasureRest and horizontal-shift
So it would seem that Han-Wen's original intent was quite explicitly
to have the partcombiner put dynamic spanners for the first voice in a
split-voice situation _above_ the line. What is somewhat absurd is
that DynamicText is _not_ put above the line which does not make a
whole lot of sense.
I'm keeping this off for now: if we want to have the upper voice
dynamics move up by default, we can still do so. And the user now has
the possibility to do it himself, too, so it's probably not the worst
idea if the default overrides are not too complex so that the user
does not have problems supplying equivalent versions and adding more
stuff.
Cc: hanw...@gmail.com
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests. But moving the hairpin down in part-combine-force regtest like discussed.
Labels: -Patch-new Patch-review
Originally posted by: k-ohara5...@oco.net
It would be good to add the dynamics direction to the \voiceN settings in your reorganized \partcombine, so that the default behavior stays the same.
The dynamics direction is needed for clarity in combined parts (http://k-ohara.oco.net/Lilypond/Mvt2_Partcombine.pdf with the patch above, versus http://k-ohara.oco.net/Lilypond/Mvt2_Largo.pdf). It would be logical to include dynamics direction in \voiceN, but it is more practical to keep it out (http://lists.gnu.org/archive/html/bug-lilypond/2010-09/msg00261.html)
The voice numbering scheme gives low numbers to the common voices, and allows \voiceFive \voiceSix ...
Originally posted by: dak@gnu.org
I guess I'll use \dynamicUp/\dynamicDown then. Those also adjust the direction of DynamicText, not just (like the partcombiner so far) DynamicLineSpanner. However, it does not appear that the setting of DynamicText.direction actually has any effect?!?
Originally posted by: k-ohara5...@oco.net
DynamicText objects are put within DynamicLineSpanners before placement, which is not at all obvious, but makes consistent placement a bit simpler. (It might be nice, if possible, to remove DynamicText from the list of grobs, letting DynamicLineSpanner handle everything.)
Originally posted by: dak@gnu.org
Use voiceOne/Two for outer+joined voices, add \dynamicUp/\dynamicDown
http://codereview.appspot.com/13242056
Labels: -Patch-review Patch-new