Re: Change_iterator refuses to move a NullVoice into a Staff
David Kastrup writes:
> For something like
>
> \change StaffGroup = "what"
>
> the change iterator looks at the current context hierarchy upwards until
> it finds a "StaffGroup" as a parent. The layer below that is the
> context to move, and if it is significantly similar in specification to
> the context that should be/become its parent, it might become hard to
> move back and forth.
>
> So it's likely a bit of work/thought to make sure one does not create
> context trapdoors from which it is hard to escape. Hovercraft parent
> contexts.
A context change involves specific pruning and grafting points, but the current
syntax of the command can be ambiguous.
The grafting point is ambiguous if there multiple contexts with the same type
and ID nearby (a vague statement betraying vague understanding). I see that as
a possibility, though the user’s option to choose context IDs seems to mitigate
that problem.
The pruning point is ambiguous if the \change command is nested in more than
one context of the given type. This is the case in my situation where
NullVoice is aliased to Staff, but I actually want to prune between the
enclosing Staff and the NullVoice.
* * *
Now that I’ve said that, I’ve been able to work around my problem by creating a
new kind of context to target (see below). I haven’t tested it in a serious
score yet. I don’t much mind having to define a special context, but I do
consider it ugly that the \change command must refer to a context outside
Lilypond’s standard model.
Back to the bug: I appreciate that it’s not obvious what to do with
Change_iterator, but is there anything obvious that could be done to NullVoice
that (without defeating its purpose) would cause \change Staff to pass over it?
Regards,
—
Dan
\version "2.19.58"
sopranoNotes = \fixed c' {
c1 d e f
\break
\change TrueStaff = "S"
g a b c'
}
\layout {
\context {
\Staff
\name TrueStaff
}
\context {
\ChoirStaff
\accepts TrueStaff
}
}
\new ChoirStaff \with {
\RemoveEmptyStaves
\override VerticalAxisGroup.remove-first = ##t
} <<
\new TrueStaff = "S" \with {
instrumentName = "S"
shortInstrumentName = "S"
} {
$(skip-of-length sopranoNotes)
}
\new TrueStaff = "SA" \with {
instrumentName = "SA"
shortInstrumentName = "SA"
} <<
\new Voice { \sopranoNotes }
\new NullVoice = "soprano" { \sopranoNotes }
>>
>>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Change_iterator refuses to move a NullVoice into a Staff
David Kastrup writes:
> Dan Eble writes:
>
>> %{
>> NullVoice is unlike a Voice in this respect: trying to move it to a
>> different Staff with \change fails with this warning:
>>
>> Change_iterator::process (): NullVoice = `soprano':
>> cannot change `Staff' to `S': not changing to same context type: Staff
>>
>> Apart from the warning, this is inconvenient. The NullVoice remaining
>> in the original staff keeps the original staff alive, demanding manual
>> work to make it disappear.
>>
>> The NullVoice context definition contains both of the following:
>>
>> \alias "Staff"
>> \alias "Voice"
>>
>> My knowledge of contexts is not extensive, but I suggest that the test
>> that \change applies is too simple.
>
> The test is
>
> else if (it.get_outlet ()->is_alias (to_type))
> {
> // No enclosing context was found because the iterator's immediate
> // context is the kind that was sought.
> /* We could change the current translator's id, but that would make
> errors hard to catch.
>
> last->translator_id_string () = get_change
> ()->change_to_id_string (); */
> result = _f ("not changing to same context type: %s", ly_symbol2string
> (to_type).c_str ());
> }
>
> and that's indeed crapola. What the test should do is check whether the
> current context type would be accepted into the hierarchy of the
> proposed parent.
Well, that's a bit too simplistic because there is no "current context
type".
For something like
\change StaffGroup = "what"
the change iterator looks at the current context hierarchy upwards until
it finds a "StaffGroup" as a parent. The layer below that is the
context to move, and if it is significantly similar in specification to
the context that should be/become its parent, it might become hard to
move back and forth.
So it's likely a bit of work/thought to make sure one does not create
context trapdoors from which it is hard to escape. Hovercraft parent
contexts.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Change_iterator refuses to move a NullVoice into a Staff
Dan Eble writes:
> %{
> NullVoice is unlike a Voice in this respect: trying to move it to a
> different Staff with \change fails with this warning:
>
> Change_iterator::process (): NullVoice = `soprano':
> cannot change `Staff' to `S': not changing to same context type: Staff
>
> Apart from the warning, this is inconvenient. The NullVoice remaining
> in the original staff keeps the original staff alive, demanding manual
> work to make it disappear.
>
> The NullVoice context definition contains both of the following:
>
> \alias "Staff"
> \alias "Voice"
>
> My knowledge of contexts is not extensive, but I suggest that the test
> that \change applies is too simple.
The test is
else if (it.get_outlet ()->is_alias (to_type))
{
// No enclosing context was found because the iterator's immediate
// context is the kind that was sought.
/* We could change the current translator's id, but that would make
errors hard to catch.
last->translator_id_string () = get_change
()->change_to_id_string (); */
result = _f ("not changing to same context type: %s", ly_symbol2string
(to_type).c_str ());
}
and that's indeed crapola. What the test should do is check whether the
current context type would be accepted into the hierarchy of the
proposed parent.
A more rigid test would be to check whether the current context type
would be accepted by the parent directly. But I'm not sure we should
rely on such knowledge as a user interface: there might be good reasons
for moving additional (mostly implicit) layers into the context
hierarchy without having to change the bulk of the music.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
