[Top][All Lists]

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

Re: midiPanPosition in midi context block

From: David Kastrup
Subject: Re: midiPanPosition in midi context block
Date: Mon, 11 Nov 2019 14:16:42 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Matt Wallis <address@hidden> writes:

> On 08/11/2019 14:30, David Kastrup wrote:
>> 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 ""
>>> 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.
> Strong words! My code,  above,  was the result of an error in
> pasting.

Nevertheless it was accepted by LilyPond.

> What I had meant to do is this:
> \score {
>   <<
>     \sopStaff
>     \altoStaff
>     \context Staff = "sop" {
>       \set Staff.midiPanPosition = #1.0
>     }
>     \context Staff = "alto" {
>       \set Staff.midiPanPosition = #-1.0
>     }
>   >>
>  \midi { }
> ... which works. But now I'm worried, because the example I copied was
> from other code I have written. Is this another abomination?

Normally, I'd not use \context here but \new .  Mind you: the issue with
\new inside of the \midi block would have been the same.

> I look forward to the day when I understand enough about how lilypond
> works internally in order to avoid abominations that happen to get
> past the parser.

Me too.

> Perhaps someone could point me to the relevant syntax reference docs
> that say (or at least imply) that my original abomination is illegal
> syntax, and to check that my amendment (above) is valid syntactically.

I don't think that we spell out "illegal syntax" a lot since, well,
there is more invalid syntax than valid syntax in general.  Where things
are less than clear, using copy&paste examples preserving structure
tends to be more on the safer side.

> I've had a look for some reference material, and found this
> (
>    "Output definitions define the relation between contexts as well as
>    their respective default settings. While most changes will usually
>    be made inside of a|\layout|block, Midi-related settings will only
>    have an effect when made within a|\midi|block."
> This does little to discourage my abomination.

You seem to be hung a bit on my strong verbiage.  It wasn't supposed to
be a personal criticism but rather expressed my dismay that the
combination of what LilyPond flags as problematic and what our manuals
and examples suggest led to a result that I had not expected to see.  I
wasn't blaming you for it.

> Also, itmakes me suspect that my code above (with the context block
> within the score) is also working only by accident (because it sets
> midi settings outside the midi block). So, am I right in thinking that
> the only legal place for midi settings for a Staff as inside the
> original definition of that Staff?

Well, "legal" is a strong word.  You are not going to get arrested.
It's more about "dependable", and you have already noticed that it
doesn't do what you expect.

>> Then create different variables/expressions for that purpose.  But the
>> \midi block cannot sensibly differentiate between differently named
>> contexts.
> Thanks for the advice. I shall use variables.

Harm already showed how to "unsensibly differentiate" but I think it is
really weird to go via that route.  Using variables seems like a better

David Kastrup

reply via email to

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