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
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey all,
I just wanted to chime in on the fact that the mactels have "Trusted Computing"
Here is a video of a lecture David Turner (FSF) did at piksel: (150MB) http://www.bek.no/~piksel/piksel05/david_turner_FSF-TC_2005.10.20.mpeg
Seems to be reason enough to boycott the mactels in their current form, buy the PPCs or wait for a non "trusted" mactel.
More links: http://www.gnu.org/philosophy/can-you-trust.html http://www.eff.org/Infrastructure/trusted_computing/20031001_tc.php http://www.boingboing.net/2005/07/31/apple_to_add_trusted.html
.b.
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.
On Mar 20, 2006, at 10:39 AM, B. Bogart wrote:
I just wanted to chime in on the fact that the mactels have "Trusted Computing"
Here is a video of a lecture David Turner (FSF) did at piksel: (150MB) http://www.bek.no/~piksel/piksel05/david_turner_FSF-TC_2005.10.20.mpeg
...haven't seen it, but thanks for the link, I'll grab it later...
Seems to be reason enough to boycott the mactels in their current
form, buy the PPCs or wait for a non "trusted" mactel.
...ahh, the ol' "stick my head in the sand" approach: personally, I
find this naive at best, harmful at worst...at this point, I would be
surprised if any shipping machine based on the intel chipset used
with coreduo processors doesn't have some form of a TCM chip...so, do
we just stop? Maybe...but what happens when you don't use the TPM?
AFAIK, apple's TCM provides a mechanism to keep you from installing
osx on non-apple hardware, but as we've seen from general reports,
this has work-arounds if you wish to pursue them...the other use
would be to allow artists and content providers to attempt to retain
some form of control over their created material: I'd imagine this
is most used in things downloaded thru the iTunes store, but doesn't
have anything to do with any cd/movie that you yourself rip...but
again, this can be broken if you wish to spend the time on it, and so
it effectively only provides an annoyance to the determined...
...so, what does this mean for pd (in an attempt to stay OT, list-
wise): conceivably, OSX quicktime at some point may prevent some
DRM'ed movies from working in GEM, but I haven't heard of anything
near that happening...if this happens, we could switch to the
opensource libraries as are used on the linux version of GEM, or even
move to gstreamer? But this hasn't happened, and never will be an
issue for your self-created media, anyway...
...personally, I'm waiting for the time (soon, I'm sure) when linux
easily installs on the macbook, and the ATI gl drivers work, then I'm
jumping into dual-boot land!
just my 2c, james
On Monday 20 Mar 2006 16:40, james tittle wrote:
...ahh, the ol' "stick my head in the sand" approach: personally, I find this naive at best, harmful at worst.
I don't like to get involved in a pointless offtopic conversation on a mailing list. But I really find your attitude far more naïve and 'stick your head in the sand' than B. Bogart's. I think a lot of people would agree with me.
I'm not going to argue this any further though because it would be a waste of everyone's time & attention.
robert.
If anyone is inclined to move this to the OT list then It may continue, but I also have no more interest to follow it.
I'm doing the opposite of sticking my head in the sand, that is advocating people spend there money in such a way to prove there is a market for non-trusted computing. Smarter and more knowledgeable people than myself have written enough on the topic of trusted computing, pro or con.
Just to say its trusted computing is inevitable does not make it any more acceptable, maybe it makes it less acceptable.
I can't convince anyone either way, but since the mactel is the first trusted machine on the market I know about I thought it would be prudent to send a few links.
</thread>
..b.
Robert Scott wrote:
On Monday 20 Mar 2006 16:40, james tittle wrote:
...ahh, the ol' "stick my head in the sand" approach: personally, I find this naive at best, harmful at worst.
I don't like to get involved in a pointless offtopic conversation on a mailing list. But I really find your attitude far more naïve and 'stick your head in the sand' than B. Bogart's. I think a lot of people would agree with me.
I'm not going to argue this any further though because it would be a waste of everyone's time & attention.
robert.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On Sun, 26 Mar 2006, Cefn Hoile wrote:
and with gcc-3.3 configure terminates with... configure: error: C preprocessor "/lib/cpp" fails sanity check
Are you mixing versions of gcc? that is, I have multiple versions of gcc here, but they also have each their own version of cpp (the macro processor). Do you have that on OSX?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Mar 26, 2006, at 11:21 AM, Mathieu Bouchard wrote:
On Sun, 26 Mar 2006, Cefn Hoile wrote:
and with gcc-3.3 configure terminates with... configure: error: C preprocessor "/lib/cpp" fails sanity check
Are you mixing versions of gcc? that is, I have multiple versions
of gcc here, but they also have each their own version of cpp (the macro processor). Do you have that on OSX?
...osx-intel only supports gcc-4.0+, unless you wanted to recompile
gcc yourself...osx-ppc supports 2.95, 3.0, 3.3, & 4.0...
james
On 26 Mar 2006, at 17:21, Mathieu Bouchard wrote:
On Sun, 26 Mar 2006, Cefn Hoile wrote:
and with gcc-3.3 configure terminates with... configure: error: C preprocessor "/lib/cpp" fails sanity check
Are you mixing versions of gcc? that is, I have multiple versions
of gcc here, but they also have each their own version of cpp (the macro processor). Do you have that on OSX?_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Cefn Hoile wrote:
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.
note: i think you _have_ to use gcc>=4.0 in order to build Gem.
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...
please try to build the CVS-version of Gem instead of 0.90 (which is pretty old)
and for a quick go, you could try disabling mmx and sse2 at configure-time with "--disable-SIMD" (because that is where the compile stops)
mfg.adsr. IOhannes
Thanks, IOhannes
Now building from latest cvs source of the Gem module from
cvs.gem.iem.at:/cvsroot/pd-gem
Have to change both CFLAGS, CPPFLAGS and CXXFLAGS to include the
pd-39_2 source folder, else you get...
configure: WARNING: m_pd.h: accepted by the compiler, rejected by the
preprocessor!
...or...
error: m_pd.h: No such file or directory
So for me it was export CFLAGS=-I/Users/cefn/Documents/curiosity/pdplay/pd-intel/ pd-0.39-2/src/ export CPPFLAGS=-I/Users/cefn/Documents/curiosity/pdplay/pd-intel/ pd-0.39-2/src/ export CXXFLAGS=-I/Users/cefn/Documents/curiosity/pdplay/pd-intel/ pd-0.39-2/src/
But I run into exactly the same error as before, even with the CVS
version.
If I run ./configure --disable-SIMD I get the same
I am now building the latest source from the Gem CVS repository.
Anyone any ideas what options I could throw at GCC version 4 to make
it more forgiving of these errors, or alternatively, what the error
means (I'm not an experienced C coder)...
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
Cefn http://cefn.com/curiosity/
On 27 Mar 2006, at 10:07, IOhannes m zmoelnig wrote:
Cefn Hoile wrote:
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.note: i think you _have_ to use gcc>=4.0 in order to build Gem.
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...please try to build the CVS-version of Gem instead of 0.90 (which is pretty old)
and for a quick go, you could try disabling mmx and sse2 at configure-time with "--disable-SIMD" (because that is where the
compile stops)mfg.adsr. IOhannes
Does Intel's icc compiler run on Mac Intel?
I compiled GEM yesterday on a Pentium4 using icc and it worked fine... that version of icc is analogous to gcc-3.3
./d5
-
B. Bogart -
Cefn Hoile -
day 5 -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
james tittle -
Mathieu Bouchard -
Phil Stone -
Robert Scott