bug-lilypond
[Top][All Lists]
Advanced

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

Re: comments on CVS from 2002-07-14 15:58 (long)


From: Werner LEMBERG
Subject: Re: comments on CVS from 2002-07-14 15:58 (long)
Date: Wed, 17 Jul 2002 07:22:12 +0200 (CEST)

> >   . Section 3.8, first example
> > 
> >     The arpeggio line doesn't look good.  Its wiggles are too big.
> 
> Too wide or too tall?

Too wide (horizontally).

> >     The trill sign is too big in comparison to the notes.
> 
> Still?! (It's already a lot smaller than in 1.4)

For me, yes.

> >     The rests in the fourth bar should be moved up automatically
> >     -- we are still using \VoiceOne, aren't we?  The same should
> >     be done for the half rest in the left hand.
> 
> Ours refs aren't clear. We talked with a guy from Universal Edition
> who maintained that rests should not be moved at all except to
> prevent a collision.  OTOH, he might have been talking about single
> voice music (like in beams, as you note below).

I was talking about the two-voice case.  A quick look into Bach's
fugues gives you something similar.

> >     The default vertical extension of the small slurs is too big.
> >     I don't know (yet) how this is handled by LilyPond, but I
> >     assume that the height of a slur is dependent on the length,
> >     right?  Which formula is used?
> 
> Slurs suck (see above).  The the control points  of the slur are
> calculated as
> 
>          (0,0),(0,h),(w-h,h),(w,0)
> 
> where h = h_infinity * F (x * r_0 / h_infinity) and F (x) = 2/pi *
> atan (pi x/2). See bezier-bow.cc

Will have a look.

> >   . Section 4.5.1, second example
> > 
> >     This must be a bug.  If I write [f'8 r16 f' g' a'], I should get
> >     this:
> > 
> >        -----------
> >        |     -----
> >        |  7  | | |
> >        x  7  x x x
> > 
> >      not this:
> > 
> >        -----------
> >        |  --------
> >        |  7  | | |
> >        x  7  x x x
> > 
> >     The latter form may be used in modern music (?), but it shouldn't
> >     be the default.
> 
> Can you formalize that for me? Do you want the beams to be connected
> as if there were no rest?

The formalizing is simple: No sub-beam ending at a rest!  A sub-beam
must start and end with a stem, except the case where it has the same
function as a flag, e.g.

       --------
       |     --
       |  7   |
       x  7   x

> >   . Section 4.8.5, first example
> > 
> >     Is a quick notation available to give a note more horizontal
> >     space?  Something like `c\wwide\ppp c\wide\pp' comes to my
> >     mind...
> 
> Nope. 

The idea is to increase the needed minimal width.  Which property
controls that so that I can write my own abbreviation?


Apropos abbreviations: I have two requests which could save a lot of
time for typing:

  . A special construction which returns the same notes in a chord as
    before, but with a different rhythm, e.g.

      <a4 c e> 4*<8>

    [What's the right syntax for 6*<a c e>, giving 6 times <a c e>?
    Or isn't this possible at all?]

  . I want simple macros with arguments, e.g.

      boring = <$1> 4*<8>

      \boring{a4 c e}
      \boring{a c f}

    It might be a good idea to enter rhythm and pitches of a chord
    separately with a new syntax, say, <pitches,rhythm>:

      boring = <$1,$2> 4*<$2*2>
                            ^
                    real multiplication

      \boring{a c e}{4}

         =>  <a4 c e> <a8 c e> <a8 c e> <a8 c e> <a8 c e>

    Probably all of this is already possible with Scheme, but this is
    sometimes very complicated.


      Werner



reply via email to

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