Re: Creating a coding system

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: schwab@linux-m68k.org,  emacs-devel@gnu.org
>> Date: Sat, 20 Dec 2014 18:38:23 +0100
>> 
>> Huh.  I'll look again, but I _did_ look in the manual previously.  Maybe
>> a coding system is not even the right way to do this
>
> Well, as I wrote elsewhere, I don't really understand what "this" is,
> so please consider elaborating.

Midi is a real-time byte-oriented protocol conveying musical data and is
primarily used for hooking up Midi-code generating keyboards with
Midi-playing devices (originally, a serial protocol at something like
31250  Baud over galvanically separated current-loop).

<URL:http://www.gweep.net/~prefect/eng/reference/protocol/midispec.html>
contains some useful information.  The raw midi messages, as read from a
midi device, contain information like "key-on on channel #9 with pitch
#83 and velocity #112".  Command bytes are #128 to #255, data bytes are
#0 to #127 and most commands come with a fixed amount of data anyway.
So resynchronization for lost bytes is usually immediate.

There are also Midi _files_: those contain additional data, most
particularly an encoding of the _timing_ of events (because as opposed
to ordinary written text, the timing of events is crucial for Midi).
Those are, more or less, the preferred storage format for "Midi
sequencers" which are able to produce or reproduce a timed stream of raw
Midi events.

There is some age-old application called "rumor" that converts Midi
messages into input for the music typesetter LilyPond, and rumor can be
hooked up with some Emacs mode.  All that is pretty arcane and not all
that well-supported.

Since Emacs can use make-serial-process for opening a raw Midi port, the
idea was to bypass the additional executable and create an application
useful for directly interfacing with Midi keyboards so that one can at
least key in pitches faster than by using a computer keyboard.

Part of the reason this may be faster than a computer keyboard is that
the typical musician looks at a score, employs some cognitive
processing, names the resulting pitch, translates it into LilyPond's
representation of a pitch (see
<URL:http://www.lilypond.org/doc/v2.19/Documentation/notation/writing-pitches>)
and then types it in using multiple keypresses.

With a Midi keyboard, typing the pitch entails looking at the score and
typing a single key (or a whole sequence of keys) using pretrained
visual/motoric connections.

Now the first iteration would be just using the pitches from a Midi
keyboard.  The second iteration would then try working with durations.
Either by putting time stamps on the events as they trundle in, or by
reading from a "cooked" Midi stream already containing encoded time time
stamps.

Conversion of time stamps to musical durations, particularly when the
time stamps have not been generated by a notation program but by a human
player, is non-trivial and would hopefully end up as an incremental
process where a human corrects durations and Emacs improves its overall
guesswork.

But time stamps are for another time.  Right now I'd be glad just to
convert the pitches from they keyboard into LilyPond's pitch notation in
order to make key entry faster.

-- 
David Kastrup