[PD] PD on Mac-Intel

Cefn Hoile lists.puredata.info at cefn.com
Sun Mar 26 13:24:14 CEST 2006


This is probably not news to anyone, but thought I'd drop a note that  
I have PD up and running on my work Intel Macbook Pro (sorry Ben, I  
said I'd be unable to resist temptation).


Steps were, roughly...

Getting pd 39_2 following the normal routine, but changing the  
PA_BIG_ENDIAN to PA_LITTLE_ENDIAN in the makefile after running a  
regular mac configure, so after the change I get

grep -n 'ENDIAN' pd-0.39-2/src/makefile
13:MORECFLAGS = -DMACOSX -DUNISTD -I/usr/X11R6/include   -I../ 
portaudio/pa_common -I../portaudio/pablio        -I../portmidi/ 
pm_common -I../portmidi/pm_mac    -I../portmidi/porttime  -Wno- 
error      -DUSEAPI_PORTAUDIO -DPA_LITTLE_ENDIAN -DPA19 - 
DPA_USE_COREAUDIO

(don't know how this should be switched - guess there's some way of  
auto-detecting this.)

Building tcltkaqua from latest sourceforge cvs and dragging the  
Wish.app created by this into /Applications.

within Apple X11, cding to the bin directory and running ./pd & then  
gives me a window where I can at least test out the audio

This minimal test of audio works fine. I never got midi to sound in  
this test window even on the powerbook. However, I don't use midi so  
never worried.


Now working on Building GEM so I can test previous pd prototypes I  
have thrown together using video and OpenGL.

Currently getting issues from the GEM build which look like they  
might come from over-strict interpretation of C in gcc4.0. Any  
thoughts welcomed. I'll take off to the GEM-dev list if I can't fix  
this easily.

With gcc 4.0 make inside the Gem directory (version 0.90, with a  
forced include of the pd src through adding -I option to CFLAGS and  
CPPFLAGS env variables) terminates with...

g++ -c -fPIC -I/Users/cefn/Documents/curiosity/pdplay/pd-intel/ 
pd-0.39-2/src/   -I..   pix_coloralpha.cpp -o pix_coloralpha.o
pix_chroma_key.cpp: In member function 'virtual void  
pix_chroma_key::processRGBA_MMX(imageStruct&, imageStruct&)':
pix_chroma_key.cpp:277: error: expected unqualified-id before numeric  
constant
pix_chroma_key.cpp:288: error: cannot convert 'int' to 'int  
__vector__' for argument '2' to 'int __vector__ _mm_cmpeq_pi32(int  
__vector__, int __vector__)'
pix_chroma_key.cpp:289: error: cannot convert 'int' to 'int  
__vector__' for argument '2' to 'int __vector__ _mm_cmpeq_pi32(int  
__vector__, int __vector__)'
pix_chroma_key.cpp:305: error: cannot convert 'int' to 'int  
__vector__' for argument '2' to 'int __vector__ _mm_cmpeq_pi32(int  
__vector__, int __vector__)'
pix_chroma_key.cpp:306: error: cannot convert 'int' to 'int  
__vector__' for argument '2' to 'int __vector__ _mm_cmpeq_pi32(int  
__vector__, int __vector__)'
pix_chroma_key.cpp: In member function 'virtual void  
pix_chroma_key::processYUV_MMX(imageStruct&, imageStruct&)':
pix_chroma_key.cpp:346: error: expected unqualified-id before numeric  
constant
pix_chroma_key.cpp:357: error: cannot convert 'int' to 'int  
__vector__' for argument '2' to 'int __vector__ _mm_cmpeq_pi32(int  
__vector__, int __vector__)'
pix_chroma_key.cpp:358: error: cannot convert 'int' to 'int  
__vector__' for argument '2' to 'int __vector__ _mm_cmpeq_pi32(int  
__vector__, int __vector__)'
pix_chroma_key.cpp:374: error: cannot convert 'int' to 'int  
__vector__' for argument '2' to 'int __vector__ _mm_cmpeq_pi32(int  
__vector__, int __vector__)'
pix_chroma_key.cpp:375: error: cannot convert 'int' to 'int  
__vector__' for argument '2' to 'int __vector__ _mm_cmpeq_pi32(int  
__vector__, int __vector__)'
pix_chroma_key.cpp: In member function 'virtual void  
pix_chroma_key::processGray_MMX(imageStruct&, imageStruct&)':
pix_chroma_key.cpp:415: error: expected unqualified-id before numeric  
constant
pix_chroma_key.cpp:426: error: cannot convert 'int' to 'int  
__vector__' for argument '2' to 'int __vector__ _mm_cmpeq_pi32(int  
__vector__, int __vector__)'
pix_chroma_key.cpp:427: error: cannot convert 'int' to 'int  
__vector__' for argument '2' to 'int __vector__ _mm_cmpeq_pi32(int  
__vector__, int __vector__)'
pix_chroma_key.cpp:443: error: cannot convert 'int' to 'int  
__vector__' for argument '2' to 'int __vector__ _mm_cmpeq_pi32(int  
__vector__, int __vector__)'
pix_chroma_key.cpp:444: error: cannot convert 'int' to 'int  
__vector__' for argument '2' to 'int __vector__ _mm_cmpeq_pi32(int  
__vector__, int __vector__)'
make[1]: *** [pix_chroma_key.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Pixes] Error 2

and with gcc-3.3 configure terminates with...

configure: error: C preprocessor "/lib/cpp" fails sanity check

I'd like to get a native build of the Gem.pd_darwin file for my  
extras directory but might have to let it go for the time being -  
plenty busy.

Cefn
Curiosity Collective
http://cefn.com/curiosity/

On 19 Mar 2006, at 20:25, Hans-Christoph Steiner wrote:

> MacIntel is definitely the way that Macs are going, so Pd needs to  
> go that way as well.  I don't have access to a MacIntel box, so I  
> can't really try my hand at it yet.  I pan on buying a MacBook as  
> my next computer, but that will be in a year or two.
>
> That said, your help would be much appreciated, I'll do what I can  
> to help out.  To start with, I tried to document everything as much  
> as possible, they are here:
>
> http://puredata.org/docs/developer
>
> I don't think that the MacIntel should cause any problems, but all  
> of the Pd code is big and not exactly well organized, so there is a  
> bit of a steep learning curve.  Start with the docs, please, then  
> post to the list, then maybe we can also refine the docs in the  
> process, in addition to the build process.  Each time someone tries  
> their hand at it, we find and fix things that make it tricky.
>
> .hc
>
> Phil Stone wrote:
>> Having just gotten a MacBook Pro for my new job, I'm naturally  
>> interested in getting PD up and running on it.  I've read that it  
>> was actually one of the first applications to run on the (then)  
>> brand-new Intel Macs last summer.  I assume that this was core PD,  
>> and that all extended libraries would have to be recompiled.
>> Has anyone tried this?  I'd be willing to work on it, but I'm a  
>> noob when it comes to building PD.  Hans, your opinion on this  
>> would be most valuable - are you interested in distributing PD- 
>> extended for MacIntel, or is that outside your current goals?  If  
>> not, could you advise me on what I'd need to do compile it?
>> Many thanks,
>> Phil Stone
>> _______________________________________________
>> PD-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
>> listinfo/pd-list
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list





More information about the Pd-list mailing list