[Top][All Lists]

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

Re: repeating bar numbers and rehearsal marks in frenched score

From: David Kastrup
Subject: Re: repeating bar numbers and rehearsal marks in frenched score
Date: Thu, 28 Jul 2016 19:49:37 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Mark Knoop <address@hidden> writes:

> At 17:43 on 28 Jul 2016, David Kastrup wrote:
>>Mark Knoop <address@hidden> writes:
>>> OK, here's a patch using only the remove-layer property with these
>>> values:
>>> - #f: ignored by Keep_alive_together_engraver
>>> - -1: kept alive by any other layer
>>Isn't that the same as '() ?
> Well no, because of the next paragraph...
>>> The prior comment at lily/, line 72:
>>> "Unspecified layers are kept alive by anything else" was not quite
>>> true - unspecified layers are not kept alive by ignored layers, i.e.
>>> those with remove-layer = ##f.
>>Ugh, this is a bit too random. 
> Seems pretty random to me at the moment, having to set a property
> called "remove-layer" to false in order to remove the layer...
>>It would probably make more sense to use number-or-symbol? here and
>>then assign various symbols to various behaviors.
> I thought of that option, but just wanted to get the behavior working
> first before continuing down this path.
>>At any rate, I think the principal problem is that the
>>Keep_alive_together_engraver is desired to keep the marks context alive
>>with _either_ of the two voices under it.  That would sound like we
>>should have some way of grouping the marks context with the
>>_StaffGroup_ rather than the individual contexts.
>>So should the Keep_alive_together_engraver stop at a VerticalAlignment?
>>If you want to keep together the contexts in a vertical alignment (like
>>a StaffGroup), you could still add another Keep_alive_together_engraver
>>in the context carrying the Vertical_alignment_engraver.
> If I understand this correctly it would seem to be a more intrusive and
> less backward compatible change.

I'm not sure that backward compatibility would be affected all that
much.  This seems like something mainly affecting the
Keep_alive_together_engraver in complex situations unlikely to occur

> And I have no idea how to implement this.
>>Basically, we would add the hara-kiri-interface to VerticalAlignment as
>>well?  Something like that?
> How would this be done? Just by adding the interface and Y-extent calls
> in define-grobs.scm?

No, this would be a more intrusive change likely involving the C++
layer.  I'm not asking you to do this but rather whether this avenue
sounds like fitting your (and the general) problem space well enough
that it would be worthwhile to pursue.

I'm somewhat fuzzy about the semantics.

David Kastrup

reply via email to

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