lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Line breaking issue


From: Hwaen Ch'uqi
Subject: Re: Line breaking issue
Date: Thu, 12 Aug 2021 18:18:41 -0400

Aww, buried in this explanation is the fact that you are "sharing the
gospel" of LilyPond with your students: Fantastic!!!

Hwaen Ch'uqi


On 8/12/21, Rachel Green <rg433n@outlook.com> wrote:
> Thanks all! That did fix the problem. A student typeset this for me, and I
> was so fixated on the cadenza measure, I did not check the syntax of the
> first measure well.
>
> Rachel
>
>> On Aug 12, 2021, at 12:24 PM, David Kastrup <dak@gnu.org> wrote:
>>
>> Valentin Petzel <valentin@petzel.at> writes:
>>
>>> Hello Rachel,
>>>
>>> As others have said before, the Beam syntax is wrong, you need to
>>> specify
>>>
>>> Note[ note note note]
>>>
>>> Instead of
>>>
>>> [note note note note]
>>>
>>> (the same way as slurs work). The big problem here is that Lilypond by
>>> default
>>> forbids breaks during Beams, which is normally only relevant when you do
>>> have
>>> Beaming over Measures. But in your case Lilypond is so confused, that it
>>>
>>> basically does not know exactly, where the beams are. So it thinks you
>>> have a
>>> beam going on when you haven’t. Fix the beams and it will work! If
>>> everythings
>>> works, Lilypond will in fact break this by itself, without you telling it
>>> to.
>>>
>>> Just a remark: You are using \voiceOne and \oneVoice for what I assume to
>>> be
>>> different hands. This is not good, as \oneVoice will change it’s
>>> behaviour
>>> depending on the note position, so if you were to change the clef or
>>> transpose
>>> the piece or something this might change the direction. Instead you can
>>> either
>>> use \voiceOne/\voiceTwo or \stemUp/\stemDown.
>>
>> \stemUp/\stemDown is pretty much always a very bad idea to use in
>> anything but the definitions of more complex voice-changing commands
>> that also cater for notehead collision strategies and other stuff.
>>
>> It was probably a mistake to make those explicit commands rather than
>> requiring them to be entered as overrides.
>>
>> --
>> David Kastrup
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]