On Tue, 15 Mar 2011 13:53:41 -0700, Jan Nieuwenhuizen <jann...@gnu.org> wrote:
To create a new track for each voice as we do now, still seems a bit like a kludge to fix MIDI's brokenness.
It is, at least, the same kludge others (classicalmidiconnection.com) use when they have more than 16 simultaneous lines of music. To have some sympathy for the brokenness, remember that MIDI is primarily a delivery protocol to playback hardware. I tried to summarize what the relevant classes do, and indicated the desired extensions in [[ ]] below : Objects of class Audio_staff correspond to MIDI tracks Each Audio_Staff contains the list of audio_items that will go onto a midi_track Objects of class Staff_performer correspond MIDI channels. Each Staff_performer has a channel number, optionally a MidiInstrument, midiMinimumVolume, etc., one [[or more]] objects of class Audio_Staff. This class implements the LilyPond performer "Staff_performer" Normally each Staff_performer gets a unique MIDI channel number, [[ but if midiChannelMapping==#'instrument then Staff_performers with the same midiInstrument share a channel number. Program-changes and midiVolume events from each Staff_performer will affect the shared MIDI channel.]] Staff_performer is responsible for routing Audio_items to the appropriate Audio_staff. Normally there is one Audio_staff per Staff_performer, [[ but if midiTrackMapping==#'voice then each uniquely-named Voice has its own Audio_staff.]] I still have the net change to midi output at http://codereview.appspot.com/4271043/ in case it is useful. Should the Audio_staff be "promoted" to Track_performer, in Voice context by default, and collect its own Audio_items? Do you still want all those maps ? _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel