all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: joakim@verona.se
To: David Kastrup <dak@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Integrating Midi into Emacs
Date: Sat, 10 Jan 2015 09:32:37 +0100	[thread overview]
Message-ID: <m3bnm7qbmi.fsf@exodia.verona.se> (raw)
In-Reply-To: <87lhlbmx7l.fsf@fencepost.gnu.org> (David Kastrup's message of "Fri, 09 Jan 2015 22:59:58 +0100")

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



  reply	other threads:[~2015-01-10  8:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-02 11:28 Integrating Midi into Emacs David Kastrup
2015-01-02 13:24 ` davi
2015-01-02 21:11 ` Christopher Allan Webber
2015-01-03  9:27   ` David Kastrup
2015-01-09 21:21 ` joakim
2015-01-09 21:59   ` David Kastrup
2015-01-10  8:32     ` joakim [this message]
2015-01-14  9:42       ` Niels Giesen
2015-01-14 10:49         ` David Kastrup
2015-01-14 11:20           ` David Kastrup
2015-01-09 22:06   ` David Kastrup
2015-01-10  8:28     ` joakim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3bnm7qbmi.fsf@exodia.verona.se \
    --to=joakim@verona.se \
    --cc=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.