Check out the portmidi documentation. I am not much of a programmer, but I was able to get midi io working with portmidi quite easily, and it's the same library used by csound5. I'm beginning work on a portmidi/C++/FLTK front end to my csound gig rig, so I may be able to share code in some useful manner. Iain Atte André Jensen wrote:

Atte, I've cobbled together a very simple bit of code that splits MIDI events according to note values. I wouldn't use it in this form in any serious way, but it should be enough to give you an idea as to how to build MIDI routers with Python. In order to use it, say something like python midisplit.py 36 60 84 Now midisplit.py will create one MIDI input port and four output ports. Connect the output ports to soft synths or so, and the input port to a keyboard. If you hit a key on the keyboard, then midisplit.py will send it via its first port if the note is between 0 and 35, to the second port if the note is between 36 and 59, etc. Generally speaking, if you list n numbers on the command line, you get n+1 output ports, unless you give no arguments, in which case midisplit will revert to its default behavior of splitting at note 60. This code uses MidiKinesis libraries, available at http://www.math.tu-berlin.de/~brinkman/software/midikinesis/ Hope this helps, Peter

Atte, You're right, I'm not worried about performance. My main concern is that this simple router only deals with note on/off events and silently drops everything else. If I were to develop a full-fledged MIDI router, I would spend some time meditating on what to do with control change events and such since it's not entirely clear how to split those. Great! Don't hesitate to ask if you have any questions. Peter

I believe someone is also doing a python wrapper for portmidi too. Iain Peter Brinkmann wrote:

I've only skimmed this thread, but what was the problem with QMidiRoute? I tried it last night and it worked fine for splitting a keyboard. My only gripe is that it displays MIDI channels as 0-15 instead of 1-16. Seems like half of the linux audio apps use 0-15, and the others use 1-16. Not a showstopper, but kind of annoying. But that's another story... paul

On Tue, 2005-07-19 at 18:39 +0200, Arnold Krille wrote: It's equally broken on Windows, the MME devices are numbered Wave0/1, Wave2/3, but the ASIO channels are labeled "ASIO 1" through "ASIO 16". IMHO anything exposed to the user needs to be labeled from 1. I've never seen a mixing board that numbered the channels from 0... Lee

Hi Dave, Yup, given the specs of the MEP4, this sort of tool should be entirely straightforward to build. My hunch is that the GUI would take a lot more time than the actual MIDI code. I suppose it's time to document the ALSA Python bindings a little more fully. The API is supposed to be mostly explanatory, but some odds and ends may require explanations. I haven't done this so far because I wasn't sure how much interest there is, but this thread is giving me the impression that this may be worthwhile. Peter

Iain Duncan wrote: I second that! -- .''`. Peace, love & harmony : :' : Atte `. `' `- http://www.atte.dk

One potential advantage to doing it in csound is that it is also very easy to adjust for different latencies between various synths. What we did was store different delay latencies in a table, then the midi parser instrument looks up the appropriate delay, and delays ouput accordingly. As far as I know, doing real time timing in python is not very accurate. This also puts the midi parsing in the csound process, meaning that if you are using --sched with csound, you don't have to worry about preempting your midi input/output. Of course if you want that to be the case, then it doesn't work. Iain

On second thought, latency accomodation should be easy enough to build on top of the ALSA bindings;) Peter