On Thu, 2015-11-12 at 10:38 -0600, David Wright wrote: > On Tue 10 Nov 2015 at 13:52:33 (+0000), Graham King wrote: > > On Mon, 2015-11-09 at 21:53 -0600, David Wright wrote: > > On Mon 09 Nov 2015 at 23:22:14 (+0000), Graham King wrote: > > > On Mon, 2015-11-09 at 14:55 -0600, Christopher R. Maden wrote: > > > On 11/09/2015 02:47 PM, Kieren MacMillan wrote: > > > > The very first thing they said to me was, “Add measure numbers.” > > > > That’s sufficient reason for me. =) > > > Good answer. > > > In that case, I would pick one part, and force those measure > > numbers in > > > as numeric rehearsal marks in the other parts. > > > Otherwise, you’d need a translation guide... > > > ~Chris > > > I guess Gould has a point. I've just realised that, under my system > > as I > > > described it, a part could have the same bar number twice. For > > example, in the > > > attachment below, T has two bars "9". But apart from an ill-chosen > > number (in > > > this case), one could regard the "bar numbers" as "numeric rehearsal > > marks". > > > Different mechanism, different formatting, same result. In practice, > > for the > > > sort of music I'm dealing with, the polymetric sections tend to be > > quite short > > > so, for the most part, bar numbers are more helpful than rehearsal > > marks. > > > > This is avoidable if each new bar is numbered with 1+(number of the > > bar—looking across all the parts—that most recently finished). Not > > something I could automate with my zero knowledge of scheme. > > > > Very logical. > > Advantages: > > +1 Might be amenable to automation. > > +2 Robust with respect to re-formatting. > > +3 Supports any variation of Staff.BarNumber.break-visibility (I think). > > > > Disadvantages: > > -1 On a given line, bar numbers increase in strange and surprising ways, > > giving potential for confusion. > > That's unavoidable by any scheme. Where a player has a part that has > many bars in one line (eg a slow-moving bass part where some other > parts have many more notes), the player will see multiple jumps in > their line, each where your "reference part" starts a new line in > its score. These jumps could be forwards or backwards.
I see your point. I'm dealing with a special case however, in which there is just a vocal score (no separate parts). Clearly, your scheme is superior in the general case. > > > One cannot just count from the start of the > > line and announce a bar number. > > Oh, I don't think you can get away without labelling every bar in > every part. We're just discussing what those labels will say. > > > For that reason alone, I'm inclined to favour: > > o Counting the bars of the top visible staff of the system, whilst > > o Allowing discontinuity at the start of each line to accommodate other > > parts that might have more bars in the previous line. > > The "start of each line" will be different in each and every score: > the full score, the vocal score, the choral score, and all the parts. > *Their* discontinuities will be all over the place, with jumps > backwards and forwards! Exciting stuff. > > So I see further advantages than just those in your list: > > +4 Bar numbers monotonically increase throughout every part. > +5 Bar numbers are a defined and intrinsic property of the music, > not an accident of one particular layout. In other words, the > bar number of every bar is known *before* LP tries to calculate > linebreaks and pagebreaks. > > > But that's just a personal preference. I wouldn't want to impose it on > > anyone > > else! (and I'm prepared to accept the need to fiddle with bar numbers > > manually > > at a late stage in the editing process). > > So what you're saying is (correct me if I'm wrong) you typeset the > music *in it's final form*, then sit down with the printout and > annotate the "reference part" bar numbers, then re-edit the source > putting in all the \set Score.currentBarNumber commands for each and > every line of the reference part. not necessarily every line. Different assumptions about the musical material - see below. > > Now comes the interesting bit: figuring out the bar numbers for all > the other parts and forcing them to match the reference part. > > And if a late correction has the effect of shifting a bar from one > line to another in the reference part, you're scuppered. Yes, all (mostly) correct, believe it or not! For my purposes, that's not a lot of work, since (i) the polymetric sections tend to be quite short, (ii) the piece is never published other than in score form and, (iii) re-working for corrections is rare (and if needed, a new set of printouts can be run off). I fully accept that this is a special case of a much more difficult general problem to which your analysis applies. I'm not trying to impose this special case on anyone, nor am I making any arguments about the general case. > > Hm. I want LP to do the work for me, not the other way round. > > Cheers, > David. > > _______________________________________________ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
