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