[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 "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.
>
> 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
> (http://lilypond.org/doc/v2.19/Documentation/notation/contexts-explained):
>
> "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
fit.
--
David Kastrup