Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Final Cut Pro X Released

I wish everyone would just come down and take a breather. As everyone knows, Apple is super secretive about future plans. My friend had just poked around FCPx code and he discovered an XML import and also python scripting. It's in there, it's just not available trough a GUI. So, everyone, please give FCPx a bit more time, at least more that an hour, before you decide to jump the ship. It looks like the infrastructure MAY BE in place for the Pro functionality to be added by the third party developers.
 
It's still a complete re-write, they handled imovie the same way. Re wrote it and built it back up, minus export to tape much to the downfall of many contestants of the V48hours 2010... at the finish line, wondering how to put their shorts on a DV tape.

Oh, 48HFC exporting hell. I've been there... Once burned a DVD in the car(!) on the way and handed it in 2 minutes before the deadline.
 
It's still a complete re-write, they handled imovie the same way. Re wrote it and built it back up, minus export to tape much to the downfall of many contestants of the V48hours 2010... at the finish line, wondering how to put their shorts on a DV tape.

Yes, I know it's rewrite. I can't work out why Apple call it version 10 since it's a completely new piece of software, with little or nothing to do with FCP7.
 
Apple can fix this entire mess with a single communication from their team.

I don't think they needed a release to announce that. You along with any other rational thinking person has worked that out without the need of a official Apple quote. I think Apple know what they are doing. They are not stupid enough to spend millions on developing a new product and deliberately abandon it's pro users... This is a building block. It's by no means all FCX has to offer...It doesn't take me state the obvious does it?

I would love to agree, but the sad history of Shake tells me to be cautious.
 
Here's an interesting thread that will affect some of you here:

As I understand it there are no such things as (old fashioned) projects anymore. Where you had a collection of sequences and bins that were relevant to the specific project. Instead each project has one (1) timeline only, or in other words each timeline is it's own project.

Media is stored in events, and accessed through them or through Smart Collections based on metadata. Delete something from an event and the source file is moved to the trash. And all media and "Events" are shared between all the projects.

Am I understanding things correctly? It sounds a lot like the way say iPhoto or iTunes is organized. Great if you have a collection of things that you wan't to have random access to. But not so great if you have different projects that you want to keep separate. I hope I'm misunderstanding, because I like to be organized and have every job in a separate project. And have all the media relevant to that job in front of me, not everything I ever worked on.

Stephan

Yeah. This is what is really confusing me. As a house with 4 or 5 editors who might all work on a project via XSAN, I can't conceive of any possible way we could use this program.

From what I can tell from playing around this AM:

1) You can't tell it where you want to save a project (always saves in your "movies" folder like imovie.
2) The "move" project command doesn't work (I get a "no value" in the Location pull down menu)
3) I can "see" my xsan volume in the browser of FCPX

Bizarre!

Max

Yeah... we have an Editshare and 14 suites/workstations, regularly sharing projects among multiple editors and assistants.

All of the other "pro" stuff - OMF, I/O cards, etc... - I have faith the 3rd parties and future updates will take of those things, but this Core Foundation/architectural stuff is probably a deal-killer for anyone needing a collaborative workflow.

I just don't see a way to make that happen.

Throw in Apple's discontinuation of Xserve, and now, Color, STPro, FC Server - and I think they are putting all of their chips in the "single user" workflow, which is fine for 95% of FCP users... just not for us!

David Jahns
Joint Editorial
Portland, OR

http://forums.creativecow.net/thread/335/2849#2849
 
We are not talking about 16-bit linear, we are talking about 16-bit RAW. RAW has no colorspace till you bake it in.

Actually, as far as i know, sensor data is in practice linear (correct me if i'm wrong, folks). Every sensor is in essence just a bunch of photon counters (the photosites) - for every additional stop of light, there's twice as many photons, twice as high value.

Edit: and yes, a separate thread would be good ;-)
 
.....My friend had just poked around FCPx code and he discovered an XML import and also python scripting. It's in there, it's just not available trough a GUI. ...... It looks like the infrastructure MAY BE in place for the Pro functionality to be added by the third party developers.

That's more like it! Being able to use FCP in a Python pipeline makes more sense, being able to tie it to Nuke, Shotgun. That would be amazing! Render your vfx shot, approve the comp, it's automatically in the edit.
 
What a good day to be an Avid editor... I'm staying there.
 
