headers
René Dudfield | 1 Mar 2012 15:06
Picon
Gravatar

Re: Mac OS X MIDI support success (MacPorts)

Nice one.  Thanks.

Do you want to make a pull request?  If not, I can apply the patch.

cheers,


On Tue, Feb 28, 2012 at 3:43 AM, Christopher Arndt <chris-zkhcXtCm3EBsjWhXrdlgMw@public.gmane.org> wrote:
Some people here on the list seemed to have had problems getting MIDI to compile / work on Mac OS X with the latest pygame.

I'm not sure which was the OS X version in question, but I have successfully compiled pygame from mercurial with MIDI support under OS X 10.6 and Python 2.7 from MacPorts.

I ran into a small problem with the configure script "config_darwin.py". At first it was telling me "Framework CoreMidi not found". A look through my ../Libraries folders told me that the name of the framework is wrong in the script: it's "CoreMIDI" not "CoreMidi".

This won't bite most users because by default the OS X filesystem is case-insensitive but mine isn't. This should be fixed.

I have written up my notes on compiling PyGame on OS X and attached a patch for config_darwin.py here:

http://trac.chrisarndt.de/code/wiki/PyGame

As you can see there, there are a few other issues with compiling on OS X but they don't concern MIDI, so I'll write about them in another post.

Here's a simple test I conducted to confirm that MIDi output works (I used fluidsynth as the tone genarator):

Python 2.7.2 (default, Feb 22 2012, 11:42:14)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
from pygame import midi
midi.init()
for i in xrange(midi.get_count()):
...     print midi.get_device_info(i)
...
('CoreMIDI', 'Netzwerk Session 1', 1, 0, 0)
('CoreMIDI', 'Netzwerk Session 1', 0, 1, 0)
('CoreMIDI', 'FluidSynth virtual port 2819', 0, 1, 0)
>>> import time
o = midi.Output(2)
>>> o.set_instrument(40)
for n in (72, 76, 79):
...     o.note_on(n, 100)
...     time.sleep(.5)
...     o.note_off(n)

... plays a broken C-major chord with strings.


Chris

Permalink | Reply | 3 comments |
headers
Christopher Arndt | 1 Mar 2012 19:57
Picon
Favicon
Gravatar

Re: Mac OS X MIDI support success (MacPorts)

On 01.03.2012 15:06, René Dudfield wrote:
> Nice one.  Thanks.
> 
> Do you want to make a pull request?  If not, I can apply the patch.

If you apply it, that would be nice. I don't have much experience with
hg yet.

You should probably split this in two commits:

1) Fixing the CoreMIDI framework name
2) Enhancing the method to look for headers in class Dependency

Also, I'm not sure if moving these lines (133f.):

    for d in DEPS:
        d.configure(incdirs, libdirs)

above the preceding for-loop is the right thing to do. It seems to me,
that the first for loop in its present form would *always* use the first
Dependency of each item in the DEPS list, because deptype.found would
never be true before calling configure() on each Dependency. Or am I
missing something here?

Chris
Permalink | Reply | 2 comments |
headers
Russell E. Owen | 2 Mar 2012 01:07

Re: Mac OS X MIDI support success (MacPorts)

In article <4F4C3F5D.4040600@...>,
 Christopher Arndt <chris@...> 
 wrote:

> Some people here on the list seemed to have had problems getting MIDI to 
> compile / work on Mac OS X with the latest pygame.
> 
> I'm not sure which was the OS X version in question, but I have 
> successfully compiled pygame from mercurial with MIDI support under OS X 
> 10.6 and Python 2.7 from MacPorts.

i'm one of those folks.

I was trying to build a pygame binary installer for the 32-bit 
python.org python. A binary installer requires static libraries for 
anything not likely to be found in the user's machine. So I build 
dependencies from source and throw away the dynamic libraries, rather 
than using MacPorts or similar package managers.

My problem is that I just can't figure out how to build portmidi from 
source -- at least on Mac OS X 10.4 (which is my usual platform for 
building such installers, as it turns out to be more reliably backward 
compatible) with gcc 4.0.1 (required for Mac OS X 10.4). The 
instructions are here: 
<http://sourceforge.net/apps/trac/portmedia/wiki/Installing%20portmidi%20
on%20Mac> but they don't work.

All other dependencies build fine. Thus the current mac binary pygame 
installer for 32-bit Python 2.7 does not have midi support (unless 
somebody has updated it).

