lilypond-devel
[Top][All Lists]
Advanced

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

Re: Keep a staff alive with multiple layers (issue 308910043 by address@


From: mark . opus11
Subject: Re: Keep a staff alive with multiple layers (issue 308910043 by address@hidden)
Date: Tue, 16 Aug 2016 02:09:25 -0700

On 2016/08/12 22:12:43, dak wrote:
I'm somewhat surprised since I would have thought the _semantics_
reasonably
straightforward.  If the _use_ turns out to be awkward, it could
probably
amended with a few scheme functions delivering appropriate context
modifications
or possibly some music function.

I haven't actually bothered doing so so I might be overlooking
something here.
Can you illustrate some of the occuring problems/awkwardnesses?  I
would have
thought the proposal comparatively straightforward to describe and use
and so
I'd be interested to know where I was being too optimistic.

Well, whilst it is relatively straightforward to implement, it
also creates the possibility of setting up a situation where the
result is essentially unknowable without fully understanding the
implementation (or trial and error).

For example, what should happen here?

- Staff A
    - removal-layer = 2
    - removal-friends = #'(b)
- Staff B
    - removal-layer = #'b
- Staff C
    - removal-layer = 1

Since A's index is greater than C's, C is set as a foe.
Hara_kiri_group_spanner::request_suicide checks foes before
friends, therefore A will be removed whenever C is present,
regardless of B's existence.

Of course this _can_ be documented and explained (that
integer-based layering will trump symbol), but I'm just not sure
what we gain from allowing this mediated access to the friends and
foes lists. Whilst adding some considerable complexity to the
codebase.

For example, in the multi-level divisi situation mentioned here
http://lists.gnu.org/archive/html/lilypond-devel/2016-07/msg00227.html,
the difficulty is unrelated to the setting of the layer priorities
- the current integer prioritising works perfectly here - but is
in finding a way to specify multiple levels of "trickyness" in the
music itself.

Essentially, I have made the multi-list approach work, but since I
don't have a use case for it I don't feel confident that it is
done in a useful way.

https://codereview.appspot.com/308910043/



reply via email to

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