Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by address@hidden)

[jean]

This is a relevant point, but I think Werner is right.

You can put your dynamics in a Dynamics context. Currently, they would
be
removed completely, while with this patch, they would be kept entirely.
Whatever the value of keepAliveInterfaces, this is no good solution for
the
kind of partitura that you describe (althought I tend to think that the
latter
would be less cryptic to the user). But with this change, the default
behavior will
be correct with a usual Dynamics, that is, if you just write spacer
rests when
you want no dynamics.

What we're debating here is the case where you put the dynamics together
with
the music in the same Staff context.

Without this change, staves with rests only are removed whatever their
dynamics.
You could think this is useful, but what if the winds start tacet in the
middle
of a system? You will then have rests with dynamics on them. With this
patch, all the
staves will be kept as soon as they contain dynamics, and you will also
have rests with
dynamics on them. I don't think there is much better to do. Whatever the
state of
keepAliveInterfaces, there is no 'easy' solution: it's up to the user to
split their
dynamics variable, or use \quoteDuring, or write a very tricky function.
As a result,
I can see no situation where the current value of keepAliveInterfaces
does a better
job than the one with dynamic-interface.

If someone does and can provide a concrete example, I'll gladly create a
different
value for Dynamics contexts, but if there is no real reason to do this,
let's keep it simple.

https://codereview.appspot.com/553760043/