Re: Change_iterator refuses to move a NullVoice into a Staff

[Dan Eble]

> On Apr 7, 2017, at 03:58, David Kastrup  wrote:
> 
>> Please try this.  I haven’t tested your patch.
> 
> I'm sort of annoyed at the somewhat roundabout \RemoveEmptyStaves bit
> but I guess that's likely a pretty direct way to figure out where the
> NullVoice went.  One doesn't get to see a lot of it otherwise.

I feel the same, but the only other idea I had involved lyrics, which
would have been more complicated.  In its favor, this test covers
something that I actually noticed rather than something contrived.

Thanks again for fixing the problem.
— 
Dan


___
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]

Dan Eble  writes:

>> Tracker issue:
>> 5116 (https://sourceforge.net/p/testlilyissues/issues/5116/)
>> Rietveld issue:
>> 322820043 (https://codereview.appspot.com/322820043)
>
> Thank you.
>
>> Could you rework your almost minimal example into a regtest?
>> Those give me much more of a headache than most code changes
>> since there is no "obviously best" regtest to aim for.
>
> Please try this.  I haven’t tested your patch.

I'm sort of annoyed at the somewhat roundabout \RemoveEmptyStaves bit
but I guess that's likely a pretty direct way to figure out where the
NullVoice went.  One doesn't get to see a lot of it otherwise.

I guess I'll take it.  Thanks.

-- 
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]

> Tracker issue:
> 5116 (https://sourceforge.net/p/testlilyissues/issues/5116/)
> Rietveld issue:
> 322820043 (https://codereview.appspot.com/322820043)

Thank you.

> Could you rework your almost minimal example into a regtest?
> Those give me much more of a headache than most code changes
> since there is no "obviously best" regtest to aim for.

Please try this.  I haven’t tested your patch.
—
Dan

%{
nullvoice-change.ly

NullVoice responds to \change Staff as a Voice would.  The first line
of the output is a single treble-clef staff.  The second line is a
single bass-clef staff.
%}

\version "2.19.58"

music = \fixed c' {
  c1
  \break
  \change Staff = "After"
  c
}

\new StaffGroup \with {
  \RemoveEmptyStaves
  \override VerticalAxisGroup.remove-first = ##t
} <<

  \new Staff = "Before" <<
\new NullVoice { \music }
  >>

  \new Staff = "After" {
\clef bass
$(skip-of-length music)
  }

>>
___
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]

Dan Eble  writes:

> 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?

Current branch: contextchange
Tracker issue: 5116 (https://sourceforge.net/p/testlilyissues/issues/5116/)
Rietveld issue: 322820043 (https://codereview.appspot.com/322820043)
Issue description:
  Allow \change to same context type  The \change command no longer
  refuses to change the parent of a context when the context itself
  would be of the proper type to change to.  This allows changing the
  parent of a context that could be nested, like StaffGroup in
  StaffGroup or NullVoice in Staff (since NullVoice is also aliased to
  Staff).

Could you rework your almost minimal example into a regtest?  Those give
me much more of a headache than most code changes since there is no
"obviously best" regtest to aim for.

Thanks

-- 
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]

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]

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

[David Kastrup]

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

Re: Change_iterator refuses to move a NullVoice into a Staff

[Dan Eble]

On Apr 4, 2017, at 22:57, Colin Campbell  wrote:
> 
> 
> Staff "S" doesn't have a NullVoice defined. I modified your code as follows, 
> and it seems to do what you want, although you still get a warning because 
> the \changeStaff event happens in both a regular Voice and a NullVoice.b

Thank you for taking the time, but your suggestion is not what I’m looking for. 
 I do in fact want what you have observed, but working: both the Voice and the 
NullVoice, at the moment that \change Staff = “S” appears, should move from 
their current Staff to Staff “S”.
— 
Dan


___
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

[Colin Campbell]

On 2017-04-04 07:54 PM, Dan Eble wrote:

On Mar 25, 2017, at 14:34, Dan Eble  wrote:

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




Staff "S" doesn't have a NullVoice defined. I modified your code as 
follows, and it seems to do what you want, although you still get a 
warning because the \changeStaff event happens in both a regular Voice 
and a NullVoice.b Perhaps others can take it further?


**

\version "2.19.54" %% just because it's what I'm using

sopranoNotes = \fixed c' {
  c1 d e f
  \break
  \change Staff = "S"
  g a b c'
}

\new ChoirStaff \with {
*% \RemoveEmptyStaves**
** % \override VerticalAxisGroup.remove-first = ##t*
} <<

  \new Staff = "S" \with {
instrumentName = "S"
shortInstrumentName = "S"
  }
*  \new NullVoice = "S" {*
$(skip-of-length sopranoNotes)
  }

  \new Staff = "SA" \with {
instrumentName = "SA"
shortInstrumentName = "SA"
  } <<
\new Voice { \sopranoNotes }
\new NullVoice = "soprano" { \sopranoNotes }
  >>

>>

*


HTH,

Colin

--
I think age is a very high price to pay for maturity.
-- Tom Stoppard
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond