lilypond-user
[Top][All Lists]
Advanced

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

Re: Sponsored feature request--cross-staff chords, ties


From: Trevor Bača
Subject: Re: Sponsored feature request--cross-staff chords, ties
Date: Wed, 23 Aug 2006 18:20:44 -0500

On 8/23/06, Han-Wen Nienhuys <address@hidden> wrote:
Trevor Bača wrote:
> On 8/22/06, Han-Wen Nienhuys <address@hidden> wrote:
>>
>> Hello,
>>
>> I once made an estimate for doing x-staff chords, for 400 EUR.  I think
>> that would be the most difficult task. If the stems + noteheads work
>> correctly, adding arpeggios and ties should be relatively easy.
>>
>> For reference, I insert what I wrote to Hans Forbrich:

> Well I had always wondered why the pricing on cross-staff stuff was so
> high. I thought it might be because it breaks the Voice model, but I
> wasn't sure ...

no, there are 2 issues: how to deal with the Staff/Voice model, and how
to keep the typesetting engine free of cyclic-dependencies. The latter
problem needs to be solved first, then we can invent ways for the
Staff/Voice model to control the typesetting engine.

Got it.


> Well, if Steve or Vivian or Hans or somebody is willing to help out,
> then I'm willing to pitch in on the sponsoring too.
>
> I'm about to have cross-staff stuff all over some piano music and also
> between different *string* staves as well. So a question.
>
> QUESTION: will the proposed cross-staff implementation path enable
> cross-staff stemming and beaming between *nonadjacent* staves (eg, 1st
> violins and basses, passing over the 2nd violins, violas and cellos)?

This is fraught with cyclic dependencies. It might be possible, but you
have to have some restrictions, eg.

  * the distances between these staves have been fixed in advance.

Fixed staff distance is perfectly good for me because of my way of
working. In every score the first thing I do is turn on proportional
notation to regularize horizontal spacing regular and the second thing
is to fix staff distances to do the same thing for vertical spacing.

So would that particular restriction (ie, that you only get
"nonadjacent stemming" or "nonadjacent beaming" or whatever we wind up
calling this sorta thing with fixed staff distances) cause a problem
for anyone else?

(If so, that's OK; we'll take one of the other paths.)


or

  * all x-staff beams are horizontal

What's an x-staff? Oh wait. Cross-staff. Got it.

No. This won't do. There still has to be beam slant for cross-staff beams.



or

  * stem directions have no influence over spacing.

I don't think I understand. (But maybe that's OK; if the
fixed-staff-y-distance restriction turns out to be acceptable then I'm
fine not grokking this point completely. On the other hand, if we
can't do the fixed-staff-y-distance thing then maybe more explanation
here would be good.)




In general:

   * spacing depends on stem directions,
   * line breaks depend on spacing
   * y-distance between staves depends on line breaks
   * beam configurations depend on y-distances
   * stem directions depend on beam configurations

hence, if we want x-staff stems, we must have restrictions: currently,
the y-distance between staves is fixed, and this works pretty well for
x-staff beams.

Right because the PianoStaff context allows cross-staff beams (but not
stems) today, under the restriction that we fix the distance between
the staves before all the other layout stuff happens.

I think we should just continue this same restriction for the other
cross-staff stuff (ie, for cross-staff *stems*, and for nonadjacent
beams and stems). Two reasons:

1. We already have the restriction with cross-staff beams in a
PianoStaff so the restriction already exists in (at least part of) the
model (and nobody seems to complain)

2. My past experience laying out cross-staff stuff in SCORE always
started with first fixing the exact vertical position of the staves
and only then doing all the beaming stuff, and this worked extremely
well, even for Takemitsu-looking stuff that beamed different string
sections together


There might be other ways to break this cycle, but there
might be other cycles as well.



--
Trevor Bača
address@hidden
... like the dew, or like lightning ...

reply via email to

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