-- Russell
Permalink | Reply | 2 comments |
headers
Christopher Arndt | 2 Mar 2012 01:59
Picon
Favicon
Gravatar

Re: Re: Mac OS X MIDI support success (MacPorts)

On 02.03.2012 01:07, Russell E. Owen wrote:
> My problem is that I just can't figure out how to build portmidi from 
> source -- at least on Mac OS X 10.4 (which is my usual platform for 
> building such installers, as it turns out to be more reliably backward 
> compatible) with gcc 4.0.1 (required for Mac OS X 10.4). The 
> instructions are here: 
> <http://sourceforge.net/apps/trac/portmedia/wiki/Installing%20portmidi%20
> on%20Mac> but they don't work.

What exactly isn't working? The instructions on the wiki are bogus, yes,
but I was able to build portmidi from SVN on 10.6 with the following
sequence of commands:

svn co
https://portmedia.svn.sourceforge.net/svnroot/portmedia/portmidi/trunk
portmidi
cd portmidi
cmake -G "Unix Makefiles"
make

(Note: there's no '.' (dot) after the make command.)

This gives me libportmidi_s.a and libportmidi.dynlib, libpmjni.dynlib
and the test programs compiled as well. I tested MIDI output with the
'test' program and fluidsynth and everything seemed ok.

I had installed a few programs and libraries with MacPorts before so I
already had all the dependencies, in particular "cmake". I think cmake
used the default C compiler gcc-4.2, but you should be able to specify
the compiler to use with:

cmake -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc-4.0 -G "Unix Makefiles"

(I'm not sure if this is the correct way to do this, but it seems to work.)

You may also need to set the SDK and the min OS X version (whatever that
means) to use:

cmake -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc-4.0 \
    -DCMAKE_C_FLAGS:STRING=-mmacosx-version-min=10.4 \
    -DCMAKE_OSX_SYSROOT:PATH=/Developer/SDKs/MacOSX10.4u.sdk \
    -G "Unix Makefiles"

Let me know, if these instructions work for you on 10.4 or if you want
me to send you the static library compiled with gcc-4.0 and the above
settings, to check if they work on 10.4.

Chris
Permalink | Reply | 1 comment |
headers
René Dudfield | 3 Mar 2012 17:36
Picon
Gravatar

Re: Mac OS X MIDI support success (MacPorts)

Hi,

you're right.  It picks the non framework build over the Framework build if they are both there.  Without your patch, when there is nothing in /usr/local, but there are Framework builds it does not work.

I'm not sure why the extra header search needs to be there?  Can you please explain why this is needed?

I've put your changes in with a few small changes.

cu.


On Thu, Mar 1, 2012 at 7:57 PM, Christopher Arndt <chris-zkhcXtCm3EBsjWhXrdlgMw@public.gmane.org> wrote:
On 01.03.2012 15:06, René Dudfield wrote:
> Nice one.  Thanks.
>
> Do you want to make a pull request?  If not, I can apply the patch.

If you apply it, that would be nice. I don't have much experience with
hg yet.

You should probably split this in two commits:

1) Fixing the CoreMIDI framework name
2) Enhancing the method to look for headers in class Dependency

Also, I'm not sure if moving these lines (133f.):

   for d in DEPS:
       d.configure(incdirs, libdirs)

above the preceding for-loop is the right thing to do. It seems to me,
that the first for loop in its present form would *always* use the first
Dependency of each item in the DEPS list, because deptype.found would
never be true before calling configure() on each Dependency. Or am I
missing something here?


Chris

Permalink | Reply | 1 comment |
headers
Christopher Arndt | 3 Mar 2012 21:12
Picon
Favicon
Gravatar

Re: Mac OS X MIDI support success (MacPorts)

Am 03.03.12 17:36, schrieb René Dudfield:
> you're right.  It picks the non framework build over the Framework build
> if they are both there.  Without your patch, when there is nothing in
> /usr/local, but there are Framework builds it does not work.

I think, that means I got it right, good. :)

> I'm not sure why the extra header search needs to be there?  Can you
> please explain why this is needed?

Because with MacPorts, the headers for SDL_image, SL_mixer, SDL_ttf etc. 
are installed under /opt/local/include/SDL (but SDL.h is installed 
directly under /opt/local/include). The PyGame sources use '#include 
<SDL_image.h' etc., so they wouldn't find them.

