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: i...@kierenmacmillan.info
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
