lilypond-devel
[Top][All Lists]
Advanced

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

Re: Does the center of the staff need to be zero?


From: Kevin Dalley
Subject: Re: Does the center of the staff need to be zero?
Date: Sun, 18 Mar 2007 08:54:20 -0700
User-agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)

Thanks for the comments.

I have run across the problem with the ledger lines, and tried to
understand it, but failed.

What I noticed is that there is sometimes a problem when either the
uppermost or lowermost line is odd, where I have good ledger lines
above, but bad ones below.  I wondered whether the drum could be done
in a manner similar to what I used for the chromatic staff.  Perhaps
I'll give it another look.  I would like to get fix this problem.

Here are my sample file.

\version "2.10"
notes = {
  \time 4/4
  c'1 d' e' f' g' a'1 b' c'' | e''  | g'' | a'' | \bar "|."
}

\new Staff \with {
}
{
%bad ledger lines
  #(define mylines '(-1 0 1))
  \override Staff.StaffSymbol #'line-positions = #mylines

  \override Staff.StaffSymbol #'line-count = #(length mylines)
  \notes
}

\new Staff \with {
}
{
%good ledger lines
  #(define mylines '(-2 0 2))
  \override Staff.StaffSymbol #'line-positions = #mylines

  \override Staff.StaffSymbol #'line-count = #(length mylines)
  \notes
}
\new Staff \with {
}
{
%lower bad, upper good
  #(define mylines '(-1 0 2))
  \override Staff.StaffSymbol #'line-positions = #mylines

  \override Staff.StaffSymbol #'line-count = #(length mylines)
  \notes
}


Juergen Reuter <address@hidden> writes:

> Hi, all!
>
> Just a few comments:
>
> Actually, binding the origin to a staff line (e.g. the most lower
> staff line) rather than to the center of the origin (as we currently
> do) would solve the current problem that you have to design clefs
> explicitly either for staves with an even number of staff lines or for
> staves with an odd number of staff lines.  In this sense, I would
> really welcome such a change (even though some of the ancient clefs
> would then have to be shifted by 1/2 staff line in the metafont code)!
>
> If you do not understand what I mean, then just try to apply the
> ordinary G clef to a score with 4 staff lines or 6 staff lines instead
> of the ordinary 5 staff lines.  You will see that the clef will always
> be off 1/2 staff line (unless you do some y-offset trickery with
> backend properties).
>
> However, the drum clef will suffer from such a change, since the drum
> clef is usually always centered on the staff, regardles of the number
> of staff lines.  I think, the drum clef is the only clef for which
> this problem will arise.  Also, I am not sure if there are some
> serious implications of such a change for the pitch squash engraver.
>
> Greetings,
> Juergen
>
> On Sat, 17 Mar 2007, Han-Wen Nienhuys wrote:
>
>> As far as I can see there is no strict need, fot it to be zero, so if
>> you have a sensible patch to change it, go ahead and post it.
>>
>>
>> BTW I know that you have an interesting patch for Lily to make line
>> configurations more flexible. I'll try to review it this week.
>>
>> regards,
>>
>> Han-Wen
>>
>>
>> 2007/3/15, Kevin Dalley <address@hidden>:
>>> In LilyPond, using line-positions, the center is required to be at 0,
>>> otherwise there are problems with the created score.  There are a
>>> couple of possibilities.
>>>
>>> One is to make the documentations more clear that staffs must be
>>> centered at 0.
>>>
>>> The other possibility is to modify LilyPond to take staffs which are
>>> not centered at 0.
>>>
>>> I notice 2 areas which need to be modified.  I have a small patch for
>>> bar-line.cc, which otherwise draws the bar line of the correct size,
>>> but centered around 0 rather than centered around the real center.
>>>
>>> Ledger lines need some work as well, though there are problems even if
>>> the staff is centered, particularly if the top and bottom lines are on
>>> even positions.
>>>
>>> Should I post my patch for bar lines for staffs which are not centered
>>> at 0?
>>
>>
>>




reply via email to

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