I"m wondering a bit about your storage? Could it be that one of the systems is playing of the main drive? Also, what codec are you using? Could you have rendered out an animation codec by mistake on the clip your testing?
Standard stuff to try would be
- Make sure you have the latest CUDA driver from NVIDIA for 10.6.6 http://www.nvidia.com/object/mac-driver-archive.html
- Clean your media cache (preferences/media)
- trash your prefs - http://blogs.adobe.com/genesisproject/2009/11/having_weird_behavior_with_an.html
Hope this helps,
Thanks for your input, just to let you know I have tried everything you mentioned before posting. I have an internal raid 0 array setup that gives well over 300mbs read/write. I have many tb's of space and more than enough ram and certainly don't run anything but software off my main drive
It is nothing to do with codecs or file types as this sluggish behaviour occurs even with a bars & tone clip generated from within.
I have contacted adobe and they are looking into it also. They tried on their systems and I think they have found the same issue. The remarkable thing as I mentioned in my original post was...
When I grab a clip on the timeline it turns to a ghosted clip (looks exactly as a normal clip but ghosted but still shows clip name etc in the ghosted instance when moving around).
Our other suite has exactly the same software and almost identical hardware and when clips are grabbed on this machine with a large timeline the clips actually turn to a grey only ghost (with no clip details etc) and moving around is very fast and responsive
Adobe said that when they move clips around it displays ghosted instances in the same way my system does.
So I am still a little perplexed with this issue.
In response to Pharther my cpu usage ranges from 90 to 100 % when moving basic clips around.
Cheers & Thanks
Also I posted this:
OS X 10.6.6
To clarify ... is seems to happen with all center and corner set points related to any video effects that are adjusted via keyframes. ( Motion )
The numbered index that can be controlled by a click-hold mouse command seems to work fine .. and doesn't product the same effect.
I have restarted, reloaded, re-edited .. and cleared the media cache.
The Activity Monitor lists 150% CPU use while this occurs.
PP is also unresponsive everywhere while the adjustment plays 'catch-up'.
Please inform me where to turn off the GPU.
I find no such option in Premiere.
I have the latest Nvidia driver.
The sluggish performance is not a Graphic Card issue .. as far as I can tell.
Very simple to reproduce every time:
1.) Add a video clip to a sequence.
2.) Choose effect "Motion".
3.) Highlight Motion effect to appear Center Set point.
4.) Mouse Click Hold Drag Center point back and forth. Watch it gag.
5.) Try Mouse Click Hold Drag on Position Index Numbers. No Problem.
The extremely long sluggish time due to frame set point movements are not effected if I toggle the Mercury Hardware // Software Playback either way .. and shouldn't have anything to do with the graphics card anyway, since it is fine when using the numbered set points index and the click/hold/drag.
Could you confirm this and send it up to the bug dept. It is definitely worthwhile to fix.
Also: It would be nice that ....
Adjusting the 'motion' frames should respond to the arrow keys ( or / as the numbered values should change ) ... such as in Photoshop.
This seems to be a inconsistency in common workflow between Adobe products.
Maybe if the was a way to customize the keyboard for this ....
The CS5 is a great suite .. I wish I was part of the design team to update certain features I am visualizing from being a 20 + year veteran of Adobe apps..
Thanks for your help.
Dennis here is a link to a video I made with the comparison between systems.
Just to re-iterate we have been operating with FCP and decided with my testing late last year to head down the premiere path, so... At the start of the year we rebuilt our systems from scratch.
We put on board all OS software and updated. We then cloned our systems so we had a clean backup with no other software on board.
We then put all other required components plus CS5 and updated and then cloned our systems at this point.
Problem exists at this point.
Hope video helps, I will provide the link via the support portal aswell.
Again the sluggishness is actually too-fast ... the mouse coordinates collected from holding the click down and dragging overrun the mouse buffer to the point where it freezes the movement trying to catch up.
The only solution is Adobe Tech. They need to address this in update and only in certain instances it is a problem. My guess is that they never will since their is probably no room for new code placement in the app.
I have solved my problem with a mouse. Not sure why that didn't fix yours ...
Just to let you know, we have 2 systems and have finally
found that it is something to do with monitor resolution and not with mouse.
The system I demonstrated in my video which worked fine suddenly had the slow instance movement
so after some testing we found that it only worked "as it should" when the timeline was
made full screen (with the " ~ " key) . When we reduce its size in the monitor gradually,
you can actually get to a point where movement becomes sluggish again.
My systems maximum monitor resolution is 1920 x 1080 and I can't reproduce this functionality / non functionality.
The other systems monitors resolution can go higher.
So in summary there seems to be a definate relashionship between monitor resolution and this annoying sluggish movement.
It would be great if someone else could confirm this with us.
Thanks Butch2oc, good find!
I can confirm this result. Instances on my 30" cinema display lag in the time line with a wired mouse, wacom intous4, and a logitech mx revolution. When the timeline is minimized to roughly 1/4 of the screen real estate, the problem goes away and does not exist with all three input devices. I use dual monitors, and was able to replicated the problem on my secondary display which has a display of 1920x1080, the lag reoccurs if the timeline window takes up more than 1/2 of the screen resolution. Please submit bug reports if anyone else can replicate this as well.