Actually, as far as i know, sensor data is in practice linear (correct me if i'm wrong, folks). Every sensor is in essence just a bunch of photon counters (the photosites) - for every additional stop of light, there's twice as many photons, twice as high value.

The question of linear or logarithmic doesn't arise with a single pixel with a single value (16 bits long, in this case). Linear or log comes into play when we are interpolating this RAW collection of pixels into a standard viewable form. Personally, linear and log themselves are confusing nomenclature with only metaphorical relevance to their mathematical definitions. I prefer to call them "stretched curve" (lin) or "compressed curve" (log). You can't have a curve (neither an image) with just a single pixel. So, should we interpolate the RAW data to a log RGB or a linear RGB? So 16-bit RAW can give a 16-bit Linear RGB or a 16-bit Log RGB (Or REDLogFilm). But where does this information come from? From the single R, G, B pixels demosaiced, obviously. That is the advantage of RAW isn't it - you have absolute flexibility. But once you commit to ProRes 4444 everything that is flexible in RAW is baked in.

Finally, there is this thread in Recon - http://reduser.net/forum/showthread.php?57834-So...-how-do-I-do-it - the message is clear. You stay in RAW as long as you can.

Jim said:
They stay in REDCODE RAW as long as possible. Whether you use REDCINE-X or Pablo, stay in REDCODE RAW until the very end. Don't make DPX files 1st and then grade. Limiting the color space, range and white balance right off the bat is not a good thing. Don't do it. This is true if the final output is a DCP package or a film print. For VFX... use Log space and 16 bit EXRs. The very LAST thing you should do for a DCP output is make DPX files.

That is pretty much what I have been trying to say.
 
The more I think about the new FCPx, the more i become convinced, that FCPx is a different animal altogether. I believe, that FCPx is a DEVELOPMENT PLATFORM and not simply an NLE. In the good old days of FCP7, Apple had to deal with every aspect of I/O and formats, as well as working on being able to "send" the timeline to Color, Logic audio etc. We all know, that this approach din't work very well in case of Red support. I think now, Apple decided to concentrate on everything edit, color, composite, sound etc, EXEPT I/O. So, if, for example, Red wants the R3D functionality in FCPx, Red will have to provide it. Same thing, if Resolve wants the roundtrip XML-like functionality, BM will have to provide it. And so forth... If that is indeed the case (obviously, I have no information on that), I think it's super smart. This way, for example, Apple doesn't have to deal with Red SDK anymore. Let Red deal with it. BM can provide as much or as little of the functionality for Resolve. Every manufacturer would be able to include features, they deem needed, without relaying on Apple!!!
 
I never imagined that so many folks in the RED camp would be so terribly resistant to change. :scared:


It'll be interesting to see how this all works out in the end. And, no, I don't think we are quite at that point yet. :001_smile:
 
The more I think about the new FCPx, the more i become convinced, that FCPx is a different animal altogether. I believe, that FCPx is a DEVELOPMENT PLATFORM and not simply an NLE. In the good old days of FCP7, Apple had to deal with every aspect of I/O and formats, as well as working on being able to "send" the timeline to Color, Logic audio etc. We all know, that this approach din't work very well in case of Red support. I think now, Apple decided to concentrate on everything edit, color, composite, sound etc, EXEPT I/O. So, if, for example, Red wants the R3D functionality in FCPx, Red will have to provide it. Same thing, if Resolve wants the roundtrip XML-like functionality, BM will have to provide it. And so forth... If that is indeed the case (obviously, I have no information on that), I think it's super smart. This way, for example, Apple doesn't have to deal with Red SDK anymore. Let Red deal with it. BM can provide as much or as little of the functionality for Resolve. Every manufacturer would be able to include features, they deem needed, without relaying on Apple!!!

I am not willing to buy this theory at this point for the simple fact that they are highlighting the broad native format support. And indeed, they seem to be quite successful, supporting everything from DSLRs to XDCAM EX. The glaring omission is, of course, R3D.

Second, it seems awfully lazy of the software developers. Look at Adobe - they seem to have no problems keeping up to date with the latest in R3D tech. How can you suddenly expect a camera manufacturer to write code for NLE software? Why is Apple dealing with Sony (XDCAM EX support) themselves while RED have to write it themselves? It makes no sense. Blackmagic writes code for DaVinci software, not Apple software.

It sounds much more like "incomplete platform" than "developmental platform". Just using the Occam's Razor. Everything else sounds like an excuse. I have no doubt that XML and EDL will come at some point, but it has to come from Apple. Why a competitor would suddenly fill in the blanks is beyond me.
 
The more I think about the new FCPx, the more i become convinced, that FCPx is a different animal altogether. I believe, that FCPx is a DEVELOPMENT PLATFORM and not simply an NLE. In the good old days of FCP7, Apple had to deal with every aspect of I/O and formats, as well as working on being able to "send" the timeline to Color, Logic audio etc. We all know, that this approach din't work very well in case of Red support. I think now, Apple decided to concentrate on everything edit, color, composite, sound etc, EXEPT I/O. So, if, for example, Red wants the R3D functionality in FCPx, Red will have to provide it. Same thing, if Resolve wants the roundtrip XML-like functionality, BM will have to provide it. And so forth... If that is indeed the case (obviously, I have no information on that), I think it's super smart. This way, for example, Apple doesn't have to deal with Red SDK anymore. Let Red deal with it. BM can provide as much or as little of the functionality for Resolve. Every manufacturer would be able to include features, they deem needed, without relaying on Apple!!!
Not a bad guess Jake. :-)
 
Or Premiere...lol...

All those predicting the demise of FCPx may end up regretting it. I suspect on the day of release of Lion, many apps and drivers will stop functioning as usual. Give it a couple of weeks. Although, I have to say, Lion on my Macbook Pro, so far, runs flawlessly. Except iTunes:-)
 
Back
Top