midi with ctypes

[dan]

Ok, interesting points.  But what I think is important is that we
agree on a cross-platform interface, ie a set of python routines that
cover everything you want to do with MIDI.  I agree that ctypes looks
like an easy way to do this quickly.  Later on, we could re-implement
in C/C++ if this seems necessary for performance reasons or any other.

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.

anton at vredegoor.doge.nl (Anton Vredegoor) wrote in message news:<bgvnvq$sfk$1 at news.hccnet.nl>...
> danbmil99 at 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