not sure why you put the top score - that's do to ragged-last-bottom = ##f
>The most prevalent problem with the score heights not being synchronized
over the markups can, of course, be corrected >without too much trouble,
e.g. by adding hidden notes such that the "optical ambitus" is identical in
both "partial scores."
I would used \once \override Score.StaffGrouper.staff-staff-spacing.padding
= #4.6 adjusted to previous height
\markup {
% \line {
\score {
\new PianoStaff {
<<
\new Staff { <c'' c> }
\new Dynamics { s4\pp }
\new Staff { c }
>>
}
\layout {
}
}
\score {
\new PianoStaff {
<<
\new Staff {
\once \override Score.StaffGrouper.staff-staff-spacing.padding = #4.6
c''' }
\new Dynamics { s4 }
\new Staff { c' }
>>
}
\layout {
\context {
\Score
}
}
}
% }
}
>Slightly more annoying are the facts that
>- the overall score is (logically) interrupted,
ya but that's more of a issue of you know it is so it bothers you i think
:) but I agree!
>- measure numbers need to be changed afterwards, time signatures need to
be removed manually when the (logical) score continues, RehearsalMark
counters etc. as well,
yup
>Nothing which cannot be worked around, I agree; but it will require some
dedication...
also you could use method one and create a false staff and move the grouper
something like this could easily be used as a template
this is based on one of the ways (this one I never posted) I tried for
scrapbook-cutaway ... anyway
\version "2.18.2"
#(define-public (stack-stencil-overlay stencils)
"Recursive function to add stencils together"
(if (and (pair? stencils)
(ly:stencil? (car stencils)))
(if (and (pair? (cdr stencils))
(ly:stencil? (cadr stencils)))
(let ((tail (stack-stencil-overlay (cdr stencils)))
(head (car stencils)))
(ly:stencil-add head tail))
(car stencils))
point-stencil))
#(define-markup-command (overlay layout props args)
(markup-list?)
"Overlay arguments one on top of the next"
(let ((stencils (interpret-markup-list layout props args)))
(stack-stencil-overlay
(remove ly:stencil-empty? stencils))))
up = {
\once \override Staff.StaffSymbol.color = #white
\once \override Staff.Clef.color = #white
\once \override Staff.TimeSignature.color = #white
\override Staff.Clef.layer = #-1
\override Staff.TimeSignature.layer = #-1
}
down = {
\once \override Staff.StaffSymbol.color = #white
\once \override Staff.Clef.color = #white
\once \override Staff.TimeSignature.color = #white
\override Staff.Clef.layer = #-1
\override Staff.TimeSignature.layer = #-1
}
\markup {
\overlay {
\overlay {
\translate #'(33.1 . 0)
\score {
\new PianoStaff \with {
} <<
\new Staff = "up" \with {
\override VerticalAxisGroup.staff-staff-spacing = #'((basic-distance .
11.8))
} \up
\new Staff = "down" \with {
} { \clef bass \down }
>>
\layout { }
\midi {
\context {
\Score
}
}
}
}
\score {
\new PianoStaff {
<<
\new Staff {
\key g \major
<c'' c> q q q
\stopStaff
\repeat unfold 2
{
s1
}
\startStaff
\override Staff.Clef.full-size-change = ##t
\once \override Staff.BarLine.transparent = ##t
\override Staff.BarLine.allow-span-bar = ##f
\once \override Staff.Clef.extra-offset = #'(1 . 0)
\once \override Staff.TimeSignature.extra-offset = #'(1 . 0)
\clef treble
\key g \major
\time 4/4
c \override Staff.BarLine.allow-span-bar = ##t
c c c
}
\new Dynamics { s4\pp }
\new Staff {
\key g \major
c c c c
\stopStaff
\repeat unfold 2
{
s1
}
\startStaff
\override Staff.Clef.full-size-change = ##t
\once \override Staff.BarLine.transparent = ##t
\override Staff.BarLine.allow-span-bar = ##f
\once \override Staff.Clef.extra-offset = #'(1 . 0)
\once \override Staff.TimeSignature.extra-offset = #'(1 . 0)
\once \override Staff.NoteHead.extra-spacing-width = #'(-2 . 0)
\clef treble
\key g \major
c'' c c c
}
>>
}
\layout {}
}}}
good luck
Stephen
On Fri, Jul 24, 2015 at 2:31 PM, Alexander Kobel <n...@a-kobel.de> wrote:
> Hi Stephen, hi everybody.
>
> On 07/24/2015 07:50 PM, Stephen MacNeil wrote:
>
>> 1.) Use \stopStaff, spacer rests, and \startStaff, or 2.) Use a
>>> markup line with two scores and a horizontal space in between.
>>>
>>
>> Version 2 theoretically offers full flexibility, but all spacing
>>> (in particular, vertical spacing) is computed separately from the
>>> overall score. If your score is even slightly non-trivial, chances
>>> are that you will end up with a imperfect solution even after
>>> fiddling around with many >settings,
>>>
>>
>> The markup solution works,
>>
>
> Actually, I agree that it works a lot better than it used to a few
> versions ago.
>
> I don't really understand the problem with "(in particular, vertical
>> spacing)"
>> 1. I don't see any problem and
>> 2. that can be changed.
>> Could you give an example.
>>
>
> Sure - find it attached. Contrieved, but trust me that similar issues
> occur in real scores.
>
> The most prevalent problem with the score heights not being synchronized
> over the markups can, of course, be corrected without too much trouble,
> e.g. by adding hidden notes such that the "optical ambitus" is identical in
> both "partial scores."
> Slightly more annoying are the facts that
> - the overall score is (logically) interrupted,
> - measure numbers need to be changed afterwards, time signatures need to
> be removed manually when the (logical) score continues, RehearsalMark
> counters etc. as well,
> - changing line breaks near the markup means moving content in the sources
> (not to mention that automatic line break determination is inhibited),
> - you have to adjust score-markup and markup-score distances before and
> after the coda line (very annoying, because they are at paper block level
> and cannot easily be changed throughout the file, and the score might go
> on),
> - vertical spacing inside the markup and at the top-level is not related
> (the spacing in the top-level score gets tighter if more systems come on
> the page, the distance in the markup stays),
> - per-score layout settings need to be duplicated.
>
> Nothing which cannot be worked around, I agree; but it will require some
> dedication...
>
> Bottom line: does anybody know whether it's possible to redraw a
>>> SystemStartBrace in the middle of the line and thus solve the issue
>>> of the first version? I already spent some hours (mostly
>>> trial-and-error) on that a while ago, but could not achieve
>>> anything useful.
>>>
>>
>> Not that I know of.
>>
>
> Pity...
>
>
> Best,
> Alexander
>
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
