|Subject:||Re: Integrating Midi into Emacs|
|Date:||Wed, 14 Jan 2015 10:42:48 +0100|
Very interesting, I will try it with my Midi equipment!David Kastrup <address@hidden> writes:
> address@hidden writes:
>> David Kastrup <address@hidden> writes:
>>> I've been meddling with CCL programs and stuff for integrating Midi
>>> input received via make-serial-process into Emacs. I've encountered
>>> several puzzling design decisions and drawbacks.
>>> There are several crucial ones, however. At its core, pressing keys
>>> on a musical keyboard will result in the insertion of note names into
>>> the current buffer. This basically is similar to an input method.
>>> c) the inserted text actually depends on buffer-local variables, for
>>> example the current notename language (English writes cs for c-sharp,
>>> Dutch writes cis, Italian writes dod), and the current key (the Midi
>>> event for c-sharp is indistinguishable from d flat, and the decision is
>>> made based on the current key in the current piece). Switching CCL
>>> programs in the decoder is tricky as they do not lend themselves to
>>> closures with internal states. Also, one would need one closure per
>>> language/key pairing currently active.
>>> This kind of flexible back-and-forth mapping is actually better
>>> accomplished by swapping around keymaps rather than encodings.
>>> What this leads up to is that a better approach would be to have Midi
>>> events in the Emacs event queue.
>> Since you said "Thoughts", I have some.
>> - I'm building a combined computer/midi keyboard, and it would
>> be really nice to use it with emacs with your idea. (If I ever manage
>> to finish the project)
>> - I'm sure you considered OSC, but heres a link anyway:
> Never heard of it. I'll take a look eventually.
>> My idea with OSC was to embedd gtk sliders in a buffer, and drive a
>> softsynth made with Overtone with these sliders using OSC.
>> Anyway, good luck with your project!
> Here is the current pitch I am working with without recompiling the
> binary, so obviously not taking modifier keys or timings at the moment.
> Also, no strategy yet for encoding key-release events.
> You just call M-x midikbd-open RET, specify a raw midi device (if
> necessary, provided by the snd-virmidi module), and then you can choose
> yourself how you are going to bind the resulting key events.
> ;;; midi-kbd.el --- Create keyboard events from Midi input -*- lexical-binding: t; -*-
> ;; Copyright (C) 2015 David Kastrup
> ;; Author: David Kastrup <address@hidden>
> ;; Keywords: convenience, hardware, multimedia
> ;; This program is free software; you can redistribute it and/or modify
> ;; it under the terms of the GNU General Public License as published by
> ;; the Free Software Foundation, either version 3 of the License, or
> ;; (at your option) any later version.
> ;; This program is distributed in the hope that it will be useful,
> ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
> ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> ;; GNU General Public License for more details.
> ;; You should have received a copy of the GNU General Public License
> ;; along with this program. If not, see <http://www.gnu.org/licenses/>.
> ;;; Commentary:
> ;; This generates events from an ALSA Midi device. The names of the
> ;; events are modeled after the nomenclature of Emacs Calc's notenames.
> ;; Channel switching events are <Channel1> ... <Channel16>
> ;; Note Events are <C_-1> <Csharp_-1> ... <G_9>
> ;; Since Midi does not encode enharmonics, there are no *flat_* key
> ;; names: it is the job of the key bindings to establish tonality
> ;; beyond the chromatic pitch.
> ;; It would make sense to provide this kind of functionality directly
> ;; from within Emacs, making use of libportmidi. That way, it could
> ;; get supported by operating systems not providing a raw Midi port
> ;; accessible as a character device. This would also improve the
> ;; possibilities to integrate timing and modifiers into events like it
> ;; is done with mouse events.
> ;;; Code:
> ;; Should this be a char-table?
> (defvar midikbd-keys
> [C_-1 Csharp_-1 D_-1 Dsharp_-1 E_-1 F_-1
> Fsharp_-1 G_-1 Gsharp_-1 A_-1 Asharp_-1 B_-1
> C_0 Csharp_0 D_0 Dsharp_0 E_0 F_0
> Fsharp_0 G_0 Gsharp_0 A_0 Asharp_0 B_0
> C_1 Csharp_1 D_1 Dsharp_1 E_1 F_1
> Fsharp_1 G_1 Gsharp_1 A_1 Asharp_1 B_1
> C_2 Csharp_2 D_2 Dsharp_2 E_2 F_2
> Fsharp_2 G_2 Gsharp_2 A_2 Asharp_2 B_2
> C_3 Csharp_3 D_3 Dsharp_3 E_3 F_3
> Fsharp_3 G_3 Gsharp_3 A_3 Asharp_3 B_3
> C_4 Csharp_4 D_4 Dsharp_4 E_4 F_4
> Fsharp_4 G_4 Gsharp_4 A_4 Asharp_4 B_4
> C_5 Csharp_5 D_5 Dsharp_5 E_5 F_5
> Fsharp_5 G_5 Gsharp_5 A_5 Asharp_5 B_5
> C_6 Csharp_6 D_6 Dsharp_6 E_6 F_6
> Fsharp_6 G_6 Gsharp_6 A_6 Asharp_6 B_6
> C_7 Csharp_7 D_7 Dsharp_7 E_7 F_7
> Fsharp_7 G_7 Gsharp_7 A_7 Asharp_7 B_7
> C_8 Csharp_8 D_8 Dsharp_8 E_8 F_8
> Fsharp_8 G_8 Gsharp_8 A_8 Asharp_8 B_8
> C_9 Csharp_9 D_9 Dsharp_9 E_9 F_9
> Fsharp_9 G_9
> Channel1 Channel2 Channel3 Channel4 Channel5 Channel6 Channel7 Channel8
> Channel9 Channel10 Channel11 Channel12 Channel13 Channel14 Channel15 Channel16]
> "Map CCL program codes to symbols used as keycodes.
> CCL program `midikbd-decoder' produces 0..127 for the pitches and
> 128..143 for the channel switches. `midikbd-keys' maps this into
> symbols used as keycodes.")
> ;; CCL programs used in coding systems apparently don't save registers
> ;; across suspension so we don't use a coding system. Instead our CCL
> ;; program is run using ccl-execute-on-string in the filter routine.
> ;; That allows us to interpret all _completed_ Midi commands without
> ;; getting confused, and it also gives us a well-defined internal
> ;; state (namely one for every call of midikbd-filter-create).
> (define-ccl-program midikbd-decoder
> ((r1 = 16)
> (read r0)
> (if ((r0 & 240) == 144)
> (read-if (r2 < 128) ; pitch
> (read-if (r3 > 0) ; velocity
> ; Some Midi devices use velocity 0
> ; for switching notes off, so skip
> ; velocity 0 notes
> ((r0 &= 15)
> (if (r0 != r1)
> ((r1 = r0)
> (write (r0 + 128))))
> (write-repeat r2)))))
> (defun midikbd-filter-create ()
> "Create one Midi process filter keeping state across calls."
> (let ((state (make-vector 9 nil)))
> (lambda (_process string)
> (setq unread-command-events
> (nconc unread-command-events
> (mapcar (lambda (x) (aref midikbd-keys x))
> (ccl-execute-on-string 'midikbd-decoder
> state string t t)))))))
> (defun midikbd-open (file)
> "Open the raw Midi device FILE as a source for Midi input.
> This should be an ALSA device like \"/dev/snd/midiC1D0\". If your
> Midi producing device is a software Midi device, you might need to
> sudo modprobe snd-virmidi
> in order to have some virtual ALSA ports available as such raw Midi
> (interactive (list (read-file-name "Midi device: "
> "/dev/snd/" "midiC1D0" t nil
> (let* ((file (expand-file-name file "/dev/snd/"))
> (buffer (get-buffer-create (concat " *Midi process " file " *")))
> (oldproc (get-buffer-process buffer)))
> (if (processp oldproc) (delete-process oldproc))
> (make-serial-process :port file
> :speed nil
> :buffer buffer
> :coding 'raw-text
> :filter (midikbd-filter-create)
> :sentinel #'ignore
> :noquery t)))
> (provide 'midi-kbd)
> ;;; midi-kbd.el ends here
> Of course this is ongoing work, but what I got here is a nice
> self-contained module doing exactly one job, that of delivering events.
> And obviously, if one were to write native Midi support, that's exactly
> the scope of what this native Midi support would be supposed to do.
|[Prev in Thread]||Current Thread||[Next in Thread]|