Thomas, Benjamin, David, Andrew and Malte:
Thank you all for taking time to help and suggestion of coding practise. The
reason I use "enclosed numeric" for variables is that I thought of using this
way I can reuse the measure (bar) throughout the piece. If I detected an
error, I only need to update one place. I did try copy and paste method before
and if I found error, I had to search where I had pasted the code to make
correction. If this is a "bug", how to proceed?If this is not an appropriate
coding practise, please give me some sample that I can follow? My object is to
reuse the measure(s) other than copy-&-paste method.
Thanks again,Ming.
From: Thomas Morley <thomasmorle...@gmail.com>
To: lilypond-user <lilypond-user@gnu.org>
Cc: Benjamin Strecker <benstrec...@gmail.com>; MING TSANG <tsan...@rogers.com>;
David Wright <lily...@lionunicorn.co.uk>
Sent: Saturday, March 19, 2016 3:14 PM
Subject: Re: difference of code construct
2016-03-19 17:26 GMT+01:00 David Wright <lily...@lionunicorn.co.uk>:
> On Fri 18 Mar 2016 at 16:42:45 (-0400), Benjamin Strecker wrote:
>> I was a little curious about the difference in the output, but I'm afraid I
>> can't offer a solution, only some observations after looking at it.
>>
>> In my tinkering, it seemed to be associated with the time signature. In
>> the example below (and attached), I get the same behavior you do, where the
>> second score has the left-hand part continuing past the apparent end of its
>> voice(s). Additionally, there is inconsistency about the beaming of the
>> eighth notes between the two scores. However, if I change the time
>> signature to 4/4 (and change R2. to R1 in the right hand), both scores
>> produce the same output.
>>
>> Would anyone be able to elaborate if this is expected behavior?
>
> I too cleaned up the example (which is a masterclass in obfucsation)
> to get down to the bare bones. I would have thought that the answer
> lies in NM (2.19.36) §5.1.3 pp571-2. The staff which ends with ">>"
> gets the pair of instantiated voices killed off, whereas the one
> ending ">> r" has already returned to its old voice when it finishes.
>
> But this idea doesn't hold using crochets instead of quavers. So
> perhaps, as you pointed out, the difference in beaming has something
> to do with it, or is a symptom of some underlying difference.
>
> (The attached example is the same with 2.18 and 2.19)
>
> Cheers,
> David.
The << ... // ... >>-construct creates new Voices. Thus you can boil it down to:
right = \new Staff { \time 3/4 R2.*3 }
left = \new Staff { r4 d'8 e' r4 }
leftI = \new Staff { r4 \new Voice { d'8 e' } r4 }
%% workarounds
%% (1) manual beaming
leftII = \new Staff { r4 \new Voice { d'8[ e'] } r4 }
%% (2) Continuing the Voice via \context
%% doesn't work for << ... // ... >> of course
leftIII = \new Staff { r4 \context Voice { d'8 e' } r4 }
<< \right \left \leftI \leftII \leftIII >>
Somehow Lilypond is confused if the the new Voice is created at a
critical measurePosition, critical for the auto-beamer.
leftII/III demonstrate workarounds.
I'd call it a bug, please report.
The only previous version I found, which doesn't add extra-measures is 2.14.2
Cheers,
Harm
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
