-
FCPX problem!!!
-
I’m with Lance, Bill. I don’t see how versioning and export range are related. Export Range is typically used to send a portion of a project to another program for additional work. This would be a necessary feature if they intend to restore “send to” functionality to Motion.
Personally, I’d like to see it implemented in one of two ways: either a “work area” solution such as After Effects uses, or even better, a multi-layer range select tool.
Andy
https://www.timesavertutorials.com
-
Thank you all for the answers, ive tried every body tactics, the whole lassoing selecting thing into on the timeline and copy/paste, the compound thing, everything and still it had those extra minutes long in it of just black, so i tried another way on my own, and fortunately i actually managed to get rid of the black at the end of my edit, see i like to edit alot off the primary storyline and that was the problem, it was a good thing i split up my edit in the timeline, all of my edit was off the primary storyline, but it was the second half that was causing the problem, so when i selected the second half of my edit and deleted it, the black at the end was gone, so it was the second half of it, so then on the second half i put it back on the primary storyline and that got rid of, maybe this will help put somebody else, but that was my problem
-
[Lance Bachelder] ” I don’t get how versioning replaces the need to export a specific area of the timeline.”
Before, you exported from within a sequence never leaving it.
Now just duplicate that sequence – preserving the current state of your file – and truncate the duplicate which becomes your “export” range just like you had in your old workflow.
Since storylines are nothing but pointers to the original media, it’s nearly as fast and simple as selecting a range in legacy and “exporting” but you’re creating a “version” for export while leaving the original in place.
Two slightly different paths that get you essentially the same function – but I see some benefits in the new process..
In legacy the default was to generate a standalone clip that was instantly disconnected from your work in progress. To preserve your work as it is and generate a new version you had to duplicate your whole timeline and because in Legacy you couldn’t have two timelines “open” at the same time – you were cutoff from all reference other than close and open the old version – which was a hassle.
In X, You duplicate your storyline (a process that consumes nearly no overhead since it’s all virtual pointers) – truncate the result and export that.
Via the Project library you can look at and skim through various versions to review differences very rapidly and visually.
In Legacy, once you exported something and made any changes there was no easily accessible record of what it was before you exported it. You just cut it off cold where it was. And the only way to reference the content was to launch an “autosave” or the exported clip as a separate file.
With the new process, all your versions are available for instant review all the time.
And the original edit stays preserved until you decide a new version is better whereupon you can cut and paste the best parts of the old versions into new ones.
Once again, it’s just different thinking. Not necessarily better or worse. IMO.
It bugged me for a week or so, then when I started to become accustomed to how “duplicate” works – I found it rapidly become just as natural to me as “range export” was in the old system.
YMMV.
“Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions.”-Justice O’Connor
-
[Bill Davis] “Now just duplicate that sequence – preserving the current state of your file – and truncate the duplicate which becomes your “export” range just like you had in your old workflow.”
That’s partially true.
I continue to be troubled by the render files. They don’t follow to the duplicated project unless you choose to duplicate all of the renders as well. This could be huge.
If I’m trying to export 10 seconds of a 20 minute project, I probably will not duplicate the renders, however whatever I export will need to be virtually re-rendered whether in the timeline, or through the export process.
You got me to think however about this versioning idea.
If I had a portion of my timeline I wanted to save in a particular state, it would make more sense to keep it all within my project. Projects keeps their renders.
I’ve been trying to use the process of auditioning compound clips for versioning. I will select a portion of my timeline, compound it, and then select the compound and duplicate to audition. Now I can step inside the compound, make my version changes, then step out. The duplicated compound clip is still pointing to the original renders. I can make 20 auditions of the compound clip and they will all keep the same original renders.
(Note that I could do this for an entire timeline as well. Compound and duplicate the audition. Doing all of my editing inside a compound could cause Inception-like brain pain however, and still feels like a workaround.)
I think for this process to be perfected, I’d like to see some things added.
I’d like to see a way to easily add a compound clip created in the timeline to the event browser. This is for safe keeping, should a compound audition clip accidently be deleted in the timeline, all of your versions won’t disappear.
I’d like to see something similar to FC7’s nesting ability. A collapsed clip in the timeline now lives in the event browser, and when I make changes to the nest in the event browser, all the iterations of the nested clip within other sequences are altered.
I think there should be a way to extend the ends of a compound clip while you are inside the timeline view of it. Right now we can see the limits of the clip, and where the non-visibile parts are greyed out. I’d like to grab the end line and be able to extend it, so when I step out of the clip my adjustments will be visible in the timeline.
This is the big one: As far as exporting, when I’m inside a compound clip, why can’t that export just reference the compound clip or regular clip I’ve got open in timeline view, instead of exporting the entire project? I think this would solve many people’s complaints about exporting just a section.
Now add to that the ability to batch export, either clips or compounds in the event browser, or projects, and we’d be a little closer to the flexibility we all enjoyed in FC7.
But really, what’s the problem with just giving us the ability to export a portion of the timeline? Honestly! What’s with that? How difficult could it be to give us a way to define a “play range”? Something so simple would make so many of us so very happy!
Back to the idea of versioning by compounding the entire timeline… couldn’t FCPX just give us a versioning option for our single project? Instead of duplicating our project, couldn’t we hit a button to save a version, sort of like opening time machine. I’d much rather have one timeline with stored states, than several copies of the projects. When I share a project, it could automatically store that state as a version, then I could always go back and see what I sent out.
And while I’m on the subject… what about giving us our vault back?
———
Don’t live your life in a secondary storyline.Mark Morache
FCPX/FCP7/Xpri/Avid
Evening Magazine,Seattle, WA
https://fcpx.wordpress.com -
[Mark Morache] “Back to the idea of versioning by compounding the entire timeline… couldn’t FCPX just give us a versioning option for our single project? Instead of duplicating our project, couldn’t we hit a button to save a version, sort of like opening time machine. I’d much rather have one timeline with stored states, than several copies of the projects. When I share a project, it could automatically store that state as a version, then I could always go back and see what I sent out.”
Mark,
It’s easy to imagine that the FCP-X team probably *could* do what you suggest. But it’s probably not as high a priority as you or I would like. And I think that’s fair. We’ve both users who’ve spent a lot of time operating the software. Having mastered the basics, we’re looking for the icing and for things that help OUR editing styles. Which is a desire I share with you wholeheartedly. But most editors who might potentially benefit from X haven’t even tried it beyond the level of “experimentation.” yet.
One Apple hallmark in software design is to try to achieve something that is as easy as possible to approach for a newbie, but then reveals complexity and control as you master the basics.
X is a better fit in that (in my opinion) for someone without editing experience than it is for the experienced editor. For us, we’re constantly trying to fit the products features into our professional expectations. And while that’s fair, it’s not necessarily smart here in the early days of software development.
The one thing that NOBODY can argue with is that the X rebuild required so much new thinking and re-orientation – particularly compared to the way the 2 million plus Legacy users had been previously trained in expectation – that here we are six months later and users like you, me and many others who had many years of operating legacy and who have now had more than six months of using X still haven’t fully established all of our own “best practices” for use of the new tool.
It’s a VERY deep tool right now. And while I can see a lot of areas where it can become even deeper – and some form of range-export or range-versioning could well be really popular. I’m not sure I’d want Apple to add even more complexity to the already steep learning curve of X.
in the two previouos “bolt on” revision adding Roles then Multicam – Apple added many new workflows and options to explore.
I very much like the idea of what you’re proposing, but I’m personally content to watch the development curve that Apple has mapped out since the software is currently still working well for me (with occasional hiccups) – and I’m still actively learning all it’s underlying capabilities.
Heck, I’ve spent nearly the entire past month, working with backup and file management strategies trying to find the best ways to plan for old project storage, access, and revision – and on Friday I’m shooting a 9 to 15 DSLR and Go-Pro multi-cam concert project – and dealing with that part of X will probably take me a full month to figure out.
So while I’m certainly looking forward to new features as much as the next guy. I see them largely as future stops along the evolution path thats already chock full of interesting stuff to explore.
If FXP-X is truly Apples pro editing play for the next decade – we’re stilll in the infancy. That’s not an excuse for when things don’t work as we need – just a way to understand that if we’re going to eventually get a tool with as broad appeal in features, stability and relevance as Legacy had become, we’re going to get it over time. Not sprung up magically – fully realized.
Again and again when I get confronted with something that frustrates me – I think back to FCP V1.
I know some don’t give Apple ANY break expecting that as a pro company with deep pockets and lots of resources fielding less than “perfect” software is enough to damn them.
But I just don’t see things that way. If AV Foundation, Core Video and Lion had had as long to mature as MacOS and Quicktime – I’d accept the argument more readily.
But the X team is largely working with brand new technologies on many, many fronts. So I’m giving them a pass on needing time to build out their rooms on the new foundation, particularly if those rooms weren’t fully planned for from the get-go.
Fun to talk about, anyway.
“Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions.”-Justice O’Connor
-
Andy,
I understand. Most people don’t at all share my thinking about where X might be going. And it’s all pure speculation on my part.
I just see things like the Project Library as a tantalizing glimpse at something that could become a mini-playout feature – allowing you to have your “projects’ published to either an internal or external portal (maybe Vimeo, maybe a corporate intranet) and in that instance, you would benefit if your “published works” were persistent and connected to only ONE revision capable owner.
Essentially, I think that in the classic world of “individual desktop computers” each machine and the files on it were an “island” (unless you were working in a true workgroup situation – something only a tiny fraction of the computing user world currently does.) cut off from everything else.
But general purpose computing is moving to a “cloud centric” model where even an individual user would benefit from being able to store their “projects” in a central location, then access the same files from multiple devices (desktops, laptops, iPads, etc) for revision as necessary.
The whole “versions” rather than “save as” model in, for example reflected in Pages or the other newer Apple software seems to support this. The central storage vault is designed to hold multiple versions of the same document and maintain versions in time ala Time Machine.
Put the two together – software that allows “versions” and shared storage that allows a “current version” to be “published” for review and use until revised – kinda needs a way to leave the published version in place while we are allowed to continue to work on new “versions” of the original.
The new Project Library in X looks very much to me to be a construct that supports this kind of more modern “cloud based – version oriented” storage concept.
Again, I could be totally wrong. But I’m trying to learn to think more in “versions” and less in “save as” truncated copies of what I used to do. And exporting a truncated “range export” ala Legacys “export this selection” seems a step backwards if I’m right about the trend toward persistent connectivity.
The less you break your connections, the more choices you maintain.
To use an example (hopefully not an actual metaphor!) We don’t want to allow everyone to draw on the original photo – but just giving them individual copies to draw on is kind of inefficient since those copies are “cut off” from further revision and everyone else. Might allowing them to access a particular “version” or even multiple “versions” while preserving the original document – and making those versions more connected and accessible be a smarter organizing principal?
I haven’t studied this or really even thought about it in depth. It’s just me trying to wrap my brain around why Apple seems to be transitioning to this “versioning” idea rather than just staying with “save as” in the new OSX approach.
We’ll see over time.
“Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions.”-Justice O’Connor
-
Your idea (once you expanded upon it) makes some sense, but it seems such an inelegant solution. Particularly since versions, to me at least, mean the same project, but with changes. In most cases, when I want to export only a portion of my timeline, it’s because I intend to work on that portion in another program: say Motion. That’s why a multi-layer range select or work area would be an elegant solution to that problem.
But I do see your point, and I wonder what the end game of this versioning feature that’s built into the OS.
Andy
https://www.timesavertutorials.com
-
I dunno, but I was doing some set plots in OmniGraffle and stumbled into a big discussion of the whole “versions” instead of “save as” thing on their discussion group.
One link referenced the Apple thinking behind the big change in Lion towards versioning.
Appears it’s also linked to the new “auto-save” functions build deeply into the OS.
Here’s the link for those who are interested…
https://support.apple.com/kb/HT4753?viewlocale=en_US&locale=en_US
“Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions.”-Justice O’Connor
Reply to this Discussion! Login or Sign Up