On Tue 01 Nov 2016 at 15:23:21 (+0100), David Kastrup wrote: > "Andrew Bernard" <andrew.bern...@gmail.com> writes: > > Hi Ming, > > We have been through this before, I am sorry to say. You write > > lilypond code in a way that compiles, yes, but it is pathological in > > the extreme, to put it mildly. You set each and every bar as a > > variable, and when there are several voices, introduce new parallel > > voices in every bar. As an example for the others, this is what you > > do: > > > > lft.46 = { <<{g2 f2}\\{d1}>> |} > > > > lft.47 = { <<{r4 ef4~ <ef g>2}\\{g,1}>> |} > > Those are not "new parallel voices": they still connect. See: > > { > << c''1~ \\ e'1~ >> > << c''1 \\ e'1 >> > } > > << ... \\ ... >> translates to > << \context Voice = "1" ... \context Voice = "2" ... >> > > so when the parallel voices line up perfectly in time, they still happen > to connect. It still makes a hash of understanding the code and > debugging it and may well trigger rare problems in our context handling. > > Without very good reason, choosing such a non-structure definitely looks > like creating more problems than it solves.
Well, the reasons were given in http://lists.gnu.org/archive/html/lilypond-user/2016-03/msg00609.html but I can't see that a construction like sop.12 = \sop.1 sop.13 = \sop.1 sop.14 = \sop.1 sop.15 = \sop.1 sop.16 = \sop.5 sop.17 = \sop.1 sop.18 = \sop.1 sop.19 = \sop.1 sop.20 = \sop.1 sop.21 = \sop.5 is any less error-prone than R1 * 5 \break R1 * 5 \break nor can I imagine that it involves any less copy&paste, unless all the sop sop sop stuff was actually typed in. At least the source is not obfuscated, which it was last time. Anyway, with a few global edits, the source compiles just fine. Last page attached. Cheers, David.
pg_0007.pdf
Description: Adobe PDF document
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user