Hi i just got my new macbook 15″.
jit.qt.grab can’t open the i sight
i also tried it with macam and PS3 comera and it open it, but freezes on first frame
before i had 10.9 on an macbook 13″ from 2010, and none of these problems where there.
i think there is a major problem with the new processor...
made some comparisons between old and new macbook (both with 10.9)
running example patch phys.multiple.mesh
macbook 13" 2010 runs at 55 fps
new macbook 15" runs at 26 fps
So I did some more tryings, here what I found out so far:
jit.freenect with 32bits only camera works (means no depth map possible), same with 64bits (it is also very slow) (help file use 106% of CPU!)
jit.openni with 32 bits works (camera, depth, skeleton) but it is very slow (help file use 106% of CPU!)
synapse we do not have yet, we will try asap
isight just opens with 64bits, with 32 does not
ps3eye webcam with 32bits opens but freeze immediately the image, with 64 bits does not read it (probably the madam driver is not supporting the 64)
jit.net.send and jit.net.recv works with localhost but not between two computers (I try new macbook pro with new macbook pro, new macbook pro with old macbook with maverick installed, new macbook pro with old macbook pro with mountain lion)… the result is always an error message in the max window saying “CORRUPT DATA”
Also, the local host from the help file does not work in the one with mountain lion and in the old macbook with maverick installed
no, i tried between 2 totally identical new 15" MacBooks and "corrupt data" message come up.
does anybody have any idea what could be the problem with these new haswell cpu?
and if it is solvable in short time? i know there is just been just an update for the maverick situation, but it's really depressing seeing a new computer running slower than an old 13" inch with no dedicated gpu
with haswell 15" macbook
i just did a quite simple msp patch and this is what i noticed:
in edit mode the situation get laggy
so i checked the cpu dsp monitor and it was at 1% sometimes 2%
then i checked activity monitor and in edito mode it shows 62% of cpu
in locked patch shows 30% of cpu
don't know if this can help
ah sorry i thought cpu architecture and ya it works as you said, i just switch 32 to 64 100 times to check the grab problem and then did’t think that could be a problem for the send but of course…
about the audio patch:
i tried 44.1 512/128 and i get the same results (before i had 44.1 512/64)
this in 32 bits, when i switch to 64 it gets approx 4% faster in both lock and unlock situation
i tried the same patch with same settings on macbook 13" 2010 and the cpu% with locked patch was the same, but in edit mode the old 13” macbook is 8% faster!
the system is clear install... i have nearly nothing on it
strangely i don't remember max asking for downloading java but i can't say it for sure, maybe i just did it without paying attention, anyway i downloaded it and installed it separately.
about the isight grab problem: doesn’t work either on pure data but it does work in Processing and usual apple apps
ah and i did some benchmark test (using Xbench) and:
everything gave expected result besides quartz graphics test
in this test the 13" old macbook was surprisingly faster than the new machine, (new 15" macbook scored 159 and old 13" macbook scored 216)
yes i'm well aware that the cpu drops when patcher is unlock, it's not that what i wanted to point out, what i wanted to do is to compare the new 15" macbook (with dedicated graphic card) with an old 13" macbook 2010 (with NO dedicated graphic card) and just to be sure i checked the cpu both with lock and unlock patcher. The point is that the patch attached above run faster on the old laptop, the old 13" waste 8% less of cpu compared to the new 15"
yesterday (and also 5 min ago just to be sure) i did the same thing with an example patch for gpu testing (phys.multiple.mesh) and also in this case the old 13" was faster (55fps) compared to the new 15" (29fps)
had a friend that tested the pays.multiple.mesh with a first generation 15" retina with 10.8: there it runs 20fps
about the isight: i said it worked with processing but i just found out that since processing 2.0 QuickTime is not used so...
anyway isight and Ps3 (macam) works in qt7, macam does not work in the new qt, device is not seen.
is seems a genera jit.pwindow problem, also with a common qt.movie, the pwindow suck an amazing amount of power specially when more than one. no problem with jit.window
i thought could be a retina screen issue but this does not happen on the first generation retina MBP
my god thanks, was so simple...
i was totally sure it was just a late retina problem, i have a friend with old retina and he don't have this problem and he probably just forgot to have switched on the low resolution option while we were making the comparison.
the last curious behavior that max still has is with the pays.multiple.mesh patch:
the patch runs 22 fps on old retina, 30 on new retina, 52 on old 2010 13" MBP,
Don't know if in this case has sense but i will try a SMC reset as suggested by Karl Kliem in the https://cycling74.com/forums/retina-performance/
thanks everybody for the support
@stefano or your friend was perhaps using an older version of Max which had no retina support and thus always in low resolution mode. This is a very recent feature.
As for the performance differences with the phys.multiple.mesh.maxpat, it looks like there are some OpenGL problems with performance of displaylists on those machines under 10.9.
I was able to speed up that patch significantly to match older machine/OS performance or better with jit.gl.model @cache_mode vbo @displaylist 0. I'm not sure if it is an OpenGL bug which Apple will address at this point, but your problem for that patch is definitely the displaylist issue.
I'm having the same issue using Max 5 on a new 15"Macbook Retina display,
with jit.qt.grab unable to open the in built iSight camera.
After reading these posts I'm still a little unclear on how this problem is resolved?
As low resolution mode is permanently selected (and greyed out) in the finder.
I know this thread is really old, but I wanted to chime in with something I discovered in case others are still running into issues (as I was, yesterday). I upgraded my computer and was having problems using the jit.qt.grab object in Max5--worked just fine in 6 and 7, but nothing but errors in 5. After trying a lot of the suggestions here, I was still coming up short--until I found this command to allow un-checking the application's low resolution box:
Open App’s Info.plist file via TextEdit or any other text editing application. (You can find Info.plist file in “/Applications/ApplicationName.app/Contents/Info.plist”).
Insert this code at the end. (Just before ).
I can't recommend this solution officially because I don't want to be responsible for breaking anyone's stuff, but it worked for me!