Hi Graham, > On the positive side: > +1 This scheme guarantees a unique id for each bar. The id increases in a > sensible manner. > +2 The scheme is robust with respect to re-formatting, if systems are > split or joined. > +3 Since Lilypond's default behaviour is to break lines only where > barlines co-incide and to number bars at the start of each line > (Staff.BarNumber.break-visibility = ##(#f #f #t)), it would work with that. > > On the negative side: > -1 We have to introduce non-integers. I don't think the current > bar-numbering engine will cope with that in cases where +3, above, does not > apply.
I didn’t really think of (or, to be honest, care about) Lilypond’s current bar-numbering engine; I was simply trying to solve a problem in notation. I can make the bar numbers appear however I want (by overriding the stencil, manually setting the barnumber counter, etc.). > -2 Where +3 does apply, musicians will get confused. One will look at the > start of the line (bar "n") and count across in the conventional way (n+1, > n+2, ...) and announce the supposed bar number. Everyone else will then look > on the wrong line entirely. Sorry: I took it as self-evident [though, of course, it isn’t] that in polymetric music, bar numbers must appear on every bar, not just at the beginning of the line. > On balance I don't think it would work. Well, until I hear a superior suggestion, this is the one I’m going to use. =) Thanks, Kieren. ________________________________ Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
