Re: instrumentSwitch and addInstrumentDefinition use

[Kieren MacMillan]

Hi Keith,

> I understand that in realistic cases you probably have the notes in one 
> variable and options for arrangements in another parallel sequence
>  flute_notes = {c'2 c'' .... }
>  arrangementB = {s1*4 \prep_alto_flute s1*4 \switch_alto_flute s1*8 }
> and it is not so convenient to break flute_notes into segments for the 
> individual \transpose{}s.

Correct on both counts.
(n.b. I *do* break flute_notes up when absolutely necessary… but I definitely 
wouldn’t call it “convenient”.)

> LilyPond has the quote/cue mechanism, where \addQuote "fluteNotes" 
> \flute_notes creates a sequence that is treated as concert pitches, as you 
> wanted and as I used in my last email.  There are some bugs with addQuote, of 
> which only 1823 makes me hesitate to recommend it
>  http://code.google.com/p/lilypond/issues/list?q=%5CquoteDuring

It would be interesting to compare all the different possible mechanisms of 
getting what I (we?) want, showing their advantages, disadvantages, and current 
roadblocks. Perhaps I’ll put together a draft of such a paper sometime soon.

> For your desired input method, you want the converse of LilyPond's usual 
> actions :
>  1) apply the \transposition to the music to determine what notes to print
>  2) send the notes in the music expression directly to MIDI

I have used Lilypond’s MIDI function(s) exactly twice in 13 years.  ;)

> (Maybe that would have been a better design from the beginning, for use by 
> composers, but it would probably have confused new users and been less 
> convenient for transcribing existing music.)

The fact that transcribing existing music was a fundamental design choice (as 
opposed to a “how can we do that, now that the best possible tool has already 
been designed”) is both evident and (IMO) unfortunate.

As for “confusing to new users”, I’ve recently realized — during my painful 
transition (and file translation) from using \relative mode to avoiding it at 
all costs — that we should probably [only] be adding syntactic sugar for new 
users, not designing the basic code with them in mind.

> This made me think that LilyPond's note_heads_engraver could adopt that 
> behavior upon when instructed
>   \set concertPitchInput = ##t
> then note_heads_performer would take the converse behavior for MIDI, then we 
> figure out appropriate behavior for note_name_engraver and 
> fretboards_engraver and chord_names_engraver and …

OOH! That sounds promising!

> Well, if the notes are right there, and you can put them in {},
>  \instrument_alto_flute { ... }  \instrument_tenor_sax { ... }
> then we (including the braver non-programmers among us) can write music 
> functions to set up for the new instrument and transposes the stuff in {} 
> using the usual LilyPond commands.

Is that the best way?

> The instrumentSwitch mechanism we had before seemed less convenient than the 
> way you wrote your \play_alto above, and it did not handle the transpositions 
> which is the tricky bit.

Yes… After Han-Wen had completed the sponsored programming (back in 2006, I 
believe), I came to that sad realization.

> I assume again that in realistic cases you have the notes in one variable, 
> and then you make different instrumental arrangements with parallel music or 
> something fancier like \push-to-tag, so that LilyPond can't be sure exactly 
> what music will be played by alto flute until the input expressions are 
> combined in a <<>> or \push-to-tag or whatever.
> 
> If my assumption is true, then to handle the transpositions the way you would 
> like, we could
> A) take JanPeter's approach of waiting until engraving to figure out what 
> music is in what transposition,
> B) teach the existing engravers to behave differently depending on 
> 'concertPitchInput, which we could set in our \instrument"alto flute" or 
> \instrument_alto_flute, or
> C) write a function \transposeConcertToWritten, that iterates through the 
> music (keeping track of timing in <<>> constructs) to figure which 
> transposition holds for each note and converts \tranposition to 
> \transpositionUpdateKey, which we would apply to the assembled music just 
> before the it goes into \new Staff (where we often use \keepWithTag)

Each has its benefits, I suppose. A) gives lots of flexibility, but adds 
complexity, at least given the current editionEngraver implementation. B) seems 
the simplest to document/describe/teach; is there a downside? C) sounds like a 
nice post-hoc solution, but what about performance?

Thanks,
Kieren.
_______________________

Kieren MacMillan, composer
www:  <http://www.kierenmacmillan.info>
email:  address@hidden