On 2014/03/29 00:44:17, Devon Schudy wrote:
dak wrote:
> If not (I actually don't know), it seems like making it rather part
of
> the midi block might be more appropriate. In which case we would
not
> need to store it separately as it would then be part of > performance_->midi_.
Oh, yes, that's much simpler.
...however, while documenting it, I noticed a problem that makes the feature nearly useless: the speed of MIDI time depends on the tempo, which isn't set until the beginning of the score, so the extra time is at some other tempo (probably 4 = 120). It might still be useful to align multiple tracks generated by Lilypond (but why not generate them as one file?) or as input to other programs that want time in MIDI ticks rather than seconds, but it's not much good for aligning the MIDI to either musical or real time.
Actually, the factors and numbers that the \tempo statements produce in Midi seem strange (when one tries finding definitions for them) but that's an entirely different problem. It would seem that the conversion of the offset into ticks could happen when the first item is going to be shipped. It's by now abundantly clear that midiStart adds non-trivial additional complexity to this patch, with problems of its own. As I suggested previously: better resubmit this patch without midiStart in it in its original form (yes, we took a lot of time and work just to arrive at the same point again) and open a separate issue for midiStart. https://codereview.appspot.com/73610044/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
