hi,
you might be interested in pygame which has portmidi for python now in svn
(currently based on pyportmidi, but with a wrapper to make it use more pep-8
like API).
We also have some scripts for building portmidi on windows linking to the
correct C libraries for different python versions (2.4,2.5, 2.6,3).
Working on it this weekend, finishing off the pygame.midi module for the
pygame 1.9 release which is due in 3 weeks.
Pre release builds for win/mac (pygame.midi pygame.examples.midi).
http://thorbrian.com/pygame/builds.php
svn if you'd like to browse for the building code:
http://www.pygame.org/wiki/svn
cu,
On Sat, May 16, 2009 at 7:55 AM, Christopher Arndt <chris.ar...@web.de>wrote:
> Hi,
>
> Atsushi Eno schrieb:
> > I was trying to autotoolize portmidi and I have portmidi.dll and
> > porttime.dll for my C# binding, though with some manual changes.
> >
> http://github.com/atsushieno/portmidi-sharp/tree/e5070610f932a5ad2f9c0e00056e166a750f161e/portmidi-patches
> >
> > The win32 patch contains a build script and autogen.sh to build
> > required things. Though I haven't verified if it really works out
> > of the box.
>
> thanks for the hint and the patches. After I set up all the MinGW/msys
> stuff on my Windows VM (which includes compiling autoconf, automake and
> libtool), I managed to build the library with your patches. The
> "autogen.sh" script didn't work for me out of the box though. I had to
> uncomment the line that created the NEWS, README, etc. files and I also
> added the "--prefix=/mingw" option to configure.
>
> Also, it was not possible to configure & build in a separate build
> directory. I had to build in the portmidi source directory for
> everything to work.
>
> I described the whole process here:
>
> http://chrisarndt.de/projects/portmidizero/
>
>
> After the "make" step I had separate "libportmidi-0.dll" and
> "libporttime-0.dll" files in pm_win/.libs. A few questions about this
> result:
>
> - Is this the intended end result?
> - If yes, why does the lib name have the "-0" appended? Is this
> necessary or is this just a convention to allow for several versions of
> the lib to be installed?
>
> - Why are there separate dlls for portmidi and porttime? Would it be
> possible to roll them into one like it is done on OS X? The things is, I
> want to use the dll with the Python ctypes module (the standard foreign
> function interface module for Python) and when I load libportmidi-0.dll,
> the system tries to find and load libporttime-0.dll as well and so the
> latter has to be in a place where the windows library loading mechanism
> will find it.
>
> Thus is would not be possible to put it alongside the libportmidi-0.dll
> in the Python package. The same problem would affect other languages
> trying to load this lib dynamically, described in this debian portmidi
> package bug:
>
> https://bugs.launchpad.net/debian/+source/portmidi/+bug/93728
>
> > I kind of want to make those per-platform patches merged and make
> > it build everything (so far it only builds libraries) but haven't
> > spent time on it yet.
>
> Apart from the above described problems, your autotools patches work
> very well, so I'm all for including them into the portmidi distribution
> or maybe an "autotoolized" branch for beta testing should be created first.
>
>
> Chris
> _______________________________________________
> media_api mailing list
> media_api@create.ucsb.edu
> http://lists.create.ucsb.edu/mailman/listinfo/media_api
>
_______________________________________________
media_api mailing list
media_api@create.ucsb.edu
http://lists.create.ucsb.edu/mailman/listinfo/media_api
