> midi2ly, obviously. It sucks royally for human-created input. Look up > Viterbi decoders and/or hidden Markov chains for a plan how to do better.
So far I have mentally broken down the task into two main chunks: 1) establish the maths function/relation recording time versus music piece time 2) transform the note durations into something sensible While item two would in principle use the information from item two, my personal experience is that note_off/duration is usually less accurate than note_start_timing. > My personal approach would be to let Emacs record notes and timings via > Midi, and display just the notes without duration. You manually place > bar checks, and it then calculates the durations in between. If you > have "typos" in between, you just delete them before quantizing the > measure, and they are taken out including the time they took. So you would store the timing in a non-screen-visible location? Fair enough. If that were to work to not bar-check every single bar but optionally only start and end of a 4, 6, 8, in general n-measure phrase than that would give you a lean workflow. When it gets more complicated, you shorten bar-check intervals. > That would seem like an efficient workflow to me, without much of a bad > impact of playing errors and uneven timing: the consequences are local. Well, at the start I thought of supplying initial conditions, but the boundary conditions approach promises to be better in stability. > Of course, this is purely hypothetical for now, but it seems like a good > plan for somebody (TM) to implement. To establish the main "wise quantisation" algorithm, including externally accessible tuning/adjusting parameters. Cheers Klaus _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
