Re: convert-ly produces invalid output for KeySignature.c0-position

[David Kastrup]

Pavel Roskin <address@hidden> writes:

> Quoting David Kastrup <address@hidden>:
>
>> Small wonder.  I thought our default use of symbols matched our naming
>> rules, but that one's an exception.
>>
>> We can make an exception for convert-ly here, but that's not a
>> satisfactorily final solution.
>>
>> I propose renaming it.  Suggestions?
>
> I'm fine with renaming.  We have Staff.middleCPosition.  Perhaps the
> same name could be used in KeySignature.
>
> On the other hand, we don't care where the _middle_ C is positioned.
> We only need to know where _some_ C is positioned to decide how to
> print the key signature.  Then "middle" could be dropped.
>
> By the way, setting KeySignature.c0-position with \override doesn't
> work.  I had to resort to setting it in Scheme:

Well, we have
void
Key_engraver::create_key (bool is_default)
{
  if (!item_)
    {
      item_ = make_item ("KeySignature",
                         key_event_ ? key_event_->self_scm () : SCM_EOL);

      /* Use middleCClefPosition rather than middleCPosition, because cue
       * notes with a different clef will modify middleCPosition. The
       * Key signature, however, should still be printed at the original
       * position. */
      item_->set_property ("c0-position",
                           get_property ("middleCClefPosition"));

So the KeySignature grob is created (which triggers all overrides and
tweaks on c0-position), and then right away c0-position is overwritten.

There is also

          if (scm_is_pair (restore))
            {
              cancellation_ = make_item ("KeyCancellation",
                                         key_event_
                                         ? key_event_->self_scm () : SCM_EOL);

              cancellation_->set_property ("alteration-alist", restore);
              cancellation_->set_property ("c0-position",
                                           get_property ("middleCPosition"));
            }
        }

in the context of a set printKeyCancellation property.  Personally, it
looks quite fishy to me that those (both in Key_engraver::create_key)
would consult different properties.  It probably does not happen all
that often that you place a key change in the middle of a cue passage,
but if you do, it looks like it would look bad.

> Perhaps c0-position can only be set together with other properties to
> have an effect.  Or maybe it's not meant to be set.

The latter, I think.

> But I need to change it when I want the key signature to correspond to
> the staff clef that is not in effect on the first note (the staff clef
> is bass, and the first note is after the treble clef).

What about changing middleCClefPosition instead?

-- 
David Kastrup