Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(2711)

Issue 131970043: Issue 3518: Support temporary divisi staves (Closed)

Can't Edit
Can't Publish+Mail
Start Review
Created:
9 years, 8 months ago by dak
Modified:
9 years, 6 months ago
Reviewers:
lemzwerg
CC:
lilypond-devel_gnu.org
Visibility:
Public.

Description

Issue 3518: Support temporary divisi staves This provides the low-level support for temporary divisi staves by adding a `VerticalAxisGroup.remove-layer' property of type integer that interacts with the "Keep_alive_together_engraver": when set to a numeric value, staves with the same numeric value are kept alive together as one group. Of several such groups with live staves, only the one with the lowest common numeric `remove-layer' is retained. Also contains commits: Regtest for VerticalAxisGroup.remove-layer (divisi staves) Reformat define-grob-properties.scm to avoid column 0 parens in strings This is actually a more low-level interface than the discussion in the issue is mostly about. Since the provided mechanisms are considerably simpler and more flexible than envisioned in the discussion, it makes sense to let people integrate this into their existing frameworks/workflows without prescribing particular wrappers at this point of time.

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+112 lines, -16 lines) Patch
A input/regression/divisi-staves.ly View 1 chunk +54 lines, -0 lines 0 comments Download
M lily/hara-kiri-group-spanner.cc View 2 chunks +10 lines, -2 lines 0 comments Download
M lily/keep-alive-together-engraver.cc View 1 chunk +34 lines, -8 lines 0 comments Download
M scm/define-grob-properties.scm View 4 chunks +14 lines, -6 lines 0 comments Download

Messages

Total messages: 2
lemzwerg
LGTM. Very nice! I guess it makes sense to actually provide `\boring' and `\tricky' with ...
9 years, 8 months ago (2014-08-20 14:48:41 UTC) #1
dak
9 years, 8 months ago (2014-08-20 15:01:22 UTC) #2
On 2014/08/20 14:48:41, lemzwerg wrote:
> LGTM.  Very nice!  I guess it makes sense to actually provide `\boring' and
> `\tricky' with better names...

For a real use case/interface (which would also warrant ending in a snippet
and/or the documentation), \boring and \tricky in the current form would not
really work well: the whole point of a divisi passage is to disentangle a
situation that is too hard to show properly in a single staff.  But that means
that we want the passages now placed between \tricky and \boring to be replaced
by spacer rests or similar in the single staff.  Otherwise we'll get NoteColumn
collision warnings and similar for the tricky passages and, worse, have the
overcrowded tricky single-staff passages (which will not appear on paper)
determine the horizontal spacing in the divisi passages.  Of course, some
interference of ultimately disappearing staves cannot be avoided, but at least
those passages where the complexity is known to _demand_ the divisi staves,
cramming the material into a non-divisi phantom staff should not be allowed to
determine warnings and spacing.
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b