lilypond-user
[Top][All Lists]
Advanced

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

Re: Changing voice order...


From: David Kastrup
Subject: Re: Changing voice order...
Date: Wed, 02 Nov 2016 14:48:26 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Noeck <address@hidden> writes:

> A bit more of Mutopia statistics:
>
> 4157 .ly files on Mutopia don't use << \\ >>
> 1130 .ly files on Mutopia do
>  307 of the latter have only one \\, so the can't be affected by a change
> The other 823 possible could be affected but most of them use only two
> voices in one construct but several such constructs.
>
> By the way, the top position with 369 double backslashes is this piece:
> https://github.com/MutopiaProject/MutopiaProject/blob/master/ftp/BachJS/BWV830/BWV-830/BWV-830-lys/BWV-830.ly

This particular one is... horrific.

upper = \relative e
{
  \clef treble 
  \key e \minor
  \time 2/2

  \ntbo #16.5 \times 4/7 { \bc e16[ g b e] \tc \su g[ b e] } g8. g16 << { g 4 
fs } \\
                                                                        { a,2   
 } \\
                                                                        { c 2   
 } >> | % 1

  \sn
  \ntbo #15.5 \times 4/7 { \bc ds,,16[ fs a c] \tc ds[ fs g] } a8. a16 << { a  
4 g            } \\ 
                                                                          {     
              } \\
                                                                          { fs 
4 e _\mordent  } \\ 
                                                                          {     
              } \\
                                                                          { 
ds!4 s            } >> | % 2


Let's take a look what conventions are employed here in the first two
<<\\>> things.  First the voices left empty (ugh) strongly suggest that
the person entering the code is aware of the up/down pattern of input.
Also the code suggest that the person is more acquainted with LilyPond's
abilities than good for the readability of their code.  Let's take a
look at the pitches (relative mode):

<< { g 4 fs } \\
   { a,2    } \\
   { c 2    } >> | % 1

top, bottom, middle: correct

<< { a  4 g            } \\
   {                   } \\
   { fs 4 e _\mordent  } \\ 
   {                   } \\
   { ds!4 s            } >> | % 2

Ugh what?  All of the non-empty ones are stemup.  Order:

top, middle, bottom: within the stemup stacking correct but what an
awful input.  And why everything stemup?

Let's take the next two examples:

<< { g16. \beams #2 #3 fs32 \beams #3 #3 e fs g16 cs,4 \prall } \\
   { cs,2                                                     } \\
   { \shortStem #4.5 a'2                                      } \\
   {                                                          } \\
   { e2                                                       } >> | % 5

Order: top, bottom, high, --none--, low

One thing that is obvious that \relative pitch is a real mess to keep
track of in this kind of highest/lowest/high/low scheme.  It works quite
more natural in high-to-low stackings.

<< { fs16. \beams #2 #3 e32 \beams #3 #3 d e fs16 b,4 \prall } \\
   { d,2                                                     } \\
   { \shortStem #5 g2                                        } >> | % 6

Correct as far as I can see.

So this most exuberant example does not get anything wrong as far as a
first glance would suggest.  It's also ugly as hell.

At any rate, the \relative problem means that a convert-ly rule actually
reordering things would be a really, really complex feat.

-- 
David Kastrup



reply via email to

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