Re: \RemoveEmptyStaves not removing first line
I am currently engraving a song for soprano and piano which begins with 15 measures of piano solo. I would like the soprano's staff not to show since it is not playing. \RemoveEmptyStaves does not seem to hide the first line of the piece. In current versions (there's no reason not to use the 2.19.xx development versions which are stable enough for professional everyday use), there's |\RemoveAllEmptyStaves| which does just that (like \RemoveEmptyStaves but also remove the respective staves in the first system). Best Lukas ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
\RemoveEmptyStaves not removing first line
Dear list, I am currently engraving a song for soprano and piano which begins with 15 measures of piano solo. I would like the soprano's staff not to show since it is not playing. \RemoveEmptyStaves does not seem to hide the first line of the piece. Rohan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: fonts not working as expected
Hi Kieran, In a message to me you mentioned you are using Alegreya Medium. Downloading this from the original type foundry, with 2.19.82 on Ubuntu 18.10 the use of the font name "Alegreya Medium", just that, works just fine. I'll try it on my Mac. Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Function or command to omit only certain accidentals of a chord?
Hello Jan! I'm just testing out EE and I've come across the need to adress a noteHead tweak in a note inside a chord. Looking for a solution, I came to this post. Is this implemented? -- Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Line-breaking with non-aligned barlines
Am So., 28. Okt. 2018 um 08:07 Uhr schrieb Werner LEMBERG :
>
> > A minimal would be:
> >
> > \paper { indent = 0 ragged-right = ##t }
> >
> > {
> > \override Beam.breakable = ##t
> > s2. s8
> > c'8[
> > \break
> > c'16]
> > }
> >
> > Not sure I'd call it a bug.
>
> IMHO, it is a bug.
>
> > But I'd love to have a method to change this behaviour easily,
> > currently there's none.
>
> I fully agree.
>
> > Though, you can dive into Beam deeply and reset 'beam-segments with
> > custom values. Leading to: [...]
>
> Very nice! If possible, this should be made the default. I even
> suggest to completely drop the current behaviour since I can't
> envision a situation where you really want this.
>
>
> Werner
Hi Werner,
I'll open an issue on the tracker.
As workaround a much more elaborated coding below.
It's now possible to process complex Beams, affecting them before and
after a line-break.
Not yet coded is affecting the beam-segments of the middle-beam-parts
of a more than two times broken Beam.
Though, it will not happen very often. At least I hope so.
\version "2.19.82"
\paper { indent = 0 ragged-right = ##t }
#(define (devide-at-vertical-count beam-dir dir-pred lst)
;; 'lst' is supposed to be the list of beam-segments
;; A new list is returned where all entries of same vertical-count are wrapped
;; into a sublist.
;; Relying on dir-pred those sublists appear in reversed order.
;; This is important to get have 'new-beams' working on the correct
;; beam-segment. Empty sublists would disturb, they are removed.
(remove
null?
(map
(lambda (i)
(let ((inner-list
(filter
(lambda (el) (eqv? (assoc-get 'vertical-count el) i))
lst)))
(cond ((eq? dir-pred 'first-beam)
(reverse inner-list))
((eq? dir-pred 'last-beam)
inner-list
;; TODO Unlikely to have more than 10 beam-segments.
;; Better than removing empty lists afterwards would be to find the correct
;; beam-count, though. Too lazy right now ...
(iota 10 0 (- beam-dir)
#(define (new-beams amounts dir-predicate lst)
;; Returns a new list suitable for 'beam-segments.
;; Relying on 'dir-predicate' left or right side of the beam-segments are
;; changed.
(append-map
(lambda (a el)
(cons
(list (caar el)
(let* ((hor (assoc-get 'horizontal (car el
(cons 'horizontal
(cond ((eqv? dir-predicate LEFT)
(cons (+ a (car hor)) (cdr hor)))
((eqv? dir-predicate RIGHT)
(cons (car hor) (+ a (cdr hor
(else hor)
(cdr el)))
amounts
lst))
shortenBrokenBeams =
#(define-music-function (amount)(list?)
"
Shorten broken Beams at line-break.
We get the 'beam-segments, rebuilding it modified.
The 'beam-segments-property is an alist of type:
'(((vertical-count . 0) (horizontal 3.865018 . 5.93))
((vertical-count . 1) (horizontal 3.865018 . 5.93)))
`vertical-count' is the beam-count, which may grow negative.
`horizontal' is the X-extent relative to 'System's 'line-width.
Regrettable this means changing `horizontal' will need to be adjusted
frequently. P.e. if Beam-direction changes.
@var{amount} is a list containing number-lists. Their values are applied to
the beam-segments at line-break.
At line-end they are applied to the right. At line-start to the left.
An empty sublist will trigger default beaming.
Limitations:
Does not work for the inner beam-parts of more than two times broken Beams.
"
#{
%% Add \once ?
\override Beam.beam-segments =
#(lambda (grob)
(let* ((middle-of-broken-beam?
(and (eq? (grob::name (ly:spanner-bound grob LEFT))
'NonMusicalPaperColumn)
(eq? (grob::name (ly:spanner-bound grob RIGHT))
'NonMusicalPaperColumn)))
(first-of-broken-beam?
(and (eq? (grob::name (ly:spanner-bound grob RIGHT))
'NonMusicalPaperColumn)
(not (eq? (grob::name (ly:spanner-bound grob LEFT))
'NonMusicalPaperColumn
(last-of-broken-beam?
(and (eq? (grob::name (ly:spanner-bound grob LEFT))
'NonMusicalPaperColumn)
(not (eq? (grob::name (ly:spanner-bound grob RIGHT))
'NonMusicalPaperColumn
(beam-segments (ly:beam::calc-beam-segments grob))
(dir (ly:grob-property grob 'direction)))
(cond
(middle-of-broken-beam?
(ly:message
"Tweaking left and right ends of a beam-segments is not yet coded.
Returning default.")
beam-segments)
(first-of-broken-beam?
Re: fonts not working as expected
Hi Abraham, > When you say “outputs nothing” do you mean nothing appears, or nothing > changes from the main doc font? It literally disappears — a blank space where there was markup before. Thanks, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Force text on line without using \textLengthOn
Am Fr., 26. Okt. 2018 um 13:58 Uhr schrieb Thomas Morley
:
> currently I've not the time to dive deeper in your code, maybe later
> today or during the upcoming weekend.
Hi Urs,
I haven't looked deeply into your code, but I think it will not work as desired.
First some general words about (Text)Spanner.
A (Text)Spanner is spanned between it's left/right bound, usually
without affecting spacing of the spanned NoteColumns at all.
If you enlarge the (Text)Spanners width, Lilypond will now use this to
space the covered NoteColumns following the built-in rules.
Example:
{
c'8 c' c' c'
\override TextSpanner.springs-and-rods = #ly:spanner::set-spacing-rods
\override TextSpanner.minimum-length = 20
c'8\startTextSpan c' c' c'\stopTextSpan
}
Here the different spacing is obvious but each is even.
In my approach I therefore tried to end (Text)Spanners as late as
possible to benefit from this behaviour.
I'm aware I mentioned the possibility to insert <>\stopTextSpanner via
a function right after the \startTextSpan, i.e. before the next event.
Your function follows those lines.
Though, now you don't benefit from the even spacing of the covered
NoteColumn, because you only have the start and end.
{
c'8 c' c' c'
\override TextSpanner.springs-and-rods = #ly:spanner::set-spacing-rods
\override TextSpanner.minimum-length = 20
c'8\startTextSpan <>\stopTextSpan c' c' c'
}
The fiddling to find the correct minimum-length of the (Text)Spanner
is of secondary importance. With or without empty dimensions of the
(Text)Spanners text.
Sorry, if I pointed in a wrong direction.
I currently don't have further insights or hints as well :(
Though, Kieren pointed to his ignore(H/V)-definitions.
Admittedly I don't know what they are about.
Testing them with
ignoreH =
\propertyTweak horizontal-skylines ##f
\propertyTweak extra-spacing-width #empty-interval
\etc
ignoreV =
\propertyTweak vertical-skylines ##f
\propertyTweak extra-spacing-height #empty-interval
\etc
ignore = \ignoreH \ignoreV \etc
{
c'8-\ignore ^"foo"
c'8-\ignore ^"bar"
}
returns a segfault:
warning: cannot find skylines - strange alignment will follow
c'8
-\ignore ^"foo"
lilypond:
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/lily/skyline.cc:660:
Real Skyline::internal_distance(const Skyline&, Real*) const:
Assertion `sky_ == -other.sky_' failed.
Aborted (core dumped)
Kieren, could you propose some use-cases?
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Issue with make-dead-when (divisi, hara_kiri)
Hi all,
Not sure if this should be on the User mailing list or one of the others.
The attached code replicates a strange behavior I have encountered several
different times, where seemingly random and irrelevant musical details
cause staves to incorrectly disappear when using the divisi snippet I
posted a few months ago. I also tested this with variants of Thomas
Morley's version of the snippet, so I'm convinced it's not anything to do
with the snippet itself.
In my attached example, notice that the Oboe 2 staff disappears when it
shouldn't, but if you remove the hairpin from the flute part, the Oboe 2
staff reappears. I believe that this is caused by the Oboe 2 staff having
'make-dead-when set to the combined staff, which itself has 'make-dead-when
set to Oboe 1. Hara_kiri_group_spanner::request_suicide checks each foe
staff for is_live and request_suicide_alone, but not request_suicide (to
avoid infinite loops, I guess). So if Oboe1+2 becomes dead due to
'make-dead-when, when on its own it would have stayed alive, it may either
appear alive or dead to Oboe 2, depending on which staff happens to be
evaluated first.
To avoid this race condition, one has to avoid setting 'keep-dead-when to
point to other staves that themselves have 'keep-dead-when set. In other
words, for some staves to be masters, others to be slaves. Which is
probably a good idea anyway, but it leaves a gap in functionality when it
comes to 3+ stave divisi. For 3 staves, you have:
1+2+3: Alive if BOTH 1 and 3 are dead
1+2: Alive if 1 is dead AND 3 is alive
2+3: Alive if 1 is alive AND 3 is dead
1: Master staff
2: Alive if BOTH 1 and 3 are alive
3: Master staff
With the semantics of the existing 'make-dead-when interface, this is
doable by making, for instance, 1+2 and 2+3 dead whenever 1+2+3 is alive,
but as I noticed, this type of inter-dependency leads to unpredictable
behavior. A better way forward would be to expand the 'make-dead-when
mechanism to support a complete variety of logical conditions, such as ALL
vs. ANY and combinations of alive and dead conditions.
Saul
\version "2.19.82"
\language "english"
remove-if-sibling = #(define-scheme-function (offsets) (list?)
(lambda (grob)
(let* (
;; The parent of a VerticalAxisGroup is a VerticalAlignment
(parent (ly:grob-parent grob 1))
;; Get the children VerticalAxisGroups of the parent
(siblings (ly:grob-object parent 'elements))
(siblings-list
(if (ly:grob-array? siblings)
(ly:grob-array->list siblings)
'()))
;; Find the siblings above or below me by offsets
(my-vindex (ly:grob-get-vertical-axis-group-index grob))
(enemy-indices (map (lambda (offset) (+ offset my-vindex)) offsets))
(enemy-vaxis? (lambda (v) (member (ly:grob-get-vertical-axis-group-index v)
enemy-indices)))
(enemy-vaxes
(filter enemy-vaxis? siblings-list))
)
;; Suicide if an enemy sibling is alive
(map
(lambda (enemy-vaxis)
(ly:pointer-group-interface::add-grob grob 'make-dead-when enemy-vaxis))
enemy-vaxes)
)
)
)
global = {
s1
\break
s1*3
\break
s1
\bar "||"
}
flute = {
\clef treble
\set Voice.midiInstrument = "flute"
R1*3 |
% Notice that without the hairpin, the Ob. 2 staff doesn't disappear
c''1\< |
c''1 <>\! |
}
oboeI = {
\clef treble
\set Voice.midiInstrument = "oboe"
\context Staff = "Ob1" { \unset Staff.keepAliveInterfaces }
R1 |
c''1 |
R1 |
\context Staff = "Ob1" { \set Staff.keepAliveInterfaces = #'() }
R1*2 |
}
oboeII = {
\clef treble
\set Voice.midiInstrument = "oboe"
R1*2 |
c'1 |
R1*2 |
}
\score {
<<
\new Staff = "Fl1" \with {
instrumentName = "Flute"
shortInstrumentName = "Fl."
} << \global \flute >>
\new StaffGroup \with {
instrumentName = "Oboe"
shortInstrumentName = "Ob."
systemStartDelimiter = #'SystemStartSquare
\override SystemStartSquare.collapse-height = #5
} <<
\new Staff = "Ob1+2" \with {
instrumentName = \markup\right-column {"1" "2"}
shortInstrumentName = \markup\right-column {"1" "2"}
\override VerticalAxisGroup.before-line-breaking = \remove-if-sibling #'(1)
} { <> << \global \partcombine \oboeI \oboeII >> }
\new Staff = "Ob1" \with {
instrumentName = "1"
shortInstrumentName = "1"
\override VerticalAxisGroup.remove-empty = ##t
\override VerticalAxisGroup.remove-first = ##t
} << \global \oboeI >>
\new Staff = "Ob2" \with {
instrumentName = "2"
shortInstrumentName = "2"
Re: fonts not working as expected
Hey, Kieren! On Sun, Oct 28, 2018 at 2:13 PM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi all, > > No MWE possible, because obviously it’s a local problem with my computer… > > I’ve installed fonts on my computer. I’ve restarted the machine, and > allowed Lilypond to recache fonts. Frescobaldi’s auto-completion mechanism > recognizes (and suggests) the new fonts, and they appear as expected in > Font Book, they show up when I run '-dshow-available-fonts x', etc. > > So they seem to be installed properly, and recognized by the various > applications involved. But > > \markup "test" > > outputs as expected [using the main document font], whereas > > \markup \override #'(font-name . "New Font Name") "test" > > outputs nothing. > > What should I be looking for to fix this problem? How can I debug it > further to see what’s wrong? When you say “outputs nothing” do you mean nothing appears, or nothing changes from the main doc font? Best, Abraham > > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MarkLine and bar numbers
On 28.10.18 17:10, Thomas Morley wrote: %% !! \override BarNumber.after-line-breaking = #'() \accepts "MarkLine" } } Only minimalistic tests done, though ... I applied it to my real-world score, and it’s definitely a step forward – however, behaviour is really erratic now: some of the rehearsal marks are still displaced. I’ll see if I can find time to make a real bug report, but would be grateful if somebody else could. Best, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
fonts not working as expected
Hi all, No MWE possible, because obviously it’s a local problem with my computer… I’ve installed fonts on my computer. I’ve restarted the machine, and allowed Lilypond to recache fonts. Frescobaldi’s auto-completion mechanism recognizes (and suggests) the new fonts, and they appear as expected in Font Book, they show up when I run '-dshow-available-fonts x', etc. So they seem to be installed properly, and recognized by the various applications involved. But \markup "test" outputs as expected [using the main document font], whereas \markup \override #'(font-name . "New Font Name") "test" outputs nothing. What should I be looking for to fix this problem? How can I debug it further to see what’s wrong? Thanks, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MarkLine and bar numbers
Am So., 28. Okt. 2018 um 17:56 Uhr schrieb Kieren MacMillan : > > Hi Harm, > > >\override BarNumber.after-line-breaking = #'() > > Whoa… What exactly does that do? It seems like a nuclear option! > > I’ll be sure to give it a try the next time I run into the issue (which > should be very soon, since it happens so frequently). Both, RehearsalMark and BarNumber have their 'after-line-breaking set to the procedure ly:side-position-interface::move-to-extremal-staff, defined in side-position-interface.cc. Setting BarNumber.after-line-breaking to an empty list disables it. I had the suspicion nobody expected a user would move Mark_engraver without moving Bar_number_engraver as well. So there might be some bleed over. So far my suspicion. Then I simply did some experiments ;) Tbh, after disabling ly:side-position-interface::move-to-extremal-staff for BarNumber my expectation was BarNumber would be printed somewhere in the middle of nowhere... So I recommend thorough testing before using this for serious work. Anyway, I'd call current behaviour a bug. In 2.21.0 we will have issue 2199 Mark_engraver in StaffGroup misplaces marks at top of Score https://sourceforge.net/p/testlilyissues/issues/2199/ Though, it's limited to StaffGroup anyway... Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MarkLine and bar numbers
Hi Harm, >\override BarNumber.after-line-breaking = #'() Whoa… What exactly does that do? It seems like a nuclear option! I’ll be sure to give it a try the next time I run into the issue (which should be very soon, since it happens so frequently). Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: interlocking/overlapping HorizontalBracket
Hi Harm, > Of course you could use a second Voice. > Or use a second Voice like below, although very cumbersome. > […] > I'd love someone would demonstrate a better way. I just tried it. Unfortunately, it becomes unmanageably cumbersome (effectively impossible) once the main voice has anything else (e.g., lyrics) attached to it — as my real-world scenario does. I think I’m going to go with a custom context, and see if I can make the code as sugar-y and simple as possible to input. Thanks, Kieren. p.s. I would still love for spanner-id to be implemented for HorizontalBracket — that (I think we would all agree) is "the better way". Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MarkLine and bar numbers
Am So., 28. Okt. 2018 um 12:39 Uhr schrieb Simon Albrecht
:
>
> Hello list,
>
> I’m currently debugging a couple issues with a use case of the MarkLine
> context. One of them is demonstrated in the attached minimal scenario:
> with a MarkLine atop the topmost staff, the barnumbers fail to align
> with the latter, as they normally would. Does anybody know how to
> prevent that?
>
> Best, Simon
Hi Simon,
how about:
\layout {
\context {
\name "MarkLine"
\type "Engraver_group"
\consists "Output_property_engraver"
\consists "Axis_group_engraver"
\consists "Mark_engraver"
\override VerticalAxisGroup.staff-affinity = #DOWN
\override VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding = #0.5
\override VerticalAxisGroup.nonstaff-nonstaff-spacing.padding = #0.5
}
\context {
\Score
\remove "Mark_engraver"
%% !!
\override BarNumber.after-line-breaking = #'()
\accepts "MarkLine"
}
}
Only minimalistic tests done, though ...
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MarkLine and bar numbers
Hi Simon, > If bar numbers are in the Staff context, start-of-line marks will be > displaced as if to accommodate Score bar numbers, even if there are none. > Anyone? Yeah, this is a thorn in my side, and has been for years. Never had the time to track down MWEs etc. to post a bug — instead, I tend to hack my scores, or use edition-engraver tweaks to fix the "floaters". Would love to see this one squashed for good. Happy to help however I can. Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MarkLine and bar numbers
Follow-up question:
If bar numbers are in the Staff context, start-of-line marks will be
displaced as if to accommodate Score bar numbers, even if there are
none. Anyone?
Sorry I’m pushing on this apparently hardly supported construct…
Best, Simon
\version "2.19.82"
#(ly:set-option 'debug-skylines #t)
\layout {
\context {
\name "MarkLine"
\type "Engraver_group"
\consists Output_property_engraver
\consists Axis_group_engraver
\consists Mark_engraver
}
\context {
\Score
\remove Mark_engraver
\accepts MarkLine
%\remove "Bar_number_engraver"
}
\context {
\Staff
\consists "Bar_number_engraver"
}
}
marks = {
s1 \break
\mark\default
s1
}
<<
\new MarkLine \marks
{ s1*2 }
>>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: interlocking/overlapping HorizontalBracket
Hi Harm, > I don't think looking at spanner-id is implemented for HorizontalBracket. =( > Ofcourse you could use a second Voice. > Or use a second Voice like below, although very cumbersome. I wonder what [minimum set of] engravers would a context need in order to just engrave HorizontalBrackets? I could see a stack of skip-delimited AnalysisBracket contexts (like Dynamics) doing what I need… though it may be just as easy to do individual voices in the main Staff context. Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MarkLine and bar numbers
On 28.10.18 14:00, damianlegassick wrote: Hello Simon don't have the solution to moving the bar number, but 'normally' they *do* align as in your pic Thanks for the hint, that got me on the right track as to a workaround: moving Bar_number_engraver to the topmost staff. Not an actual solution – I don’t think that bar numbers should behave that way – but fine for now. Best, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MarkLine and bar numbers
Hello Simon
don't have the solution to moving the bar number, but 'normally' they *do*
align as in your pic
\version "2.19.82"
aux = {
s1*2
}
soprano = \relative {
s1 \mark\default
\break
s
}
<<
\new StaffGroup <<
\new Staff \new Voice \soprano
\new Staff \new Voice \aux
>>
>>
> On 28 Oct 2018, at 11:38, Simon Albrecht wrote:
>
> Hello list,
>
> I’m currently debugging a couple issues with a use case of the MarkLine
> context. One of them is demonstrated in the attached minimal scenario: with a
> MarkLine atop the topmost staff, the barnumbers fail to align with the
> latter, as they normally would. Does anybody know how to prevent that?
>
> Best, Simon
>
> 12-37-23.png>___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
MarkLine and bar numbers
Hello list,
I’m currently debugging a couple issues with a use case of the MarkLine
context. One of them is demonstrated in the attached minimal scenario:
with a MarkLine atop the topmost staff, the barnumbers fail to align
with the latter, as they normally would. Does anybody know how to
prevent that?
Best, Simon
\version "2.19.82"
\layout {
\context {
\name "MarkLine"
\type "Engraver_group"
\consists Output_property_engraver
\consists Axis_group_engraver
\consists Mark_engraver
}
\context {
\Score
\remove Mark_engraver
\accepts MarkLine
}
}
aux = {
s1*2
}
marks = {
s1
\mark\default
s
}
soprano = \relative {
s1
\break
s
}
<<
\new MarkLine \marks
\new StaffGroup <<
\new Staff \new Voice \soprano
\new Staff \new Voice \aux
>>
>>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Line-breaking with non-aligned barlines
> A minimal would be:
>
> \paper { indent = 0 ragged-right = ##t }
>
> {
> \override Beam.breakable = ##t
> s2. s8
> c'8[
> \break
> c'16]
> }
>
> Not sure I'd call it a bug.
IMHO, it is a bug.
> But I'd love to have a method to change this behaviour easily,
> currently there's none.
I fully agree.
> Though, you can dive into Beam deeply and reset 'beam-segments with
> custom values. Leading to: [...]
Very nice! If possible, this should be made the default. I even
suggest to completely drop the current behaviour since I can't
envision a situation where you really want this.
Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
