Re: Cues (CueVoice) and quoted instrument name : InstrumentSwitch

[David Kastrup]

David Kastrup <address@hidden> writes:

> Xavier Scheuer <address@hidden> writes:
>
>> There is actually a snippet implementing "namedCueDuring" that use this
>> instrumentCueName!  And it seems to work well AFAICS.
>> http://lsr.dsi.unimi.it/LSR/Item?id=388
>>
>> It would be great if someone could "extend" cueDuring so it can take
>> *optional* arguments, like cueClef, instrumentCueName, etc.
>> A "\with-like" syntax:
>>
>>   \cueDuring #flute \with {
>>     instrumentCueName = "flute"  % if not set, do not print InstrumentCueName
>>     cueClef = "treble"  % if not set, no clef
>>     % or alternatively cueClef could be defined but printed only when
>>     % needed; in this case we need an automatic "thing" that should
>>     % know if the clef currently used by the "main instrument" is
>>     % the same as the clef used for the cue (quoted) instrument.
>>     cueDirection = NEUTRAL
>>     % actually I need this, currently we can only define cued UP or
>>     % DOWN but I have seen in many scores cues with normal ("neutral")
>>     % stem directions (idem for ties, slurs, etc. -> equiv. \oneVoice).
>>   } { R1 }
>>
>>
>> Maybe Reinhold would have better thoughts about this.
>
> I can offer to implement a ly:context-mod? predicate, also optional, for
> music functions, that would offer this syntax.  Note, however, that you
> could already employ this predicate as long as you use the following call
> syntax:
>
> \cueDuring #flute ##{ \with { instrumentCueName = "flute" } } { R1 }
>
> You just write
> cueDuring =
> #(define-music-function
>    (parser location what mods main-music) (string? (ly:context-mod?) 
> ly:music?)
>
> Then use something like
>   (or mods (a-call-creating-the-default-modifications))
> inside.
>
> Once ly:context-mod? is _properly_ supported as an argument type, you
> can remove the ##{ ... } around the \with.
>
> With the current approach to music function arguments, you will _need_
> to remove ##{ ... } if ly:context-mod? gets its own argument parsing
> support in the current manner (let's call it a €50 job, and I suppose
> that it's straightforward enough on the current code base that most
> programmers could do it, probably not requiring more than 30 lines
> total).
>
> With the stuff I am currently designing, Lilypond would not need special
> support for supporting either syntax in the call.  But that will likely
> take at least a month to get finished, and I suspect the changes to be
> rather controversial: Basically, pretty much all existing code would
> stay working, but there will be wagonloads of situations where totally
> "naive code" will rather surprisingly just do what was intended.  Rather
> dangerously close to GLISS status, but again: I doubt that much working
> code would be affected.

The current dev/syntax branch can work with context modification
arguments using either Scheme syntax or straightforward \with { ... }
and it will also permit them as optional arguments.

It is not yet the radical approach (just affects function arguments).
Still, I like the code: the actual change allowing context modifications
into arguments consists of two (identical) lines.

There go my €50...

-- 
David Kastrup