Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > midi with ctypes

Reply
Thread Tools

midi with ctypes

 
 
Anton Vredegoor
Guest
Posts: n/a
 
      08-07-2003
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
 
Reply With Quote
 
 
 
 
Anton Vredegoor
Guest
Posts: n/a
 
      08-08-2003
http://www.velocityreviews.com/forums/(E-Mail Removed) (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

 
Reply With Quote
 
 
 
 
Anton Vredegoor
Guest
Posts: n/a
 
      08-09-2003
(E-Mail Removed) (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

 
Reply With Quote
 
Thomas Heller
Guest
Posts: n/a
 
      08-09-2003
(E-Mail Removed) (Anton Vredegoor) writes:

> (E-Mail Removed) (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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Portable midi communication with external midi instruments? Asbjørn Bjørnstad Java 0 10-09-2008 03:03 PM
Real Time Midi File Playback - Reading and Writing midi at the sametime Gilly Python 6 05-04-2008 09:16 PM
D/L midi files launches a midi player I want the midi file Vlad Firefox 2 06-10-2005 02:25 AM
RE: [ctypes-users] [Ann] ctypes 0.9.0 released Henk Punt Python 0 07-23-2004 10:34 PM
Java MIDI output device to MIDI Yoke. Hugo Villeneuve Java 0 07-04-2003 10:31 PM



Advertisments