Andrew Richards
Forum Replies Created
-
[Chris Harlan] “Isn’t an EDL an even simpilar timeline?”
Yeah, but EDL isn’t a singular format. There is variation in how they can be formatted, so supporting import is made difficult by the unpredictable formatting. If it were easy, someone would have put out an EDL to FCPXML translator by now. Either it is harder than it looks, or has too limited a market, or both.
Best,
Andy -
[Jeremy Garchow] “Just from a tea leaf perspective, the XServe is kind of what you and Craig are proposing. “Just add” thunderbolt, and a few higher speed PCIe ports, and away you go. As I said, I’d like to be wrong.”
Not really. The Xserve was 1U with hot swap HDDs and PSUs, forcing them to get very sophisticated inside and forcing it to be more than 30″ deep. I want a 3/4 thick Mac Pro (I guess that is more like 3U) with detachable handles. That’s a considerably smaller leap. I don’t even care if they don’t sell their own rack rails.
Best,
Andy -
[Walter Soyka] “FCPX’s new parent/child data model is exposed in FCPXML. Since FCPX can import iMovie projects, but not traditional FCP projects or EDLs, I assume that iMovie also uses this parent/child paradigm.”
I don’t. I assume it can import iMovie and not legacy FCP is because iMovie uses such a flat and simple timeline. Easy to translate. Final Cut Express could import it too. The vast array of structures they’d have to translate to deal with tracks, nested sequences, etc, make importing legacy FCP projects a very different story.
[Walter Soyka] “Of course I’d agree that FCPX builds on what’s available in iMovie, but they seem to share a common foundation, and I wouldn’t assume they were designed and implemented independently.”
Even if FCPX is iMovie evolved, calling the completely new APIs and implementing a vastly more complex data structure must be all new code. Even if you are right, that isn’t much of a shortcut to FCPX. Think invertebrates to mammals, not chimps to humans.
I would be much more willing to entertain the idea that FCPX is going to donate a lot of code to some future 64-bit iMovie than the idea that current iMovie donated very much at all in the way of code to FCPX.
Best,
Andy -
[Aindreas Gallagher] “Is that the only bit? What about the my little pony yellow selection boxes, the skimmable clip lozenges, the very actual identical buttons for going into iPhoto and iTunes, because that’s where we keep royalty free music and the Getty images.. Amirite??”
Sharing UI art is not in away indicative of shared code underneath. If you are arguing the UI brushstrokes came from the same hand, I don’t disagree. If you think that means all of what’s happening underneath is the same, you are simply wrong.
[Aindreas Gallagher] “Then there’s the crop tool, the ken burns effect.. Everything up there, the actual operation of audio handling and visualisation of audio and peaking – All these things aren’t like iMovie – they are identical to iMovie “
UI look and feel, even what the buttons do, is not the same as how it is being done. The APIs that FCPX is necessarily using to be 64-bit require new code under that similar UI skin.
[Aindreas Gallagher] “This thing is made out of iMovie spare parts with a bunch of buggy new stuff soldered on.”
That metaphor doesn’t even work. Software development is not Scrapheap Challenge.
[Aindreas Gallagher] “Its essential goal is to appeal to, and monetise, the consumer video enthusiast base.”
Is it? I agree Apple has a consistent iApp/App Pro marketing tiering, but if all they wanted to do was take more money from iMovie users, they’d be better off selling them theme packs. Much higher margins there.
Best,
Andy -
[Jeremy Garchow] “I’d like to see a rack mount capable product, but they killed the one they had.”
They didn’t kill it because it was rack-able, they killed it because it didn’t sell enough units to justify continuing. If Jony Ive can stomach making an iMac hang on a wall, he should be able to tolerate a Mac Pro neatly suspended in a rack.
Best,
Andy -
[Aindreas Gallagher] “I don’t think pulling 32 bit iMovie code into 64 bit FCPX code is a corporate moon shot.”
It isn’t a moon shot, but the amount of code the two share is likely very little. So it isn’t a thin veneer either.
[Aindreas Gallagher] “Seriously – try the timeline audio-peaking. its literally identical. the idea that apple had to go to software jupiter and back to produce a paid for kludge of iMovie is hard to believe – doesn’t this at all feel like an unstable, monetised expansion of iMovie? Isn’t that what this is?”
That bit of UI is one of the few things they could reasonably share in terms of code. The UI bindings and behaviors of any app are a pretty small fraction of their sum development. The data structures and underpinnings are a much bigger job, and those are likely new and unique in FCPX given what we know about the APIs being used and the difference in structural complexity between an iMovie timeline and an FCPX timeline.
Best,
Andy -
[Walter Soyka] “Why rewrite the code that deals with the timeline interface or data model if you don’t have to? “
The data model is significantly different, iMovie vs FCPX. Conceptually, FCPX has several significantly more complex structures like clips connections, compound clips, subframe editing, secondary story lines, and auditions. iMovie is just a single string of video blobs with transitions and limited graphics. Structurally, FCPX uses CoreData to write to a different project container than the binary iMovie uses. So you have totally different media handling APIs that have to interact with a totally different data handling API. That means new code.
There is clearly a familial resemblance and a certain amount of commonality in terms of the high-level concepts (Events vs Projects, trackless timeline) and UI layout, but the inner workings have so little in common they may indeed have had to rewrite everything just to be 64-bit on all the new APIs.
[Walter Soyka] “…it would certainly be possible (and economical) to share some of the higher-level UI and timeline data mdoel code even though the lower-level media- and resource-handling code is completely separate.”
The iMovie UI and timeline data model are much, much less complex than FCPX’s. Sure, it is possible they were a starting point (definitely a raw conceptual starting point), but there are so many complex structures unique to FCPX along with the requisite different underpinnings for 64-bit that the code probably shares very little in common, if anything.
If there is one place there might be some commonality in the code it would be at the UI level, but linking UI elements to the underlying guts of an app isn’t the bulk of the development work. Far more of it is the lower-level data/media/resource-handling.
I’m just disputing the idea that FCPX was a trivial project that was just a riff on iMovie. That just doesn’t wash for me. To my mind the trivial thing would be the amount of code the two might share, not the development effort necessary to produce FCPX.
Best,
Andy -
Oh I use them too, but I wish they required less than a hacksaw to remove and weren’t so harsh on the hands. On my fantasy box they are held on the top and bottom with a few beefy screws that would also support optional rails. Having them molded in shouldn’t be a design necessity. It is only seamless on one side anyway since the access babel breaks up the other side.
Best,
Andy -
With Apple’s design talent, you’d think they could design a handle that was a little more ergonomic and a little less enhanced interrogation…
That’s why I put quotes around “handles”, they barely qualify.
Best,
Andy -
[Jeremy Garchow] “A rack mount blob isn’t the Apple way. Those handles help keep the MacPro cool and quiet due to airflow. A square cage won’t be as effective unless you put really noisy fans in there.”
The perforated metal lets the air flow, but the handles are just…there. They aren’t heat sinks. It couldn’t be a solid aluminum shell like a mini, but they could put the current case on a bit of a diet without losing any key functionality. Who actually uses two optical drives? And the two 4x slots are bandwidth-equivalent to Thunderbolt, so that’s even more interior space that can be ditched. The Xeons with their generous heat sinks, and the PSU , and space for full length PCIe cards still need the same amount of room. If they turn the wide bits 90 degrees and trim the fat, 19″x19″x3.5″ should yield enough interior volume for my wish list.
Best,
Andy