From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: Integrating Midi into Emacs Date: Sat, 10 Jan 2015 09:32:37 +0100 Message-ID: References: <87fvbttoa9.fsf@fencepost.gnu.org> <87lhlbmx7l.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1420878802 2541 80.91.229.3 (10 Jan 2015 08:33:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Jan 2015 08:33:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 10 09:33:17 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y9rTx-0001Zj-Ix for ged-emacs-devel@m.gmane.org; Sat, 10 Jan 2015 09:33:17 +0100 Original-Received: from localhost ([::1]:54518 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9rTw-0006KT-N4 for ged-emacs-devel@m.gmane.org; Sat, 10 Jan 2015 03:33:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9rTs-0006Jh-86 for emacs-devel@gnu.org; Sat, 10 Jan 2015 03:33:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y9rTq-0006ZW-7f for emacs-devel@gnu.org; Sat, 10 Jan 2015 03:33:12 -0500 Original-Received: from mx2.bahnhof.se ([213.80.101.12]:44514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9rTm-0006YH-DA; Sat, 10 Jan 2015 03:33:06 -0500 Original-Received: from localhost (mf.bahnhof.se [213.80.101.20]) by mx2-reinject (Postfix) with ESMTP id BA7C640BE7; Sat, 10 Jan 2015 09:33:05 +0100 (CET) X-Virus-Scanned: by amavisd-new using ClamAV at bahnhof.se (MF4) Original-Received: from mf4.bahnhof.se ([127.0.0.1]) by localhost (mf4.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVrZ+I48V7VU; Sat, 10 Jan 2015 09:32:57 +0100 (CET) Original-Received: from mta.verona.se (h-235-62.a149.priv.bahnhof.se [85.24.235.62]) by mf4.bahnhof.se (Postfix) with ESMTP id AF9963D7873; Sat, 10 Jan 2015 09:32:57 +0100 (CET) Original-Received: from localhost (unknown [127.0.0.1]) by mta.verona.se (Postfix) with ESMTP id 724DB529D2F; Sat, 10 Jan 2015 08:32:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at verona.se Original-Received: from mta.verona.se ([127.0.0.1]) by localhost (exodia.verona.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VKTuGt4Oj5l; Sat, 10 Jan 2015 09:32:37 +0100 (CET) Original-Received: from exodia.verona.se (www.verona.se [192.168.200.15]) by mta.verona.se (Postfix) with ESMTP id 3D7D8529D2C; Sat, 10 Jan 2015 09:32:37 +0100 (CET) In-Reply-To: <87lhlbmx7l.fsf@fencepost.gnu.org> (David Kastrup's message of "Fri, 09 Jan 2015 22:59:58 +0100") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 213.80.101.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:181126 Archived-At: David Kastrup writes: > joakim@verona.se writes: > >> David Kastrup 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 > ;; 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 . > > ;;; 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 ... > ;; Note Events are ... > ;; 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