So I changed the check for the header files in Dependency.configure() to:

     for dir in incdirs:
         if isinstance(incnames, basestring):
             incnames = [incnames]
         for incname in incnames:
             path = os.path.join(dir, incname)

             if os.path.isfile(path):
                 self.inc_dir = os.path.dirname(path)
                 break

This allow to specify either a single header file or a list of header 
file locations with optional leading direcrtories (relative to one of 
the incdirs) and saves the directory of the found header in 
self.inc_dir, not the currently checked directory from incdirs. I could 
have just added '/opt/local/include/SDL' to the global incdirs, but with 
the changed code you can just specify extra include sub-directories for 
a single dependency. Still a bit of a kludge, but it works. :)

Chris
Permalink | Reply | 0 comments |
headers
Ian Mallett | 4 Mar 2012 08:52
Picon

Re: Mixing Colorkey and Surface alpha

On Wed, Feb 29, 2012 at 12:23 PM, Lin Parkh <lparkh-Wuw85uim5zDR7s880joybQ@public.gmane.org> wrote:

I have two surfaces. The source surface that I am blitting has a “surface alpha” set to give me semi transparency.  The destination surface has a transparent colorkey.  What I would like to have happen is that source surface makes semi transparent any pixels on the destination surface that are not transparent but otherwise ignores the colorkey pixels.  Is this possible?

As far as I am aware, and the way you're asking, no.  If you think about it, the destination surface is has binary transparency values (i.e., completely opaque or completely transparent).  What sort of data would you expect to store to get a semi-transparent colorkeyed surface?

My recommendation is to just use per-pixel alpha for just about everything.  You can pretty easily convert a colorkeyed surface into one.  At a guess, I would appreciate if the designers made .convert_alpha() do this--but if they didn't, the conversion would be pretty simple: loop through all pixels in the old surface, set the new surface's corresponding pixel's transparency to be either 0 or 255 based on what the RGB color is.  If you do this, then the blending operation you described above suddenly becomes trivial.

Ian
Permalink | Reply | 1 comment |
headers
Lynn Oliver | 5 Mar 2012 04:10
Picon

pygame installation on OS X 10.7.3

Hello,

It appears that the Mac binary install package pygame-1.9.2pre-py2.7-macosx10.7mpkg.zip does not include midi support (I get "ImportError: No module named pypm").

I have tried building from sources but without success.  I am able to install using MacPorts with the +portmidi option, but this creates an entirely new installation of Python and I've been unable to get all the other libraries at the proper level to be compatible with my current installation.

Would it be possible to get a binary version for OS X 10.7 that includes midi support?

Thanks,
Lynn
Permalink | Reply | 1 comment |
headers
Russell E. Owen | 5 Mar 2012 20:55

Re: Mac OS X MIDI support success (MacPorts)

In article <4F501B7F.3060603@...>,
 Christopher Arndt <chris@...> 
 wrote:

