16 Dec
2004
16 Dec
'04
7:42 p.m.
Hi Tim,
Nope, that's not a
leak, as you already pointed out in your followup.
That's one of the
reasons why I think it may not work. My main concern
is that any such tool would require a lot of calibration, and it be
rather sensitive to any changes in the target GUIs.
In the
meantime, I've put together a little MIDI routing module for
Python and ALSA. I'm tentatively calling it pyseq, and you can find
it at
http://www.math.tu-berlin.de/~brinkman/software/pyseq.tgz
if you're interested. I'm using ctypes to expose the snd_seq_event
struct and ALSA functions to Python.
Ah, an interesting little piece of code. There seems to be a memory
leak in startMidiLoop() -- the pfds are never free()'d. I've been busy too in the meantime and added
snd_seq_* support to the
nam successor. Announcement following sometime soon.
Cool. I'm looking forward
to seeing the new version.
[...] The
solution I have in mind is to have Python map MIDI
control events to X events, which would, in theory anyway, let me
add MIDI controls to almost any GUI. I have a hunch that this idea
may not fly in practice, but I'm having fun thinking about it.
Python won't fly supersonic anyway; so as long as you're not expecting
sub-millisecond latency from your MIDI -> X signal path I don't see
why it shouldn't work. However, binding to certain widgets might prove
hard if they don't come with their own X Window ID. Unless, of course, you want to control non-music
applications, whose
authors will likely show little favour for OSC-enabling patches.
Well, at the very
least I'd like to keep the option of creatively
misusing MIDI events (how about a game of Pong, with paddles controlled
by MIDI sliders;).
Peter