Hi All,
This is my first post here on this list. So I've been working with pd/gem for half a year now. I am very focused on gem in combination with video/audio. I always had the restriction of my hardware, my computer was not powerful enough. so I tend to get a new one. My intention is to by one new IntelMacs. since I really want to get hold of an computer that can handle this I intened to go for this plattform. So I do have a couple of questions:
do you think that there is a future for pd/gem on this plattform?
How was the overall performance of PD/GEM on a mac in general.
What are your expectations or estimations on this issue?
Since this is really something that is decission making for me, I would be happy for any replies.
Thomas
Leave the house before you find something worth staying in for. (Banksy)
hi
Thomas Kronlachner wrote:
Hi All,
This is my first post here on this list. So I've been working with pd/gem for half a year now. I am very focused on gem in combination with video/audio. I always had the restriction of my hardware, my computer was not powerful enough. so I tend to get a new one. My intention is to by one new IntelMacs. since I really want to get hold of an computer that can handle this I intened to go for this plattform. So I do have a couple of questions:
you have probably noticed that just recently (yesterday!) a similar question popped up....people seem to be very excited about this
- do you think that there is a future for pd/gem on this plattform?
generally i don't think there is such a thing like future, but of course MacIntel will be supported by both pd/Gem hey both pd and Gem where among the first applications that have been known to run on MacIntel (at least that is how i interprete the fact, that both pd and Gem have been successfully tested on last year's apple developer conference, when the MacIntel was first published)
- How was the overall performance of PD/GEM on a mac in general.
on current macs, Gem outperforms other platforms in 2 aspects:
- a lot of pix_sh!t has been optimized for AltiVec (some pix-objects are
MMX optimized (but fewer than for AltiVec), and none has yet been optimized for SSE2); due to the nature of this optimization you will gain nothing from it on MacIntel.
- the video-path (for texturing a lot of changing images, like video or
movies) to the gfx-card has been optimized. i guess you will persist on the MacIntel.
- What are your expectations or estimations on this issue?
personally, i wouldn't go for the very first MacIntels. I expect several problems (none of which i could name) which will surely get fixed within the next months.
mfg.asdr. IOhannes
hi Thomas,
I run PD/Gem on both linux and MAC machines. (no mactel)
Gem seems a lot more efficient for video on OSX, this is probably due to the very nice (proprietary) video decoders and quicktime making it all integrated. (and the developers being very adept at optimizing for the MAC platform).
Still without making lots of efforts audio in PD (with a crappy internal card) seems terrible, the GUI causing dropouts and all kinds of heck, this does not seem to happen under linux. (with a crappy sounds card).
So I guess it depends on what you want to do with it, video or more 3D graphics, still images or video processing...
Personally I do performances on the g4 laptop, which has treated me well, and installations on linux. One day I'll have to give back this g4 and then I guess I'll be doing everything on linux...
Now if someone made linux video decoders perform as well as the OSX ones, and GEM was full of as much SIMD (or SSE, or whatever its called) on linux as the OSX version is I think they would be pretty equal.
.b.
Thomas Kronlachner wrote:
Hi All,
This is my first post here on this list. So I've been working with pd/gem for half a year now. I am very focused on gem in combination with video/audio. I always had the restriction of my hardware, my computer was not powerful enough. so I tend to get a new one. My intention is to by one new IntelMacs. since I really want to get hold of an computer that can handle this I intened to go for this plattform. So I do have a couple of questions:
do you think that there is a future for pd/gem on this plattform?
How was the overall performance of PD/GEM on a mac in general.
What are your expectations or estimations on this issue?
Since this is really something that is decission making for me, I would be happy for any replies.
Thomas
Leave the house before you find something worth staying in for. (Banksy)
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Am 17.01.2006 um 17:36 schrieb B. Bogart:
hi Thomas,
I run PD/Gem on both linux and MAC machines. (no mactel)
Gem seems a lot more efficient for video on OSX, this is probably
due to the very nice (proprietary) video decoders and quicktime making it all integrated. (and the developers being very adept at optimizing for the MAC platform).
maybe the text on the gem website should be altered then: Quote:
GEM was originally written by Mark Danks to do realtime openGL-based
graphics on SGI and Win32 platforms.
Günter Geiger made a port to LINUX.
GEM is now maintained at the IEM by IOhannes m zmölnig. Future
developments will be aimed at Linux and Win32 platforms.
GEM is open source software, it is free for any use and can be
downloaded from the internet. GEM runs on Win32, IRIX and LINUX
platforms. There is also an experimental port to MAC-OSX.
„THERE IS ALSO AN EXPERIMENTAL PORT TO MAC-OSX“
does not quite sound like what you described. actually it scared me
from using Gem quite a bit, until franz of the sat told me that it's
not true.
max
Still without making lots of efforts audio in PD (with a crappy
internal card) seems terrible, the GUI causing dropouts and all kinds of heck, this does not seem to happen under linux. (with a crappy sounds card).So I guess it depends on what you want to do with it, video or more 3D graphics, still images or video processing...
Personally I do performances on the g4 laptop, which has treated me well, and installations on linux. One day I'll have to give back
this g4 and then I guess I'll be doing everything on linux...Now if someone made linux video decoders perform as well as the OSX ones, and GEM was full of as much SIMD (or SSE, or whatever its
called) on linux as the OSX version is I think they would be pretty equal..b.
Thomas Kronlachner wrote:
Hi All,
This is my first post here on this list. So I've been working with pd/gem for half a year now. I am very focused on gem in
combination with video/audio. I always had the restriction of my hardware, my computer was not powerful enough. so I tend to get a new one. My intention
is to by one new IntelMacs. since I really want to get hold of an computer that can handle this I intened to go for this plattform. So I do
have a couple of questions:
do you think that there is a future for pd/gem on this plattform?
How was the overall performance of PD/GEM on a mac in general.
What are your expectations or estimations on this issue?
Since this is really something that is decission making for me, I
would be happy for any replies.Thomas
Leave the house before you find something worth staying in for.
(Banksy)
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
HI
I personally would love to keep on working mainly with Gem and controling video/pictures and stuff like that by audio signals.The main issue why I was asking is because I didn't find too much info about Gem in particular in combination with MacOSX on the internet. I had no clue about the performance on this OS in general. Thanks a lot for giving me so many interesting information.
Thomas ___________________________________________________ Leave the house before you find something worth staying in for.
From: Max Neupert abonnements@revolwear.com To: "B. Bogart" ben@ekran.org CC: Thomas Kronlachner heartofoak456@hotmail.com, pd-list@iem.at Subject: Re: [PD] IntelMacs & PD/GEM Date: Tue, 17 Jan 2006 18:34:44 +0100
Am 17.01.2006 um 17:36 schrieb B. Bogart:
hi Thomas,
I run PD/Gem on both linux and MAC machines. (no mactel)
Gem seems a lot more efficient for video on OSX, this is probably due to the very nice (proprietary) video decoders and quicktime making it all integrated. (and the developers being very adept at optimizing for the MAC platform).
maybe the text on the gem website should be altered then: Quote:
GEM was originally written by Mark Danks to do realtime openGL-based
graphics on SGI and Win32 platforms.Günter Geiger made a port to LINUX.
GEM is now maintained at the IEM by IOhannes m zmölnig. Future
developments will be aimed at Linux and Win32 platforms.GEM is open source software, it is free for any use and can be downloaded from the internet. GEM runs on Win32, IRIX and LINUX platforms. There is also an experimental port to MAC-OSX.
ÂTHERE IS ALSO AN EXPERIMENTAL PORT TO MAC-OSXÂ
does not quite sound like what you described. actually it scared me from using Gem quite a bit, until franz of the sat told me that it's not true.
max
Still without making lots of efforts audio in PD (with a crappy internal card) seems terrible, the GUI causing dropouts and all kinds of heck, this does not seem to happen under linux. (with a crappy sounds card).
So I guess it depends on what you want to do with it, video or more 3D graphics, still images or video processing...
Personally I do performances on the g4 laptop, which has treated me well, and installations on linux. One day I'll have to give back this g4 and then I guess I'll be doing everything on linux...
Now if someone made linux video decoders perform as well as the OSX ones, and GEM was full of as much SIMD (or SSE, or whatever its called) on linux as the OSX version is I think they would be pretty equal.
.b.
Thomas Kronlachner wrote:
Hi All,
This is my first post here on this list. So I've been working with pd/gem for half a year now. I am very focused on gem in combination with video/audio. I always had the restriction of my hardware, my computer was not powerful enough. so I tend to get a new one. My intention is to by one new IntelMacs. since I really want to get hold of an computer that can handle this I intened to go for this plattform. So I do have a couple of questions:
do you think that there is a future for pd/gem on this plattform?
How was the overall performance of PD/GEM on a mac in general.
What are your expectations or estimations on this issue?
Since this is really something that is decission making for me, I would be happy for any replies.
Thomas
Leave the house before you find something worth staying in for. (Banksy)
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
Hi Thomas,
Thomas Kronlachner wrote:
- How was the overall performance of PD/GEM on a mac in general.
As others have noted, GEM performance is generally pretty good on ther current Mac line, espc compaired to PDP which is heavily optimized for Intel processors (perhaps a benefit on the MacTel?). Although I have seen situations using a firewire camera where a GEM patch suddenly eats 2-300% of the CPU it used every other time you ran it, which I suspect has something to do with the drivers used.
But for audio, PD on OSX performs quite poorly in my opinion. Patches which run quite comfortably on the same machine under Linux have staggering dropouts and the GUI responds quite slowly or not at all when doing any serious audio processing on OSX. I have tried all available installers as well as compiling myself (outside of the build system) to remedy the problem but haven't found any solution that really works. Perhaps using the latest Tcl/Tk packages would help, but I haven't been able to trick PD into compiling against those yet ;-)
All in all, I won't be using PD on OSX for any live audio work any time soon when performance is far superior under Linux. Perhaps others have different experiences, however.
d.
On 1/17/06, derek holzer derek@x-i.net wrote:
Although I have seen situations using a firewire camera where a GEM patch suddenly eats 2-300% of the CPU it used every other time you ran it, which I suspect has something to do with the drivers used.
Which firewire camera do you see that with? I have used many (iSight, iBot, ImagingSource, etc) and not had that problem. Can you reliably reproduce it? If so then post a patch to the list and I can look into it.
„THERE IS ALSO AN EXPERIMENTAL PORT TO MAC-OSX"
does not quite sound like what you described. actually it scared me from using Gem quite a bit, until franz of the sat told me that it's not true.
It's about as experimental as the rest of Pd, which does scare off a few folks. I often hear that because there is no company peddling Pd, it is 'unsupported' and 'unstable'. Oh well.
Someone should update that IEM page and remove that line. The link to my page can probably go since it is pretty out of date as well.
cgc
chris clepper wrote:
On 1/17/06, derek holzer derek@x-i.net wrote:
Although I have seen situations using a firewire camera where a GEM patch suddenly eats 2-300% of the CPU it used every other time you ran it, which I suspect has something to do with the drivers used.
Which firewire camera do you see that with? I have used many (iSight, iBot, ImagingSource, etc) and not had that problem. Can you reliably reproduce it? If so then post a patch to the list and I can look into it.
Sony TRV 900 and other camcorder types. Can't reliably reproduce, that's what makes it so special...and frustrating. I've tried to track down the source of this a few times, but without luck. Nothing has been changed from the last time the patch was run, but the CPU use increases. Usually a reboot is the only thing which fixes it. I'll take better notes next time, so long as it isn't happening 10 minutes before a performance.
d.
On 1/17/06, derek holzer derek@x-i.net wrote:
Sony TRV 900 and other camcorder types. Can't reliably reproduce, that's what makes it so special...and frustrating. I've tried to track down the source of this a few times, but without luck. Nothing has been changed from the last time the patch was run, but the CPU use increases. Usually a reboot is the only thing which fixes it. I'll take better notes next time, so long as it isn't happening 10 minutes before a performance.
I've got a Sony DCR-SC100 and DCR-PC101 here and neither one has had such a problem wiht pix_video. I also regularly use the Panasonic GS series without issue. Which version of GEM do you have and what does pix_video output when acquiring the device? Are you setting the dimensions to 720x480/576?
cgc
On Jan 17, 2006, at 2:38 PM, chris clepper wrote:
On 1/17/06, derek holzer derek@x-i.net wrote:
Although I have seen situations using a firewire camera where a GEM patch suddenly
eats 2-300% of the CPU it used every other time you ran it, which I
suspect has something to do with the drivers used.Which firewire camera do you see that with? I have used many (iSight, iBot, ImagingSource, etc) and not had that problem. Can you reliably reproduce it? If so then post a patch to the list and I can look into it.
...yep, the only problem I've seen that isn't solved by unplugging
and replugging the camera is the well known problem with
[pdp_ieee1394], and this is due to copy/paste misuse of the Quicktime
SequenceGrabber API (you can't run SGIdle() in a seperate thread)...
„THERE IS ALSO AN EXPERIMENTAL PORT TO MAC-OSX"
does not quite sound like what you described. actually it scared
me from using Gem quite a bit, until franz of the sat told me that it's
not true.It's about as experimental as the rest of Pd, which does scare off a few folks. I often hear that because there is no company peddling Pd, it is 'unsupported' and 'unstable'. Oh well.
Someone should update that IEM page and remove that line. The link to my page can probably go since it is pretty out of date as well.
...yep, that page hasn't been updated in at least 2 years: going
further than what chris says, I'd add that gem on osx is more stable
than pd's audio system on osx! As usual, this comes from the fact
that the osx developers' interests tend more to using pd as a
graphics rather than an audio instrument...audio is actually on my
new year's to-do list, so we'll see...
...as a sidenote, despite some osx tcl/tk improvements, there's still
lots of room to go: I mean, we are emulating XWindows calls on a
wholly different display system...with that in mind, I'd like to
remind everyone that there's no real reason to use the aqua tcl/tk:
pd works a bit better when using the x11 tcl/tk (certainly looks more
like the linux version)...and the good part is that even doing this,
the GEM & gridflow windows still output to native osx opengl (pdp/3dp
coming soon!)
l8r, james
chris clepper wrote:
On 1/17/06, derek holzer derek@x-i.net wrote:
�THERE IS ALSO AN EXPERIMENTAL PORT TO MAC-OSX"
does not quite sound like what you described. actually it scared me from using Gem quite a bit, until franz of the sat told me that it's not true.
It's about as experimental as the rest of Pd, which does scare off a few folks. I often hear that because there is no company peddling Pd, it is 'unsupported' and 'unstable'. Oh well.
Someone should update that IEM page and remove that line. The link to my page can probably go since it is pretty out of date as well.
sorry for the outdated site. should be fixed somewhat now...
mfga.sdr. IOhannes
Keep in mind, that the Macintels have the TCP (Trusted Computing Platform) chip which is activated and can't be switched off. Again Apple is a first with it (implementing and using the chip in the os) and they lost me as an customer.
Cheers,
Malte
Malte Steiner media art + development -www.block4.com-
Best to take this off list, but I thought the 945 chip series was
incompatible with TPM support, although some of the other hardware
elements would be compatible.
http://arstechnica.com/reviews/hardware/imac-coreduo.ars says
from looking at pictures of the chips, we were able to do some
deduction from the chip numbers. The northbridge chip looks to be an
82945GM, which identifies it as the Mobile Intel 945GM Express
chipset. According to the S-Spec number (SL8Z2), it's a standard
Intel chipset and therefore not an Apple-specific variant. The
southbridge appears to be an ICH7-M, which has support for a Trusted
Computing module.
and http://www.tgdaily.com/2006/01/12/how_different_are_the_new_intel- based_macs/ says
If it is the 945 that's running the Macs, this means that TPM won't
play a role in 32-bit iMac and MacBook Pro architecture, at least for
the next six months or so.
Could you post me a link to the source which contradicts this. It
would be handy to track.
I don't trust Trusted Computing either although I may just be hungry
enough for an Intel Mac to compromise.
Cefn http://cefn.com/curiosity/
On 17 Jan 2006, at 17:38, Malte Steiner wrote:
Keep in mind, that the Macintels have the TCP (Trusted Computing
Platform) chip which is activated and can't be switched off. Again
Apple is a first with it (implementing and using the chip in the
os) and they lost me as an customer.Cheers,
Malte
Malte Steiner media art + development -www.block4.com-
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
hi,
Am Dienstag 17 Januar 2006 19:15 schrieb lists.puredata.info@cefn.com: [...snip...]
I don't trust Trusted Computing either although I may just be hungry enough for an Intel Mac to compromise.
be aware that because there are many people that are "just hungry enough" now will probably also hungry enough for the next step towards a tpm/drm world. after many little, small steps that no one really takes important enough, we will end up in a completely vendor locked computer world.
“Those who desire to give up freedom in order to gain security, will not have, nor do they deserve, either one.” Benjamin Franklin
greets,
chris
On Jan 17, 2006, at 12:38 PM, Malte Steiner wrote:
Keep in mind, that the Macintels have the TCP (Trusted Computing
Platform) chip which is activated and can't be switched off. Again
Apple is a first with it (implementing and using the chip in the
os) and they lost me as an customer.
...indeed this is bad news, but I'm not sure if it's a show stopper,
because I don't really know what it means: How will this be used?
Will it interfere with content that I produce? Or is it just a way
for copyright holders to assert their rights? I can see it perhaps
limiting someone from resampling video or audio that has been
"protected" by this tech, but that's not really part of my creative
drive...
...also, a very similar laptop is available from Acer (travelmate
8204WLMi): http://www.pcmag.com/article2/0,1759,1907007,00.asp
...anyone know if this is also going to have a TCP setup? Anyone
know how well linux is supported on it? When would we see gl drivers
for it?
hmmm, james
-
B. Bogart -
chris clepper -
Christian Klippel -
derek holzer -
IOhannes m zmoelnig -
james tittle -
lists.puredata.info＠cefn.com -
Malte Steiner -
Max Neupert -
Thomas Kronlachner