Re: how to enter notes quickly (midi keyboard available)

[David Kastrup]

Klaus Föhl <address@hidden> writes:

>> 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.

It would be a text property (you want to have it follow copy&paste).
And mouse-over could give a guess.  But I would think that it would be
distracting if the stuff would flicker around while you are doing note
entry.

> 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.

It would not necessarily be required to tell: it should be reasonably
workable to guess how many measures are in between once the editor has
"got the hang" of the timing.

>> 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.

Whatever approach you choose, I think it important to be able to pepper
additional quantization information in between where required, without
prescribing a rigid workflow.  You basically want to _converge_ to the
right solution using the provided help on the fly.

> To establish the main "wise quantisation" algorithm, including
> externally accessible tuning/adjusting parameters.

I think that painless interactivity beats smart batch mode in this case.
Your mileage may differ with an excellent sightreading keyboard player
playing to a rhythm computer.  But I know that when I do a recording
(for Youtube etc) it takes a _lot_ of takes until I get something
half-way decent.  And it would be stupid to have one measure of junk
ruin the whole take, when you can just delete it with the editor.

Of course, you also need to be able to replay sound, to figure out where
the junk is sitting.

The main thing, in my opinion, is the smoothness of
editing/correction/clue providing interactivity.  If you get that right,
"pretty good" for the quantization will work fine.

You can also do things like show hand-entered durations in a "definite"
color, and derived durations shaded.  You can validate the derived stuff
and it become definitive.  And so on.

You don't type a whole article in one piece, and retype from the
beginning if you made a mistake.  So why expect this from music entry?

-- 
David Kastrup