From: joakim@verona.se
To: David Kastrup <dak@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Integrating Midi into Emacs
Date: Fri, 09 Jan 2015 22:21:18 +0100 [thread overview]
Message-ID: <m31tn3sl9t.fsf@exodia.verona.se> (raw)
In-Reply-To: <87fvbttoa9.fsf@fencepost.gnu.org> (David Kastrup's message of "Fri, 02 Jan 2015 12:28:14 +0100")
David Kastrup <dak@gnu.org> writes:
> Hi,
>
> 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.
>
> Here are several respects causing a bad fit:
>
> a) user expectation will be to have music keyboard keys insert into the
> selected window. make-serial-process can not really have the process be
> tied into one editing buffer since those editing buffers run processes
> of their own (viewer, compilation with LilyPond etc) and
> get-buffer-process is used for checking for conflicts. Also, one cannot
> reattach the process to different buffers when buffers are getting
> switched. So basically make-serial-process happens for a buffer of its
> own, and this buffer distributes the received information through its
> process filter. This process filter then does something akin to
>
> (defun notename-filter (process string)
> (with-current-buffer (window-buffer)
> (if (= (aref string 0) ?\ )
> (if (and (= (window-point) (process-mark process))
> (eq (current-buffer) (marker-buffer (process-mark process))))
> (insert string)
> (insert (substring string 1)))
> (insert string))
> (move-marker (process-mark process) (window-point) (current-buffer))))
>
> Apart from the complications arising from trying to put spaces between
> successive entries only if no editing happened in between, the thing to
> note is that this works on (window-buffer), the currently selected
> buffer. It is not clear how many save-excursions may intervene, and
> when a process filter actually gets triggered. So point and mark in the
> buffer may or may not terminally advance. One really would want to feed
> this through the regular input queue instead of going directly into some
> buffer.
>
> Which gets us to point
> b) Ultimately, input should be time-stamped. It's reasonably easy to do
> this using the process-filter, tacking on appropriate text properties,
> but the timestamp may be slightly stale when Emacs is busy as process
> filters are only run at appropriately idle times.
>
> 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. They would want timestamps like mouse
> events, they would want some identifiable nice names/identifications for
> binding them to actions. Since they are primarily going to be used as
> an input method with one hand on the computer keyboard and one hand on
> the Midi keyboard, it might even make sense to allow for keyboard
> modifiers like shift/alt/control in order to signify particular modified
> actions.
>
> So basically it would seem nice to extend the Emacs input events. That,
> in itself, feels like something that Emacs should support out of the box
> without recompilation. If it doesn't, it might be worth thinking about
> what might be necessary to make it do so. There is also a chance that
> an implementation along that lines could be made to work with XEmacs
> without requiring compilation.
>
> However, to really get timestamps with the accuracy of the arriving
> input, it would make sense to use the binary ALSA API for communicating
> with Midi input devices.
>
> One advantage of tieing Midi input in at a basic level might also be
> that one can use it to convey modifiers like Hyper and Super that avid
> Emacs typists might want to enter using foot pedals. The number of USB
> computer keyboards providing for Emacs-friendly foot pedals is
> minuscule. Midi-capable footpedals, however, are not exactly a dime a
> dozen but they are quite ubiquitous.
>
> So being able to exploit Midi signals with a timing accuracy making it
> possible to match them to computer keyboard input would make it much
> easier to acquire workable modifier pedals even for regular non-musician
> uses.
>
> 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
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!
--
Joakim Verona
next prev parent reply other threads:[~2015-01-09 21:21 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 [this message]
2015-01-09 21:59 ` David Kastrup
2015-01-10 8:32 ` joakim
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m31tn3sl9t.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).