-
Todays FCP X announcement
-
[Craig Seeman] “Three point editing works for me and I suspect most people or you’d see wide complaints about given its fundamental use.”
It is broken by design. When they realized that they duct-taped Shift-D onto the the thing.
[Craig Seeman] “Replace at playhead is not broken. It hasn’t been implemented. Replace is currently is Start or End or “Replace.”
“Three useless things where one useful was is broken.
-
[Craig Seeman] “The number of people and organizations who used spreadsheets instead of databases because they had no idea how to use a database was pervasive IMHO.”
Certainly. I’ve seen this many times as well. That doesn’t change the fact that even though they have some functional overlap, they’re really different tools for different jobs.
[Craig Seeman] “Being able to use Roles to line up content in rows (tracks) as needed would be good. I don’t want my NLE to limited by that mode, as most are. “
Fair enough. I’m curious – do you do a lot of work in nodal compositors? If so I can imagine why you you’d find this liberating. For me, tracks are a foundation. They provide inherent structure and organization, both temporally and visually. I’ve never felt limited by them. Just the opposite, in fact.
[Craig Seeman] “One thing that FCPX hasn’t broached, and may not for some time, is that a powerful database not only allows for complex relationships but allows for flexible display. FCPX has a ways to go in that area but my own guess is that Apple is going to move the database further along for a bit before it can really get into more flexible interface control.”
This is something Walter Murch alludes to in that interview from a couple months ago. The idea being that if you have a robust database backend, you can build whatever UI you want on top of it to visualize the data. Great idea and hope it’s possible.
My hunch though is that the timeline UI itself is designed around a data model that is considerably less flexible than people think. My gut is the UI design decisions are deeply baked in. I’d love to be wrong about this though! The possibility of a malleable database backend that could be poured into any type of frontend UI is what keeps me paying attention to FCPX’s progress.
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl -
[Aindreas Gallagher] “…in straightforward terms the transformative importance of the database…”
Hi
My most straightforward ‘need’ is for different captures (tape) or transfers (card) of the same material – A/V + timecode + Reel Name – to be seen by the NLE as linkable with no issues, regardless of clip in/outs etc. So for example if a whole tape had been captured overall, then fragmentary clip sections subsequently recaptured would work in the edited project without any relink fiddling and fooling around.A label based spreadsheet like FCP Legacy couldn’t do this as it can’t see beyond the original capture/ingest labeling of the video. All that Shift-F matchback malarky if you’ve brought clips into the browser from another project.
A proper database would see clips from identical assets as being the same thing even if brought to the project by different ingest methods.
That’s where my puck has been – awaiting an NLE to catch up with it… 😉
-
[Paul Dickin] ”
A proper database would see clips from identical assets as being the same thing even if brought to the project by different ingest methods.
“again being stupid – how does that arise in a work scenario? what are you describing in a work scenario with this re-linking going beyond the spreadsheet?
[Paul Dickin] “So for example if a whole tape had been captured overall, then fragmentary clip sections subsequently recaptured would work in the edited project without any relink fiddling and fooling around.
“nnnnn. do you mean you are capturing smaller segments of the same material? I’m not getting my head around this bit? whats the work scenario?
http://www.ogallchoir.net
promo producer/editor.grading/motion graphics -
[Craig Seeman] “Being able to use Roles to line up content in rows (tracks) as needed would be good. I don’t want my NLE to limited by that mode, as most are. “
[David Lawrence] “Fair enough. I’m curious – do you do a lot of work in nodal compositors? If so I can imagine why you you’d find this liberating.”
I see where you’re going here with nodes versus tracks, but I’ve made the argument before that nodal compositing is a great example of how allowing the operator to use spatial arrangement is important. Imagine if the node graph continuously automatically reflowed as you worked — you’d get lost.
People are naturally very good at spatial thinking, but FCPX doesn’t take advantage of this.
Metadata is one thing, but a self-collapsing timeline is another. Craig makes a great point — and I think Jeremy has suggested this, too — it’d be great if FCPX could actually use metadata to drive the view of the timeline instead of always showing the native parent/child view.
Position and alignment conveys information to humans very quickly. Here’s a quick non-editorial example. In my article on FCPX from a few months ago, I included this timeline:
Here’s another look at the same timeline, ruthlessly collapsed:
They convey the same information, but one is meaningful to humans at a glance, and the other requires a lot more work — or additional tools or workarounds — for humans to process.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
Simon, Brad may be referring to a proposed app due at the end of Feb –
https://forums.creativecow.net/thread/335/25455
But still vaporware
-
mind you david –
as somebody who knows coding like they know CERN, I still feel full blown multiclip architecture turned up quite head turningly fast in the fashion they have just produced it.
although: the timeline is as ever glommed with chrome when moving clip objects tho. I will never stop stamping my walking stick on that point. that timeline has immense problems moving the physical clip objects.
to me, they feel immensely heavy objects on current hardware – its a ridiculously gloopy timeline. I would recommend anyone to throw a clip around freely on 7 and X – really let your mouse go – the difference is jaw dropping given that physical clip movement represents intrinsic editing thought process.
http://www.ogallchoir.net
promo producer/editor.grading/motion graphics -
[Aindreas Gallagher] “as somebody who knows coding like they know CERN, I still feel full blown multiclip architecture turned up quite head turningly fast in the fashion they have just produced it.”
I hope no one here really believes this release was in any way, shape or form a response to customer complaints and concerns. It seems quite clear to me that we’ve now pretty much reached the version of FCP X that ProApps had always intended to launch. It’s just that they were probably a year premature, so a lot either wasn’t ready or didn’t work or was dependent on something now yet in the OS. So items had to be stripped out and are now being added back in. I think this version pretty clearly shows an unequivocal direction, which means not many of the “lovable FCP 7 features” are going to make their way back in.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
Those timelines are interesting, Walter. I’ve got to go back and read that.
-
[Walter Soyka] “I see where you’re going here with nodes versus tracks, but I’ve made the argument before that nodal compositing is a great example of how allowing the operator to use spatial arrangement is important.”
We’re in complete agreement here. Spatial position is essential in mapping a nodal pipeline. The last thing you’d want is for it to constantly reflow. Where I was coming from is that in nodal compositing, the focus is generally on individual shots, not the timeline or time per se. The spatial position and connections between nodes have nothing to do with that node’s relationship to time. It’s all about the composite.
[Walter Soyka] “Imagine if the node graph continuously automatically reflowed as you worked — you’d get lost.
People are naturally very good at spatial thinking, but FCPX doesn’t take advantage of this.”
Agreed. I think this is one of the reasons I dislike the magnetic timeline. By default it reflows both horizontally and vertically in time. For my work style and project needs, more often than not, this gets in the way.
[Walter Soyka] “Metadata is one thing, but a self-collapsing timeline is another. Craig makes a great point — and I think Jeremy has suggested this, too — it’d be great if FCPX could actually use metadata to drive the view of the timeline instead of always showing the native parent/child view.”
Yes! This would be great. I think the forced parent/child UI is the core problem with the current FCPX timeline for editor’s like myself. It’s an artificial constraint when you’re used to working in an open, non-hierarchical timeline.
I hope we eventually see something like this but I’m not holding my breath 😉
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl
Reply to this Discussion! Login or Sign Up