Franz Bieberkopf
Forum Replies Created
-
[Steve Connor] “… your statement that you hadn’t patched anything in ten years was a strange one.”
Steve,
I think we’re down to semantic arguments then – I suppose you’re correct that when I drag multiple clips into a sequence, there is a patching operation that goes on. This is automatic though, and would not slow me down. Tony West’s original post was that patching used to slow him down.
Franz.
-
[tony west] “However you want to word it, it’s got to get there.”
Tony,
Yes, I suppose if you want to broaden the meaning of patching to include clip arrangement in the timeline, then I do “patch”.
That would mean that compound clips, arranging and managing clip connections and secondary storylines come under the same meaning, wouldn’t it?
Franz.
Edit: on reflection, though, it seems to be me that “patching” is better reserved for the source / record “patch bay” paradigm it came from – ie aligning signal paths.
-
Jeremy,
I’ve discussed before that I work with what might be called “sequence-based” editing (as opposed to what might be called “clip-based” editing). I’ve thought that I might make a longer post on this approach and why I continue to use it.
The short answer is that I start any project by dragging all clips into a sequence (or sequences). From that point on it is very rare that I ever go back to the browser for clips – pretty much everything gets manipulated, deleted, copied, pasted in sequence.
The viewer only gets used for effects (and on rare occasions some matchback or tech problem-solving type functions).
Multiple tracks come from selection and dragging.
(As an aside, this is one reason why the appeal of the organizational tools in the FCPX Event Browser don’t get me too excited – my organization is done in sequence.)
Franz.
-
Jeremy,
Typically I have 6-8 video tracks (usually escalated to maybe 12 or more during prep for lab) and 12-16 audio tracks.
I think I’ve posted more than one example in past – the first is still illustrative.
https://forums.creativecow.net/readpost/335/17728Franz.
-
Tony,
That was all clear and understood by me from your original post.
Franz.
-
[Richard Herd] “How do I turn sequences into media items so they open in the viewer window?”
Richard,
I’m not sure I understand the intent of the question.
Why not just open them as sequences? Why do you need them in the viewer window?
Franz.
-
[Richard Herd] “Of course that’s an empirical issue.”
Richard,
Auditions would not be of use to me.
I’m not really sure how one could do any sort of empirical test. Once I’ve cut the scene in one NLE, I’ve largely “solved” or addressed the creative issues that have been taking so long. To cut the same scene in another NLE, I’d just more or less execute the decisions once again. It’s the creative process that takes time – not the execution. I guess incompetence or poor process would slow things down.
I suppose one could do a comparison of similar approaches using different scenes, but it would require aggregation of several such scenes to be meaningful (as no two scenes are in any way “equal” in the challenges they present).
Franz.
-
[Steve Connor] “… but pretty much everyone who uses FCPX on real world projects say it’s faster, surely that has some weight? Not everyone who uses it was inefficient with using other NLE’s surely?”
Steve,
I think people who try it and stick with it are the ones that like it – “speed” seems to be cited often. I think you probably won’t hear much from those who find it clunkier or slower – they just won’t use it – though there has been some notes (from Oliver Peters in particular) about things that tend to bog him down in FCPX.
That doesn’t answer the real speed question, though.
“Speed” relates to specific tasks, or general approaches. I’ve been working on the same scene assembly for over a week now – it’s been ridiculously slow. And though render speeds are slow, nothing about the NLE I’m using has had a meaningful impact on the speed of the process. This wouldn’t have been any faster in X, PPro, Avid – the issues are creative.
When you hear complaints about double clicking on 1000 clips, doesn’t it raise process questions?
Franz.
-
[Steve Connor] “… if it’s faster for the person using it, regardless of their previous editing practice, then that has to be a good thing doesn’t it?”
Steve,
This is a common refrain here. But I’ve not made claims against people feeling good about what they do. If someone is feeling good about the software their using, that’s a good foundation for work.
For me claims of speed beg the question – what is it faster at doing? If someone claims it’s faster at “editing” then I’m going to wonder about what they really mean.
My point above is that the speed claims may say as much about previous practice as it does about new software.
Franz.
-
[Morten Carlsen] “That is WHY I switched to FCPx when it came about.”
Morten,
It’s been interesting to watch FCPX discussion particularly around efficiency and speed.
The claim often repeated here is that you have to understand FCPX to use it properly – ie. there is an “optimum” approach.
But yours is not the first post that makes me wonder about how others use their NLE of choice (now and in the past). 1000 double clicks? and further down Tony West talking about patching tracks slowing him down. (I don’t think I’ve ever patched a track in 10 years or more of using FCP).
It’s interesting because there are often claims about users “not understanding” FCPX but I read stuff like that I wonder which users “understand” the current the NLE they use. I’ve seen all sorts of bad habits, and poorly thought-out process. It seems to me that’s true regardless of NLE – in other words any NLE requires understanding how to optimize the software to the task.
The 10 x speed claims are pretty funny though – if somebody told me their new software allowed them to edit ten times faster (transcoding, rendering, exporting times aside), I would really wonder about their editing practice.
Franz.