Re: midiPanPosition in midi context block

[David Kastrup]

Thomas Morley <address@hidden> writes:

> Am Fr., 8. Nov. 2019 um 15:35 Uhr schrieb David Kastrup <address@hidden>:
>>
>> Matt Wallis <address@hidden> writes:
>>
>> > But it doesn't work if I try to set the midiPanPosition inside a midi
>> > context block like this:
>> >
>> > \version "2.19.83"
>> >
>> > \include "english.ly"
>> > sopStaff = \new Staff = "sop" {
>> >   \relative c' { e4 f g a }
>> > }
>> > altoStaff = \new Staff = "alto" {
>> >   \relative c' { c4 d e f }
>> > }
>> > \score {
>> >   <<
>> >     \sopStaff
>> >     \altoStaff
>> >   >>
>> >   \midi {
>> >     \context Staff = "sop" {
>> >       \set Staff.midiPanPosition = #1.0
>> >       \set Staff.midiBalance = #1.0
>> >     }
>> >     \context Staff = "alto" {
>> >       \set Staff.midiPanPosition = #-1.0
>> >       \set Staff.midiBalance = #-1.0
>> >     }
>> >   }
>> > }
>>
>> This is terrible.  Really, really terrible.  \context Staff = "xxx"
>> should never be allowed in an output block since setting name-specific
>> context defs is not supported and does not make sense, either.  I'll see
>> whether I can stop the parser from accepting this abomination.
>> >
>> > Furthermore, the result of doing this is that both staffs are played
>> > through the left, and nothing on the right.
>> >
>> > Am I doing something wrong?
>>
>> As a rule, changing syntax until something passes the parser instead of
>> working from documented syntax and examples is a bad idea.  Most of the
>> time, you'll trigger error messages pinpointing the problem.
>>
>> But sometimes there are oversights.
>>
>> > I want to do the setting in the midi context block because I require
>> > different pan positions for a staff depending on which score it
>> > appears in.
>>
>> Then create different variables/expressions for that purpose.  But the
>> \midi block cannot sensibly differentiate between differently named
>> contexts.
>
> Below seems to work for \layout.

Well, there was a reason I wrote "cannot sensibly differentiate" rather
than "cannot differentiate".

> \version "2.19.83"
>
> idFontSize =
>   \applyContext
>     #(lambda (ctx)
>       (ly:context-set-property! ctx 'fontSize
>         (cond ((string=? (ly:context-id ctx) "foo")
>                -6)
>               ((string=? (ly:context-id ctx) "bar")
>                6)
>               (else (ly:context-property ctx 'fontSize)))))
>
> \score {
>   <<
>     \new Staff = "foo"  \relative c' { e4 f g a }
>     \new Staff = "bar"  \relative c' { c4 d e f }
>   >>
>   \layout {
>     \context {
>       \Staff
>       \idFontSize
>     }
>   }
> }
>
> Didn't test for midi, though, why shouldn't the method work there as well.

Sure, it would.  But that's not really what output definitions are for:
if you want different behavior, the proper solution is to create
different context types.

It's comparatively easy to disallow
\context ... { }
in an output definition and get something like
    dak@lola:/tmp$ /usr/local/tmp/lilypond/out/bin/lilypond zing.ly
    GNU LilyPond 2.21.0
    Processing `zing.ly'
    Parsing...
    zing.ly:16:14: error: syntax error, unexpected SYMBOL, expecting '{'
        \context 
                 Staff = "sop" {
    zing.ly:20:14: error: syntax error, unexpected SYMBOL, expecting '{'
        \context 
                 Staff = "alto" {
    zing.ly:25:2: error: Unfinished main input
    }

The problem with that is that something like

    \override Staff.InstrumentName.color = #red
    
in an output definition is allowed and _does_ create what amounts to

    \context Staff { \override InstrumentName.color = #red }
    
which is translated into an override instruction for _all_ context
definitions having an _alias_ of Staff (rather than just \Staff itself),
so this also affects TabStaff and others.

So interfering here does not sound like the right solution.  It might
make sense to sound a warning for Staff = "sop" and similar though since
those cannot be implemented without contortions of the kind you
demonstrated and I don't think that a good idea.  It's also irritating
that this requires switching the syntax from prop = val and \override
Grob... to \set prop = val and \override Context.Grob...

-- 
David Kastrup