FCP X is a joke in your town

[nrausch]

So,
I had to buy FCPX and install on a test system, just to make my own conclusions on the new product.
All excuses aside:

-"It's rebuilt from the ground up"
-"Its only v1.0"
- "64bits are better than 32"
-"It takes time to get used to new things."

I understand all that and appreciate those things.

But...

All of the valuable workflow tools are gone. This is a JOKE.
Make no mistake. This IS iMovie X. I'm sure that there will be an update soon, but to even make this FCP worth looking at again... that 1st update needs to include XML, EDL, OMF support & Log and Capture & Edit to tape & forward compatibility with projects from prior versions of FCP.

While at it, throw in a "classic" mode button that returns the interface to a useable state, not an app built for iPad.

If they're going to make it better, why release it so soon, and like this? Wait until it's an actual improvement to the previous version. Or don't EOL FCP7, and call this new product "iMovie Deluxe for iOS"

It seems mostly useless.

Compressor still seems awesome. Imported all my custom settings from prior version, no issues. I do however wonder how comp farms will work now. Do we have to purchase $49 compressor for all nodes? Curious....

Thanks for listening. Just needed to vent. I mean it is really sad.
1 step forward to 64bits and Grand Central, 500 steps back in terms of ACTUAL functionality.

This reminds me of the "New Coke" debacle in the 80's.

[JSamuel]

+1 to that.
My main issue is that FCS was EOL'd at this point, if it wasn't, I would have happily reserved my 'thoughts'.

[Tim Burton]

The biggest mistake IMHO was calling it Final Cut Pro alongside canning FCP7. If they had given it a new name, to signify a new generation of app it would not have caught so much criticism. Goes to also prove that agile development isn't liked in desktop apps.

The media industry loves legacy, however some things need to move on and eggs are broken making an omlette. To address the points above with my opinion:

XML - Fair enough, it's used by grading systems and the like and was useful for MAM integration. However I'd happy see this fade away for a decent API in return.

EDL - it is 2011 and linear suites are a thing of the past, the faster we can ditch using crap like CMX3600 the better. Anything else using EDLs should have been using XML at least.

OMF - Purely for Pro Tools? Move on, OMF is dead and we should be using AAF as a minimum.

Log & Capture - Can be sorted with a 3rd party app, I welcome a data centric approach to NLEs. However this is more of a nail in the tape coffin, as what more troubling for tape workflows is conform has gone. With no way of exporting the 'decomposed' (parlance borrowed) sequence to reconform, and no way of introducing a 2nd file as a alternative resolution, you are forced to capture (in 3rd party app) and work in a highres + proxy format greatly increasing your storage needs. USP of tape gone, may as well enjoy the fruits of tapeless.

Edit to tape - Ditto 3rd party app, broadcasters are trying to ditch Tape as a exchange format, file based delivery is the way forward. Again look to Avid Interplay and their broadcast integration.

Forward compatibility with projects from prior versions of FCP - Yes and no, they should have give FCPX a new name, breaking the implicit ties with FCP7. Migrating is never going to be smooth which such a seachange. I personally would finish current projects on FCP7 and start new ones on FCPX. XML importer would help here, although you need an app to move UNC referenced media into the events db.

The issues / features I'd like to see fixed in the next release are:

SDI Support - Not for ingest or layoff, but to simply see what your cut will look like on a broadcast monitor. The AJA 2nd monitor over SDI is a kludge, bleugh.

Multicam - This is something many users have come to rely on, especially for OB and live event stuff.

Multi User Backend - Now I like that FCPX essentially has taken the Avid framework of media being stored & sorted for you (although you can still get it to use a UNC file path) and event tied the metadata to the same DB. However I want to see how this would work in a SAN / NAS enviroment, where the ground is moving under NLE as other users work in the group. The SQLite db seems to address everything by UUIDs so it can handle merges, splits and forked instances of the same content. However they need some kinda user control that isnt POSIX to allow structures to be built.

API - Now this is my number 1 request, if they provided a decent API we could use, Core Data apps could be built to get around all the interoperability and it would be handled by 3rd parties. XML? no problem, writing something to parse the project db. Ditto AAF, could even encapsulate the media from the events. Empower the community to sort it's own issues, maybe make some $$$ in the process and sell + deploy via the App Store.

All IMHO anyway, and I've already donned my flame suit.

T

[Tim Burton]

Oh one more thing: why am I against seeing some things like OMF etc come back? Dev time and bloat, let spend what is finite resource move forward to satisfy the use case, not shoe horning in legacy support.

[nrausch]

[Tim Burton]

With regards to the events db looking after thing, you can op out and tell it to leave the files in place when you import. No handcuffs, and the media open in the finder.

Interoperability should be a free market thing, and this is I hope where the FCPX ecosystem will prevail. Create a guideline to work within to maintain quality, then allow the community to create tools.

I dont work in post directly now (used to run a 38 seat FCP facility) however if I did I'd be knocking on the door of Media Composer with something like MXFServer to act as my projects platform. Hmmm might by some shares are a 6-12 month investment, while FCPX catches up.