lilypond-user
[Top][All Lists]
Advanced

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

Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffCon


From: Graham King
Subject: Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)
Date: Fri, 13 Nov 2015 14:27:04 +0000

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
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user

reply via email to

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