lilypond-user
[Top][All Lists]
Advanced

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

Re: difference of code construct


From: MING TSANG
Subject: Re: difference of code construct
Date: Sun, 20 Mar 2016 01:10:55 +0000 (UTC)

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 <address@hidden>
To: lilypond-user <address@hidden>
Cc: Benjamin Strecker <address@hidden>; MING TSANG <address@hidden>; David Wright <address@hidden>
Sent: Saturday, March 19, 2016 3:14 PM
Subject: Re: difference of code construct

2016-03-19 17:26 GMT+01:00 David Wright <address@hidden>:
> 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


reply via email to

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