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
