Add dynamic-interface to keepAliveInterfaces
This will prevent \Remove[All]EmptyStaves from removing
Dynamics contexts containing dynamics attached to spacer
rests but no actual notes (the standard use case
for a Dynamics context).
What I am worried about is a partitura that puts common dynamics on every staff,
including staves without notes. That would keep those from being kept alive.
So the question is whether we should not possibly create a different
keepAliveInterfaces for the Dynamics context?
Opinions?
LGTM https://codereview.appspot.com/553760043/diff/565830044/Documentation/notation/staff.itely File Documentation/notation/staff.itely (right): https://codereview.appspot.com/553760043/diff/565830044/Documentation/notation/staff.itely#newcode801 Documentation/notation/staff.itely:801: rests, skips, or a combination of these elements. ...
> What I am worried about is a partitura that puts common dynamics on
> every staff, including staves without notes.
Never seen that, AFAIK. Can you provide a link to such a score?
Werner
On 2020/03/26 12:52:29, wl_gnu.org wrote:
> Never seen that, AFAIK. Can you provide a link to such a score?
I can certainly imagine that sort of things, in an orchestral score simple
enough that all instruments share the same dynamics (as was common until the
late 18th century), and where the LilyPonder may want to store all that in a
shared variable, including for systems where for example all the wind
instruments are tacet.
OTOH, we may also decide that users advanced enough to typeset a full partitura
are knowledgeable enough to know how to set their own keepAliveInterfaces.
BTW (on an unrelated note), I’ve just noticed that there’s something weird
happening with some stem columns when dynamics are attached to spacer rests:
https://sourceforge.net/p/testlilyissues/issues/4691/#cc82
V.
>> Never seen that, AFAIK. Can you provide a link to such a score?
>
> I can certainly imagine that sort of things, in an orchestral score
> simple enough that all instruments share the same dynamics (as was
> common until the late 18th century), and where the LilyPonder may
> want to store all that in a shared variable, including for systems
> where for example all the wind instruments are tacet.
Well, sharing is OK, but displaying? Are you really saying there
exist scores that have staff lines only with rests, and which also
have dynamics like 'f' or 'p'? Besides not making any sense, it would
completely confuse the player IMHO.
Werner
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.
On 2020/03/27 19:00:08, jean wrote:
> I can see no situation where the current value of keepAliveInterfaces does a
> better
> job than the one with dynamic-interface.
OK, you both make a valid point. Then it LGTM as well.
V.
On 2020/03/27 23:16:40, Dan Eble wrote:
> Is the impact (if any) on existing scores important? (cases that we might not
> have in regression tests but that might irk users?)
... and speaking of regression tests, if you don't want someone to break your
work later, it would be a good idea to add one.
On 2020/03/27 23:16:40, Dan Eble wrote: > Is the impact (if any) on existing scores ...
3 years, 12 months ago
(2020-03-31 20:14:44 UTC)
#19
On 2020/03/27 23:16:40, Dan Eble wrote:
> Is the impact (if any) on existing scores important? (cases that we might not
> have in regression tests but that might irk users?)
It should be close to zero.
In fact, I'm stupid. I just realised a thing: up to now, users have been told to
put \RemoveEmptyStaves in a \context { \Staff ... }. So it won't change anything
in the overwhelming majority of scores. But, it will allow you to do this in a
\context { \Score ... } (also applying to TabStaff etc.) or, by the by, in a
\context { \PianoStaff ... } (it will apply to the whole piano part, but no
longer remove the Dynamics context between the staves).
I'll update the documentation with this.
By the way, why do we say \RemoveEmptyStaves instead of \removeEmptyStaves?
On 2020/03/31 20:14:44, jean wrote: > I'll update the documentation with this. Hum, while exploring ...
3 years, 12 months ago
(2020-03-31 20:26:51 UTC)
#20
On 2020/03/31 20:14:44, jean wrote:
> I'll update the documentation with this.
Hum, while exploring the regression tests, I just discovered that we have a
Keep_alive_together_engraver out there, undocumented, except in the internals.
I'll take a look at it, and try to write appropriate documentation (or find the
authors and ask them to document it!). Setting the issue to needs_work.
On 3/31/20, jean@abou-samra.fr <jean@abou-samra.fr> wrote: > By the way, why do we say \RemoveEmptyStaves instead ...
3 years, 12 months ago
(2020-03-31 20:43:03 UTC)
#21
On 3/31/20, jean@abou-samra.fr <jean@abou-samra.fr> wrote:
> By the way, why do we say \RemoveEmptyStaves instead of
> \removeEmptyStaves?
Because it’s a context property that you need to set for your whole
context (it’s actually a \with block), not on-the-fly like \cadenzaOn;
see also \RemoveEmptyStaffContext, which is capitalized like all
context names (Staff, RhythmicStaff etc.). It may (may!) become
clearer to you if you have a look at ly/context-mods-init.ly and
ly/engraver-init.ly (unlike non-capitalized properties and commands
defined in ly/property-init.ly and ly/music-functions-init.ly).
… And, yes, I do realize that’s way too convoluted of an explanation.
If someone else can do it more straightforwardly, have at it! :-)
Cheers,
- V.
Thanks for you support, Valentin. > … And, yes, I do realize that’s way too ...
3 years, 11 months ago
(2020-05-03 20:03:56 UTC)
#25
Thanks for you support, Valentin.
> … And, yes, I do realize that’s way too convoluted of an explanation.
If someone else can do it more straightforwardly, have at it! :-)
Hey, don't make me feel bad about my own more-than-lengthy explanations!
On 2020/03/31 20:51:05, Valentin Villenave wrote:
> You can’t say it’s undocumented, its documentation is just not meant
> for regular users:
True, I meant that this isn't just useful for internal use, you may need it as a
regular user, I think, because a conductor would think the choir or the strings
as a whole, so it can sound weird to have a system with only violin I without
violin II (hope I'm clear).
There is now a regression test as asked for, and a bit more documentation. I
added an example about Keep_alive_together_engraver, though I'm not completely
satified with it--feel free to improve. It is taken from
https://www.universaledition.com/kurt-weill-764/works/der-jasager-1900 (Kurt
Weill, Der Jasager). This score isn't actually demonstrating the need for this
(it could have been if the breaks were placed another way) but if this is
wanted, here is an example showing that it happens in printed music:
http://imslp.eu/files/imglnks/euimg/5/54/IMSLP522307-PMLP3653-NBE_-_Symphonie...
(the first page).
Yet, there is still an issue. What's happening in this example?
\version "2.21.0"
keepRests =
\applyContext
#(lambda (context)
(ly:context-set-property! context 'keepAliveInterfaces
(cons 'rest-interface (ly:context-property context
'keepAliveInterfaces))))
\layout {
\context {
\Score
\RemoveAllEmptyStaves
\keepRests
}
}
<<
{ c'1 c'1 c'1 }
{ R1 \break s1 \break R1 }
>>
I expect the second staff in the second system to disappear, but this is not the
case. Yet if you replace the surrounding R1 with r1, then it works. Did I
misunderstand the way \RemoveEmptyStaves works? How can it depend on the other
systems? It can't be put in the documentation if it doesn't work...
Thanks!
Issue 553760043: Add dynamic-interface to keepAliveInterfaces
Created 4 years ago by jean
Modified 3 years, 11 months ago
Reviewers: dak, lemzwerg, wl_gnu.org, Valentin Villenave, Dan Eble
Base URL:
Comments: 2