Re: Integrating Midi into Emacs

[Niels Giesen <niels.giesen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 9511 bytes --]

Hi David,

This looks really cool to me. I tried to use your code, but cannot for the
life of me find out how to bind functions to those events. Could you give a
simple example?

It would be great if indeed all (details of) midi events could be made
available to Emacs.

By the way, it might be nice for Emacs to be able to act as a midi device
itself too, both for input and output in Alsa, and to be able to hook Emacs
up to other programs inside qjackctl or st..

Please keep us updated on this exciting work.

On Sat, Jan 10, 2015 at 9:32 AM, <joakim@verona.se> wrote:

> David Kastrup <dak@gnu.org> writes:
>
> > joakim@verona.se writes:
> >
> >> David Kastrup <dak@gnu.org> 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.
> >>>
> >>> Thoughts?
> >>
> >> 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:
> >>   http://delysid.org/emacs/osc.el
> >
> > 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.
>
> Very interesting, I will try it with my Midi equipment!
>
> >
> > ;;; midi-kbd.el --- Create keyboard events from Midi input  -*-
> lexical-binding: t; -*-
> >
> > ;; Copyright (C) 2015  David Kastrup
> >
> > ;; Author: David Kastrup <dak@gnu.org>
> > ;; 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
> >   '(1
> >     ((r1 = 16)
> >      (loop
> >       (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)))))
> >       (repeat)))))
> >
> > (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)))))))
> >
> > ;;;###autoload
> > (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
> > call
> >
> >     sudo modprobe snd-virmidi
> >
> > in order to have some virtual ALSA ports available as such raw Midi
> > devices."
> >   (interactive (list (read-file-name "Midi device: "
> >                                    "/dev/snd/" "midiC1D0" t nil
> >                                    #'file-readable-p)))
> >   (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.
>
> --
> Joakim Verona
>
>


-- 
http://pft.github.com

[-- Attachment #2: Type: text/html, Size: 12430 bytes --]