midi with ctypes

[Anton Vredegoor]

Recently there has been a lot of progress concerning the integration
of midi into python. A midipy.cpp for Python20 is found and various
compiling efforts having been undertaken to compile it for Python23.
See the other threads about midipy.cpp for more info.

However, seeing that the resulting midipy.pyd is only 48 kilobyte long
and seeing that midipy.cpp exports only 14 functions, most of which
are inside winmm.dll (for W98 and W2000 at least) I decided to start
another effort, which I'm presenting below and for which I hope kind
people will add some functions since I doesn't seem to be too hard.

first create a winmm.def like this:

pexports winmm.dll > winmm.def

Now open winmm.def and find the relevant functions, compare them with
what's inside midipy.cpp and try to reproduce them using ctypes. The
file "mmedia.hlp" from Borland C++ Builder for example, contains
detailed info about midi functions, most of which seem to be direct
wrappers around the functions inside winmm.dll .

Now to get started try this:

#ctypesmidipy.py

from ctypes import *

def getNumMidiInDevices():
return windll.winmm.midiInGetNumDevs()

def getNumMidiOutDevices():
return windll.winmm.midiOutGetNumDevs()

def test():
print getNumMidiInDevices()
print getNumMidiOutDevices()

if __name__=='__main__':
test()

Please note that after importing this file every function should work
the same as if midipy.pyd had been imported. Not being very familiar
with midi programming I succeeded only to get 2 of the 14 functions
working. Getting more functions to work should be harder, but not very
hard. Please, anybody reading this, add a function if there's a sudden
insight into how it should be done. By and by ctypesmidipy.py will be
put together like a little pypy-alike project replacing midipy.cpp :-)
Any feasibility studies and remarks about possible legal objections to
this are very welcome too.

Anton

[Anton Vredegoor]

da*******@yahoo.com (dan) topposted:

Interesting idea, but frankly it seems like alot of extra overhead.
Now that midipy is compiling, I'm more inclined to add features in C
than using ctypes.
The microsoft visual C compiler is about half a gigabyte size, the
soundfont SDK from creative labs is about 20 megabyte size, the OSC
toolkit is about 3 megabyte size, the midipy.cpp is a few kilobyte
size.

Compare this with the ctypes solution: ctypes itself is about half a
megabyte size and the ctypesmidipy.py is taking a few kilobytes.

From this comparison one could conclude that the overhead is largely
on the side of the current solution using C.
What advantages can we expect from doing it this way?

The ctypes solution is cheaper, there are less license issues because
there are less parties involved, it's a lot less code so it's easier
to understand and maintain, programming this module in Python gives
extra flexibility, and most importantly this could be a platform
independent solution for MIDI programming. That would earn Python
extra kudos from music programmers.

Anton

[Anton Vredegoor]

da*******@yahoo.com (dan) wrote:

One point worth thinking about: a serious MIDI library would include a
method for scheduling low-level routines at exact times (similar to a
sound output buffer). This would almost by definition require some C
code.

At some level these samples must be computed by the hardware, but MIDI
is about controlling this hardware at a higher level. Maybe we can get
away with less exact timing for which Python would be fast enough.

Anton

[Thomas Heller]

an***@vredegoor.doge.nl (Anton Vredegoor) writes:

da*******@yahoo.com (dan) topposted:

Interesting idea, but frankly it seems like alot of extra overhead.
Now that midipy is compiling, I'm more inclined to add features in C
than using ctypes.

The microsoft visual C compiler is about half a gigabyte size, the
soundfont SDK from creative labs is about 20 megabyte size, the OSC
toolkit is about 3 megabyte size, the midipy.cpp is a few kilobyte
size.

Compare this with the ctypes solution: ctypes itself is about half a
megabyte size and the ctypesmidipy.py is taking a few kilobytes.

From this comparison one could conclude that the overhead is largely
on the side of the current solution using C.

What advantages can we expect from doing it this way?

The ctypes solution is cheaper, there are less license issues because
there are less parties involved, it's a lot less code so it's easier
to understand and maintain, programming this module in Python gives
extra flexibility, and most importantly this could be a platform
independent solution for MIDI programming. That would earn Python
extra kudos from music programmers.

There may even be another advantage (in the future): the ctypes solution
may be more portable. Bradley Schatz has started porting ctypes to Java,
and so it seems also usable from Jython. Not to speak of pypy...

Thomas