lilypond-user
[Top][All Lists]
Advanced

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

Re: New snippet: remove staff if another is alive (for wind divisi)


From: Saul Tobin
Subject: Re: New snippet: remove staff if another is alive (for wind divisi)
Date: Tue, 7 Aug 2018 16:39:35 -0700

Super glad to see this conversation happening! David I'm so glad you've been working on the backend for divisi. Divisi staves have long been my biggest headache. 

Thomas, thanks for writing the improved version. I haven't had a chance to look at the code deeply yet — I will play around with it this weekend. 

One observation about the user interface: logically, if the combined 1+2 staff is hidden, both the staff for 1 and the staff for 2 should be printed. IMO one of the design goals for a divisi user interface should be to manage this automatically without the need to write separate simultaneous commands to hide or unhide each staff. There are only two possible states for a two-part divisi: combined or separate staves. Only a single command should be needed to toggle that state. Extrapolate for 3, 4 way divisi etc.

As an aside, for what it's worth, from my perspective as a composer who uses a lot of divisi staves, I want to minimize separation of divisi commands from musical content, because the choice to divide or not depends on the musical content, which I may revise frequently. I recognize that many other Lilypond users prefer the style you used in your example, but I just thought I'd mention it, since if this is moving towards an officially supported interface, IMO it needs to support both styles.

Saul

On Tue, Aug 7, 2018 at 12:42 PM David Kastrup <address@hidden> wrote:
Thomas Morley <address@hidden> writes:

> 2018-08-07 20:28 GMT+02:00 David Kastrup <address@hidden>:
>> Thomas Morley <address@hidden> writes:
>
>>>> Ok, let me chime in: I've basically developed some of the low-level
>>>> mechanisms for divisi staves.
>>>
>>> You mean that 'make-dead-when stuff?
>>
>> Well, that's the internal part of the low end.  But it's usually driven
>> by the remove-layer property.  You are not actually using it?
>
> Nope.
> I'll have a closer look at it, though.

Maybe it's a failure.  It may well have problems scaling since it
creates a single hierarchy.  I know that one tenet or inspiration for
that kind of numerical hierarchy was that it was reasonably certain to
avoid creating strange loops.

--
David Kastrup

_______________________________________________
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]