[Rob Mackintosh]

If there is a market, and they can do something innovative, why leave the money on the table?

Nothing in Greg Joswiak’s recent talk on focus, simplicity, courage(?) and being the best precludes the development of a new workstation.

This excerpt from the FxPlug 2.0 SDK Overview is enlightening:

Users of Final Cut Pro X are looking to solve specific tasks rather than to apply particular effects. In general, you should avoid publishing long lists of parameters that are likely to confuse users and make completing their tasks harder rather than easier.
Advanced users who need more control will be able to either open your Final Cut Effect in Motion and edit it themselves, or create their own Final Cut Effects within Motion for their specific task. Remember, less advanced users will be overwhelmed by filters that are too complex and won’t generally need to control every parameter in a given filter.

Same goes for hardware. The current iMacs can be a workstation or home PC or a kiosk.
Motion is to FCPX what Thunderbolt accessories are to the iMac.

I’m sure there are advanced users pushing the iPad and iPhone to their limits.
They’ll take the high and low end user if they can get them, and with the minimum number of products.

I expect a “reinvention of the workstation” sometime in the next couple of years.
Just don’t be surprised if it’s branded Mac Mini Pro.

[Rob Mackintosh]

A container that functioned like a group in Motion – a collapsible stack – would be useful.

From memory this has been raised a few times on this forum.

[Rob Mackintosh]

Not much.

Will explore them more.

I’m coming around to your POV.

[Rob Mackintosh]

Wouldn’t this be easier with compound clips.

I’m a relative beginner compared to you fellows and don’t do this sort of thing, but if I had 40 variations of a title I’d work like this:

Complete first title, option drag up and make changes. Repeat, collapsing completed layers into compounds as I went. Once finished, break open all the smaller compounds and collapse into one compound clip. Open the compound and solo the version needed for each export.

If I needed to work on a particular version in context i.e in the main timeline, I would first compound everything above and below it, break open the main compound, mute the other compound layers and go to work.

Granted the performance might not be there at the moment.

[Rob Mackintosh]

Yes, a couple of weeks ago.

[Rob Mackintosh]

Thanks for all the free effects. Brilliant, as they say on The Fast Show.

As Andrew Richards explains there may be issues relating to the autosave and concurrent queries to the database. Some optimizing and faster hardware might solve that.

But that doesn’t explain the weird project bloating, and the resultant sluggishness, that occurs with markers, compound clips and when blading a clip.

As I understand it the undo queue is flushed when you quit. Perhaps the information is retained but not accessible and this contributes to the bloat? I know references to markers persist even when they’re deleted. I deleted over 10,000 of them and my project shrank from over 1GB to around 100MB.

Essentially all media in FCPX can be treated as a sequence.
What are the ramifications of this?

[Rob Mackintosh]

Agreed.

And it puts a dampener on one of the potential strengths of FCPX – versioning in the timeline.

[Rob Mackintosh]

Another experiment:

Loaded 57 minute aiff into new project.
Placed on primary storyline, put into compound clip, opened compound clip.
Project about 150KB in size.

Added 10 markers at 5 minute intervals.- showing 10 markers.

Cut aiff file into 152 clips. Exported XML showing 1520 markers.

Deleted markers. Exported XML showing 1520 markers. Project size about 6MB.

On primary storyline cut compound clip into 10. Exported XML showing 15100 markers.
Project file around 60MB. XML file 1.9MB

Cut compound into 30 separate clips. Exported XML showing 45300 markers. Project file now 175 MB. Takes a minute to load.

There are no markers in the project. The audio exported from the project hasn’t changed. The project file is over a thousand times its original size.

[Rob Mackintosh]

I have had a similar experience with a 50 minute SD project. Broken into 4 separate projects to manage. See below for where 300 markers in the wrong place can get you:

Long post here: https://forums.creativecow.net/readpost/344/5732 if you want the details.

There’s a lot of clever thinking gone into FCPX. I think the much maligned Randy has looked at everything from iMovie to SGO Mistika and arrived at a product design that, once you wrap your head around it, can really speed up workflows.

The execution is atrocious. How is my iTunes database file (.itl), that references 20 000 + items and 150GB of data, kept to only 6MB when my humble fcpx project referencing a few hundred items and about 8GB can balloon to 1.2GB?
(Incidentally the iTunes XML is 4x the size of the .itl database)

[Rob Mackintosh]

Thanks for doing more tests T.

Whatever the technical implementation, which at the moment is poor, conceptually FCPX works differently to what you would expect:

– Every project points to the source media, not just “clips” in an Event. Perhaps this is necessary to communicate with other software. It suggests it would be trivial to implement a reconnect media function.

– All the metadata applied to a clip within an Event appears to be duplicated in the Project.

– You can reconstruct an Event, keywords and all, with just the project file (limited to the media contained within the project).

Why not leave the metadata (and source file info) in the Event and only hook into it when exporting a project or XML?