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:
>
On 3/31/20, j...@abou-samra.fr wrote:
> 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.
I believe it was added by Joe Neeman in order to fix issue #442:
https://sourceforge.net/p/testlilyis
On 3/31/20, j...@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
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 documentatio
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 \RemoveEm
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 on
Is the impact (if any) on existing scores important? (cases that we
might not have in regression tests but that might irk users?)
https://codereview.appspot.com/553760043/
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.
https://codereview.appspot.com/553760043/
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 tha
>> 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
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 Lil
> 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
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, sk
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?
https://code
14 matches
Mail list logo
