David Mcgavran
Forum Replies Created
-
Hold tight until we release. I will come back here and on the ppro blog to talk opencl
Cheers
Dave
———————————————————————————————————
David McGavran, Adobe Systems Incorporated
Engineering Manager Adobe Premiere Pro
——————————————————————————————————— -
Yep I am with Adobe 🙂 Tod introduced me below, I decided to add a signature 😉
Can you send private messages on this forum? If so send me a link
Cheers
Dave
———————————————————————————————————
David McGavran, Adobe Systems Incorporated
Engineering Manager Adobe Premiere Pro
——————————————————————————————————— -
Yep if you could post me a small file I can see if it works here and we can start from there.
Cheers
Dave
-
Sample file somewhere?
Thanks
Dave
-
What he was telling you was essentially true. Speedgrade joined the products in September and this released was focued on making it part of the Adobe family. We have a rigid but viable solution to move finished premiere projects into SpeedGrade for grading. That works well. We also have edl in/out in both speedgrade and ppro. In the future we will be spending the time making speedgrade work in the suite. Integration takes time 🙂
Cheers
Dave
-
you can also send me a small sample clip
Cheers
Dave
-
Hi James,
We haven’t had any problems like that. We do know however that in 5.5 we import the footage in the 601 colorspace as canon changed to 709 and didn’t tell us. We fixed that in 6.0. Also for the 59.94 footage Canon’s timecode is writing something strange, this will be fixed in an update to cs6.
Cheers
Dave
-
If that is true something is very wrong… AME has had many many different output options for a long time. Can you post a screen shot?
Cheers
Dave
-
Keep in touch and let us know how CS6 with the AJA drivers works for you. We were aware we needed to address the 3rd party io workflow and we are confident we have.
Cheers
Dave
-
Hi Jim,
Again this are tricky questions to answer. As far as parity between Mac and Windows the main difference in CS6 is that Mac has OpenCL options for AMD users and Windows doesn’t. There are a few older bits that are windows only but we haven’t had requests for that on the mac. As far as code in general about 80% of the code is identical on mac and windows. In the past 6 releases or so we have spent much more effort on the mac. Examples Port Classic to Carbon, CFM to Mach, Carbon to Cocoa, PPC to Intel and now we are starting to look at porting to a brand new tool set that Apple is providing and to sandboxing. If you look at just the Mercury code it is almost identical on Mac and Windows so the question becomes why is windows faster (or is it?)? Again no straight easy answer here. Apple chooses to move its platform ahead faster leaving behind legacy support. This is great for users but makes it difficult for programmers. One of the features of the mac that is great for users is the windowing model. You almost never get flashes or artifacting and it is able to use the GPU for normal drawing operations. This is great and I love it as a user. However, as a programmer it puts us one step farther away from the raw performance of the machine. Also on windows we can work directly with our card manufacturers and they can put performance fixes directly into the driver. On the mac it is a different process to get fixes. With all that said I will promise you that we do everything in our power to use all the power of the machines our customers buy. So for CS6 we decided to focus on adding OpenCL support for mac users as that is the supported GPU tech there. This is our first time doing OpenCL and we are working closely with our partners to make it faster and performant. We will then look to expanding which cards we support. At any rate I look forward to you trying out the mac version of CS6 and continuing to give us feedback.
Cheers
Dave