midi with ctypes

Discussion in 'Python' started by Anton Vredegoor, Aug 7, 2003.

  1. 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, Aug 7, 2003
    #1
    1. Advertising

  2. (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, Aug 8, 2003
    #2
    1. Advertising

  3. (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
     
    Anton Vredegoor, Aug 9, 2003
    #3
  4. (Anton Vredegoor) writes:

    > (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
     
    Thomas Heller, Aug 9, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hugo Villeneuve

    Java MIDI output device to MIDI Yoke.

    Hugo Villeneuve, Jul 4, 2003, in forum: Java
    Replies:
    0
    Views:
    951
    Hugo Villeneuve
    Jul 4, 2003
  2. Henk Punt
    Replies:
    0
    Views:
    398
    Henk Punt
    Jul 23, 2004
  3. Gilly
    Replies:
    6
    Views:
    430
    Ken Starks
    May 4, 2008
  4. Replies:
    0
    Views:
    504
  5. Asbjørn Bjørnstad
    Replies:
    0
    Views:
    441
    Asbjørn Bjørnstad
    Oct 9, 2008
Loading...

Share This Page