16 Dec
2004
16 Dec
'04
10:17 a.m.
Hi Peter,
I remember that I looked at nam a while ago, but I must
admit that I
didn't get very far with it. When I looked at your page again just now,
I noticed that the tar ball nam*.tgz has disappeared.
Sorry, my fault. It's up now FWIW.
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.
[...] 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. In that case,
you'd probably need to build in cross-process support for specific X
toolkits, which may prove more fun to think about than to actually
implement ...
I would like to suggest patching the applications you want to control
to support OSC; it might turn out to be the same amount of work, but
with more public benefit and less dependency on particular widget and
keybinding organisation (which can be a volatile thing). Unless, of
course, you want to control non-music applications, whose authors will
likely show little favour for OSC-enabling patches.
Cheers, Tim