> On 02.03.2012 01:07, Russell E. Owen wrote:
> > My problem is that I just can't figure out how to build portmidi from 
> > source -- at least on Mac OS X 10.4 (which is my usual platform for 
> > building such installers, as it turns out to be more reliably backward 
> > compatible) with gcc 4.0.1 (required for Mac OS X 10.4). The 
> > instructions are here: 
> > <http://sourceforge.net/apps/trac/portmedia/wiki/Installing%20portmidi%20
> > on%20Mac> but they don't work.
> 
> What exactly isn't working? The instructions on the wiki are bogus, yes,
> but I was able to build portmidi from SVN on 10.6 with the following
> sequence of commands:
> 
> svn co
> https://portmedia.svn.sourceforge.net/svnroot/portmedia/portmidi/trunk
> portmidi
> cd portmidi
> cmake -G "Unix Makefiles"
> make
> 
> (Note: there's no '.' (dot) after the make command.)
> 
> This gives me libportmidi_s.a and libportmidi.dynlib, libpmjni.dynlib
> and the test programs compiled as well. I tested MIDI output with the
> 'test' program and fluidsynth and everything seemed ok.
> 
> I had installed a few programs and libraries with MacPorts before so I
> already had all the dependencies, in particular "cmake". I think cmake
> used the default C compiler gcc-4.2, but you should be able to specify
> the compiler to use with:
> 
> cmake -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc-4.0 -G "Unix Makefiles"
> 
> (I'm not sure if this is the correct way to do this, but it seems to work.)
> 
> You may also need to set the SDK and the min OS X version (whatever that
> means) to use:
> 
> cmake -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc-4.0 \
>     -DCMAKE_C_FLAGS:STRING=-mmacosx-version-min=10.4 \
>     -DCMAKE_OSX_SYSROOT:PATH=/Developer/SDKs/MacOSX10.4u.sdk \
>     -G "Unix Makefiles"
> 
> Let me know, if these instructions work for you on 10.4 or if you want
> me to send you the static library compiled with gcc-4.0 and the above
> settings, to check if they work on 10.4.
> 
> 
> 
> Chris

Thank you very much. I'll give that a try and let you know how it goes. 
If it fails then I'll certainly be interested in trying a library from 
you if you can provide a static library.

-- Russell
Permalink | Reply | 0 comments |
headers
Russell Owen | 5 Mar 2012 23:13

Re: Mac OS X MIDI support success (MacPorts)


The problem I'm having is that it insists on trying to use Mac OS X 10.5 SDK, which doesn't even exist on my
operating system (I'm trying to build this on Mac OS X 10.4, to assure backward compatibility, and I only
have 10.3.9 and 10.4 SDKs installed). That's clearly not going to work.

I have tried everything I can think of, based on google searches, including:
$ export MACOSX_DEPLOYMENT_TARGET=10.4
$ export CMAKE_OSX_DEPLOYMENT_TARGET=10.4
$ export CMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.4.sdk
and even running the CMake GUI and overriding the path to the SDK before pressing Generate. It ignores
everying and always uses a path to the nonexistent 10.5 SDK.

I don't know if this is a bug in CMake 2.8.6 or if portmidi's config insists on 10.5 or later.

It's presumably practical to build a binary installer for python.org's 64-bit python (Mac OS X 10.6 and
later) that includes portmidi. I'm not sure it's doable for the 32-bit python.org python (MacOS X 10.3.9
and later) -- at least not without giving up 10.4 compatibility.

-- Russell

On Mar 5, 2012, at 11:53 AM, Christopher Arndt (by way of "Russell E. Owen"
<rowen@...>) wrote:

> On 02.03.2012 01:07, Russell E. Owen wrote:
>> My problem is that I just can't figure out how to build portmidi from 
>> source -- at least on Mac OS X 10.4 (which is my usual platform for 
>> building such installers, as it turns out to be more reliably backward 
>> compatible) with gcc 4.0.1 (required for Mac OS X 10.4). The 
>> instructions are here: 
>> <http://sourceforge.net/apps/trac/portmedia/wiki/Installing%20portmidi%20
>> on%20Mac> but they don't work.
> 
> What exactly isn't working? The instructions on the wiki are bogus, yes,
> but I was able to build portmidi from SVN on 10.6 with the following
> sequence of commands:
> 
> svn co
> https://portmedia.svn.sourceforge.net/svnroot/portmedia/portmidi/trunk
> portmidi
> cd portmidi
> cmake -G "Unix Makefiles"
> make
> 
> (Note: there's no '.' (dot) after the make command.)
> 
> This gives me libportmidi_s.a and libportmidi.dynlib, libpmjni.dynlib
> and the test programs compiled as well. I tested MIDI output with the
> 'test' program and fluidsynth and everything seemed ok.
> 
> I had installed a few programs and libraries with MacPorts before so I
> already had all the dependencies, in particular "cmake". I think cmake
> used the default C compiler gcc-4.2, but you should be able to specify
> the compiler to use with:
> 
> cmake -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc-4.0 -G "Unix Makefiles"
> 
> (I'm not sure if this is the correct way to do this, but it seems to 
> work.)
> 
> You may also need to set the SDK and the min OS X version (whatever that
> means) to use:
> 
> cmake -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc-4.0 \
>    -DCMAKE_C_FLAGS:STRING=-mmacosx-version-min=10.4 \
>    -DCMAKE_OSX_SYSROOT:PATH=/Developer/SDKs/MacOSX10.4u.sdk \
>    -G "Unix Makefiles"
> 
> Let me know, if these instructions work for you on 10.4 or if you want
> me to send you the static library compiled with gcc-4.0 and the above
> settings, to check if they work on 10.4.
> 
> 
> 
> Chris
Permalink | Reply | 6 comments |

Gmane