|
|
All the news now and in your digital future
Uh Oh! Not Good...
Posted by Dan Brockett
|
Re: Uh Oh! Not Good... February 18, 2010 09:22AM |
OK...so Casablanca was a joke. 
When life gives you dilemmas...make dilemmanade.
When life gives you dilemmas...make dilemmanade.
|
Re: Uh Oh! Not Good... February 18, 2010 09:43AM |
Okay, a couple slightly less sarcastic replies.
That's true. But remember that at its core, Mac OS X is thirty-year-old code. I don't mean some of the underlying design principles and stuff; I mean that a big chunk of Mac OS X consists of source code that was physically typed by somebody in the late 70s, early 80s, and has not been changed since. The fact that some or a lot of the underlying source code is a decade old does not mean that source code has gone off and needs to be thrown out before we all catch salmonella.
For another data point, Media Composer was developed in the late 80s and hasn't been ground-up rewritten since. And though it debuted on the Mac, it wasn't even originally a Mac application! It was originally written to run on workstations built by a company nobody even remembers any more. Along the way, Media Composer has been modified to run on the Power PC, on Intel computers under the Windows OS and on Mac OS X. By all rights, it should be a wonky, unstable piece of junk ? but from what I've heard, the universal opinion is that version 4 is the best version yet.
There's an old saying about babies and bathwater here, but I can't remember how it goes.
Let's break these down individually.
"Make it 64-bit" is a damn tricky thing. Back in the 90s, I worked primarily on SGI systems, workstations and mini-supercomputers. Those were among the first widely available 64-bit systems, and SGI did something very clever with them. Knowing there was a huge (in relative terms) installed base of software that'd been compiled against the 32-bit MIPS ABI, SGI made sure their 64-bit systems would run all that older 32-bit code without modification. (This was an approach Intel famously failed to take with their Itanium line of high-end chips, and they failed commercially as a consequence.) But in doing so, they discovered something that's only obvious in retrospect: All other things being equal, a 64-bit version of an application will run slower than its corresponding 32-bit version.
It's easy to see why. A 64-bit application can address tons more memory, because it uses 64-bit-long memory pointers ? essentially just logical addresses to places in memory ? rather than 32-bit pointers. But a lot of what computers do is store and recall pointers, so pointers end up in processor cache all the time. Like literally all the time; a typical user-facing application does way more with pointers and handles (pointers-to-pointers) than it does with user data.
And 64-bit pointers are (surprise) twice as big as 32-bit pointers. Which means you can only fit half as many of them in the various high-speed caches in your computer. Which means you have more cache misses, and cache misses are really expensive in terms of computer performance. Even though it's measured in microseconds takes a lot longer to fetch a number from main memory than from cache, and when you're doing that a billion times a second, it adds up.
So for about a decade, the conventional wisdom was that 64-bit computing was sometimes necessary ? when you needed to manipulate large data sets in memory ? but never desirable.
Intel (and others, but we're all using Intel microchips right now) did some clever things to try to combat that. It took them years of trial and error, but it's to the point now where 64-bit Intel microchips like the ones in our Macs can be as fast or faster when running 64-bit code compared to otherwise-equal 32-bit code. But 64-bit is still not an automatic "turbo" button, and "Let's make it 64-bit" is not a good business choice. A good business choice is "Let's make it 64-bit so we can do X."
As for memory, Final Cut doesn't need much. Seriously; Final Cut sips RAM. That's because it rarely needs to have more than twelve-or-so frames in memory at any given time. The whole design philosophy behind a Final Cut system is to have a storage array that's fast enough to provide the computer with frames in real time. Because of this, Final Cut doesn't need to do a ton of complex caching in main memory, even when doing real-time playback of unrendered effects. Compare this to an application like After Effects, for example, that uses main memory to cache rendered frames instead of writing them to disk, to provide real-time playback in a context where real-time playback is otherwise impossible. Or say Photoshop, where your entire raster is resident in main memory at all times, every pixel of every layer stored as a vast list of numbers. For those applications, an effectively unlimited memory address space is an automatic win; for Final Cut, the benefits aren't remotely so obvious.
On the subject of multi-processing and GPU offloading, Final Cut is actually rather brilliant. It's a highly modular system, code-wise, you see. Final Cut does no decoding or encoding itself. All of that is handled by Quicktime, and each Quicktime component for each separate format is a separate piece of software. That opens up the possibility for high levels of optimization at the Quicktime-component level, to take advantage of parallel architectures. This isn't merely theoretical; this is how ProRes works. One of the major selling points of ProRes when it debuted (and in turnabout, one of the major selling points of the eight-processor Mac Pro systems when they debuted) was the fact that real-time performance with ProRes scaled linearly with processor count. The Quicktime component for playback was highly optimized for the Mac Pro, and thus could play back roughly twice as many streams in real time on an eight-processor system as on a four-processor system. Linear scalability is the holy grail of parallel computing, and Apple came about as close as humanly possible to achieving it with ProRes and Final Cut 6 ? without making any major parallelization-related changes to Final Cut itself. It was all in that one module.
Similarly, the Smoothcam feature that was a major selling point of Final Cut 6 (it was 6, right?) is implemented as a plug-in. It wasn't necessary for Apple to rip out big chunks of the application to add that feature; they just implemented it as a plug-in and went on with their lives. This had the advantage of leaving the core application basically untouched, as far as the Smoothcam feature was concerned, which meant it was both easier to implement and less likely to introduce regression bugs in the application itself.
Does that mean Final Cut is perfect? Of course not! Even aside from the fact that there's always room for improvement in everything, there are some really obvious opportunities for improvement in Final Cut as it stands right now. The rendering engine could stand to be modularized, like playback and effects are today. If Final Cut wants to be a viable finishing system (which is not necessarily the case, but go with me) then the focus needs to be on ubiquitous real-time performance. Final Cut needs a real-time color corrector, real-time DVE, and at least two layers of real-time compositing. We're a long way from that; right now, Final Cut can't even consistently do real-time dissolves with full-resolution media. Dissolves! That's the simplest thing an editor can do! The focus for the Final Cut engineering team, in my just-some-random-guy opinion, needs to be on eliminating "render" as a thing the operator needs to know about. Will they ever succeed entirely? Of course not; inevitably, somebody's going to decide he wants to use Final Cut as a full-fledged 3D compositing system (sigh) and will try to stack up twelve or sixteen layers on the timeline and be dismayed to see the giant "Are you kidding?" error box pop up. But a reasonable goal should be to make eighty percent of what eighty percent of editors do be real-time.
Will they ever achieve that? No. I really don't think they will. You want to talk about GPU? Okay. When Autodesk ported Smoke to the Mac, they declared unilaterally that the only supported graphics option would be the eighteen hundred dollar QuadroFX board. Smoke won't run at all without that board. The technical reason revolves around backpath performance and drawing rendered frames back off the board and into main memory, but whatever. Point is, if you want a real-time system, you have to pay for it in two ways: first, by giving up the flexibility to just install the software on pretty much any computer you have lying around, and second by handing over lots of pictures of George Washington to get the right gear.
It sucks, but there's a lot that the graphics card in your Mac Pro just isn't useful for when it comes to Final Cut. Could the software take better advantage of graphics cards in general? Sure! OpenCL provides a robust software framework that opens up the possibility of offloading processing tasks to the graphics coprocessor ? or indeed, any other coprocessor, in principle like the Red Rocket board for R3D coprocessing ? and it'd be great if Final Cut took advantage of that. But the unhappy truth is that graphics boards aren't ready yet to be used as general-purpose processing nodes. There are still too many shortcomings ? like the aforementioned backpath performance ? that were never relevant as long as the graphics board's job was to do nothing more than take OpenGL instructions and textures from the computer and turn them into a raster. OpenCL lays the groundwork, but it's still up to the IHVs to do their part.
Snow Leopard, as I mentioned before, marked the public debut of a couple of fundamental core technologies ? GCD and OpenCL ? that have the potential to radically change the way high-performance software is written. But big changes happen slowly. Not this year but possibly next, and almost certainly by mid-2012, we'll see Final Cut Pro 8. Don't be surprised if at that time the software has been enhanced by these underlying core technologies to emphasize real-time performance. It just can't all happen overnight, y'know? And you're certainly not more likely to get it sooner by imploring Apple to discard all the work that's been put into Final Cut over the past decade and start over from scratch. That way lies madness.
Quote
FCP, at it's core, is 10yr code
That's true. But remember that at its core, Mac OS X is thirty-year-old code. I don't mean some of the underlying design principles and stuff; I mean that a big chunk of Mac OS X consists of source code that was physically typed by somebody in the late 70s, early 80s, and has not been changed since. The fact that some or a lot of the underlying source code is a decade old does not mean that source code has gone off and needs to be thrown out before we all catch salmonella.
For another data point, Media Composer was developed in the late 80s and hasn't been ground-up rewritten since. And though it debuted on the Mac, it wasn't even originally a Mac application! It was originally written to run on workstations built by a company nobody even remembers any more. Along the way, Media Composer has been modified to run on the Power PC, on Intel computers under the Windows OS and on Mac OS X. By all rights, it should be a wonky, unstable piece of junk ? but from what I've heard, the universal opinion is that version 4 is the best version yet.
There's an old saying about babies and bathwater here, but I can't remember how it goes.
Quote
so it can take advantage of things like being 64-bit, being able to access more RAM (I think 3 or 4 gigs is the limit right now), being able to better leverage all the cores the Mac Pros have, take more advantage of the GPU, etc.,.
Let's break these down individually.
"Make it 64-bit" is a damn tricky thing. Back in the 90s, I worked primarily on SGI systems, workstations and mini-supercomputers. Those were among the first widely available 64-bit systems, and SGI did something very clever with them. Knowing there was a huge (in relative terms) installed base of software that'd been compiled against the 32-bit MIPS ABI, SGI made sure their 64-bit systems would run all that older 32-bit code without modification. (This was an approach Intel famously failed to take with their Itanium line of high-end chips, and they failed commercially as a consequence.) But in doing so, they discovered something that's only obvious in retrospect: All other things being equal, a 64-bit version of an application will run slower than its corresponding 32-bit version.
It's easy to see why. A 64-bit application can address tons more memory, because it uses 64-bit-long memory pointers ? essentially just logical addresses to places in memory ? rather than 32-bit pointers. But a lot of what computers do is store and recall pointers, so pointers end up in processor cache all the time. Like literally all the time; a typical user-facing application does way more with pointers and handles (pointers-to-pointers) than it does with user data.
And 64-bit pointers are (surprise) twice as big as 32-bit pointers. Which means you can only fit half as many of them in the various high-speed caches in your computer. Which means you have more cache misses, and cache misses are really expensive in terms of computer performance. Even though it's measured in microseconds takes a lot longer to fetch a number from main memory than from cache, and when you're doing that a billion times a second, it adds up.
So for about a decade, the conventional wisdom was that 64-bit computing was sometimes necessary ? when you needed to manipulate large data sets in memory ? but never desirable.
Intel (and others, but we're all using Intel microchips right now) did some clever things to try to combat that. It took them years of trial and error, but it's to the point now where 64-bit Intel microchips like the ones in our Macs can be as fast or faster when running 64-bit code compared to otherwise-equal 32-bit code. But 64-bit is still not an automatic "turbo" button, and "Let's make it 64-bit" is not a good business choice. A good business choice is "Let's make it 64-bit so we can do X."
As for memory, Final Cut doesn't need much. Seriously; Final Cut sips RAM. That's because it rarely needs to have more than twelve-or-so frames in memory at any given time. The whole design philosophy behind a Final Cut system is to have a storage array that's fast enough to provide the computer with frames in real time. Because of this, Final Cut doesn't need to do a ton of complex caching in main memory, even when doing real-time playback of unrendered effects. Compare this to an application like After Effects, for example, that uses main memory to cache rendered frames instead of writing them to disk, to provide real-time playback in a context where real-time playback is otherwise impossible. Or say Photoshop, where your entire raster is resident in main memory at all times, every pixel of every layer stored as a vast list of numbers. For those applications, an effectively unlimited memory address space is an automatic win; for Final Cut, the benefits aren't remotely so obvious.
On the subject of multi-processing and GPU offloading, Final Cut is actually rather brilliant. It's a highly modular system, code-wise, you see. Final Cut does no decoding or encoding itself. All of that is handled by Quicktime, and each Quicktime component for each separate format is a separate piece of software. That opens up the possibility for high levels of optimization at the Quicktime-component level, to take advantage of parallel architectures. This isn't merely theoretical; this is how ProRes works. One of the major selling points of ProRes when it debuted (and in turnabout, one of the major selling points of the eight-processor Mac Pro systems when they debuted) was the fact that real-time performance with ProRes scaled linearly with processor count. The Quicktime component for playback was highly optimized for the Mac Pro, and thus could play back roughly twice as many streams in real time on an eight-processor system as on a four-processor system. Linear scalability is the holy grail of parallel computing, and Apple came about as close as humanly possible to achieving it with ProRes and Final Cut 6 ? without making any major parallelization-related changes to Final Cut itself. It was all in that one module.
Similarly, the Smoothcam feature that was a major selling point of Final Cut 6 (it was 6, right?) is implemented as a plug-in. It wasn't necessary for Apple to rip out big chunks of the application to add that feature; they just implemented it as a plug-in and went on with their lives. This had the advantage of leaving the core application basically untouched, as far as the Smoothcam feature was concerned, which meant it was both easier to implement and less likely to introduce regression bugs in the application itself.
Does that mean Final Cut is perfect? Of course not! Even aside from the fact that there's always room for improvement in everything, there are some really obvious opportunities for improvement in Final Cut as it stands right now. The rendering engine could stand to be modularized, like playback and effects are today. If Final Cut wants to be a viable finishing system (which is not necessarily the case, but go with me) then the focus needs to be on ubiquitous real-time performance. Final Cut needs a real-time color corrector, real-time DVE, and at least two layers of real-time compositing. We're a long way from that; right now, Final Cut can't even consistently do real-time dissolves with full-resolution media. Dissolves! That's the simplest thing an editor can do! The focus for the Final Cut engineering team, in my just-some-random-guy opinion, needs to be on eliminating "render" as a thing the operator needs to know about. Will they ever succeed entirely? Of course not; inevitably, somebody's going to decide he wants to use Final Cut as a full-fledged 3D compositing system (sigh) and will try to stack up twelve or sixteen layers on the timeline and be dismayed to see the giant "Are you kidding?" error box pop up. But a reasonable goal should be to make eighty percent of what eighty percent of editors do be real-time.
Will they ever achieve that? No. I really don't think they will. You want to talk about GPU? Okay. When Autodesk ported Smoke to the Mac, they declared unilaterally that the only supported graphics option would be the eighteen hundred dollar QuadroFX board. Smoke won't run at all without that board. The technical reason revolves around backpath performance and drawing rendered frames back off the board and into main memory, but whatever. Point is, if you want a real-time system, you have to pay for it in two ways: first, by giving up the flexibility to just install the software on pretty much any computer you have lying around, and second by handing over lots of pictures of George Washington to get the right gear.
It sucks, but there's a lot that the graphics card in your Mac Pro just isn't useful for when it comes to Final Cut. Could the software take better advantage of graphics cards in general? Sure! OpenCL provides a robust software framework that opens up the possibility of offloading processing tasks to the graphics coprocessor ? or indeed, any other coprocessor, in principle like the Red Rocket board for R3D coprocessing ? and it'd be great if Final Cut took advantage of that. But the unhappy truth is that graphics boards aren't ready yet to be used as general-purpose processing nodes. There are still too many shortcomings ? like the aforementioned backpath performance ? that were never relevant as long as the graphics board's job was to do nothing more than take OpenGL instructions and textures from the computer and turn them into a raster. OpenCL lays the groundwork, but it's still up to the IHVs to do their part.
Snow Leopard, as I mentioned before, marked the public debut of a couple of fundamental core technologies ? GCD and OpenCL ? that have the potential to radically change the way high-performance software is written. But big changes happen slowly. Not this year but possibly next, and almost certainly by mid-2012, we'll see Final Cut Pro 8. Don't be surprised if at that time the software has been enhanced by these underlying core technologies to emphasize real-time performance. It just can't all happen overnight, y'know? And you're certainly not more likely to get it sooner by imploring Apple to discard all the work that's been put into Final Cut over the past decade and start over from scratch. That way lies madness.
|
Re: Uh Oh! Not Good... February 19, 2010 09:34AM |
>I think playing that youtube video blew out my right speaker :-\
It probably won for sound design too. It's a very unique stereo field mix. One speaker just produces buzz... Wait, i think that's my earthing...
>As for memory, Final Cut doesn't need much. Seriously; Final Cut sips RAM.
There is one long overdue limitation, that has often been attributed to RAM, and that is the inability to handle a large project file. This is one major drawback when we start looking at long form or especially long form multi-cam edits which can really bloat up a project size. On my own end, I have my own practice of breaking up projects into different stages. And when I take on a job as a finishing editor, I tend to duplicate the project and delete all unnecessary elements (all previous edit sequences, rushes, etc..). And on some edits, I make time stamped back ups, and keep up to only 3 or 4 previous edit sequences. But this is in itself a workaround.
>But a reasonable goal should be to make eighty percent of what eighty percent of editors do be
>real-time.
Not sure if this is a good thing or a bad thing. One of the reasons FCP was so aggressively developed earlier on, was because of then Microsoft's investment into Avid. ProApps sell pro hardware. Steve Jobs knows that, and that's why Apple bought KeyGrip.
Years ago, when FCP came out with the 3 way color corrector, many folks on the other platforms, looked over and drooled. Then multi-cam came out, and a lot of guys made the leap over to FCP. And at one point in time, FCP had one big advantage over Avid- the ability to work easily with file based HD formats, and it was even more stable than the Avid on the Adrenaline. That was great. What was once seen as "the poor man's Avid", now could do practically everything that used to require expensive proprietary hardware and workstation, and in some regards even held its own.
One good thing about Snow Leopard, is that Apple is laying the groundwork to better utilize the hardware that we have today- OpenCL, Grand Central, the push towards Cocoa, etc... And then, there's this business structure where ProApps uses the built-in infrastructure in OSX to sell the Pro hardware. Then there's the other side of Apple's business structure, where Apple consumer/mobile hardware uses the infrastructure in OSX (QTX, scaled down OSX). Abandoning ProApps would mean to rely solely on Avid, or Adobe to develop software to push sales of the Apple pro hardware range, and we know that's not going to happen. And the average consumer is as interested in buying a high end MacPro, as they are in learning Chinese ballet, not really, but you get the picture. So the development of Apple's ProApps, and capturing a sizeable chunk of the target market, is extremely important to the sale of Apple's Pro hardware range.
On the other hand, FCP always had a few outstanding bugs- the inability to trim properly with Media Manager, the inability to work with large project files, etc... To some degree, it does seem as if the ProApps folks have been caught napping, as Avid came fighting back with ScriptSync along with an audio transcriber to run it on, and the open timeline, Avid Media Access, amongst other features... Adobe has an audio transcriber in Premiere, and AE is able to utilize all the multiple processors available to render. The new FCS had some neat additions, but the ability to use iChat with your producer is no magic bullet (no pun intended). I sure hope that the FCP development team has been paying close attention to all this, because many of us do want those new bells and whistles in the other platforms, including a faster renderer.
I have a love/hate relationship with the rest of the FCS Apps. I love most of it, especially Color, and I am slowly discovering Motion more and more (after helping a friend do a lower third on a reel the other night). I use Motion when I'm lazy to send the files over the AE guys. And I used to really hate Motion. If FCP is the poorer man's Avid, then Motion completely falls below the poverty line. It was unstable, crashy (I had a Motion project that would crash upon launching, and it consists of only 1 shot with a tracker on it), and Motion has been temperamentally worse than that nightmare ex-girlfriend. I'm not sure how much improvements it has made in the latest incarnation.
Then once, I made a foray into Soundtrack Pro. I just couldn't get it to work on a 22 and a half minute video that I sent out as a soundtrack pro multi-track project. It will open, then it will beachball for ages, before sending out a love letter to Apple employees. Perhaps if I compressed the video into a low resolution Mpeg4, it may have worked, but since then, I've always used it as an indie mastering tool on the overall dialog mix.
For me, using FCP together with the whole extended family- including Motion for extended type, visual effects and compositing; Soundtrack for a nice compressed, puffy audio mix; Color for that beautiful look... is like trying to work a long distance relationship- troublesome and usually unsatisfying. I'm not up to it in many regards, and it seems to take a lot of time and patience. In some parts due to the cumbersome workflow, and in others, due to seemingly erratic software behavior.
I do like the FCS apps, just that I hope they eventually make the cross app relationship between the apps more functional and less temperamental. But overall, it is because of the FCS apps that makes FCP so much cooler than Avid.
I think I've digressed.
www.strypesinpost.com
It probably won for sound design too. It's a very unique stereo field mix. One speaker just produces buzz... Wait, i think that's my earthing...
>As for memory, Final Cut doesn't need much. Seriously; Final Cut sips RAM.
There is one long overdue limitation, that has often been attributed to RAM, and that is the inability to handle a large project file. This is one major drawback when we start looking at long form or especially long form multi-cam edits which can really bloat up a project size. On my own end, I have my own practice of breaking up projects into different stages. And when I take on a job as a finishing editor, I tend to duplicate the project and delete all unnecessary elements (all previous edit sequences, rushes, etc..). And on some edits, I make time stamped back ups, and keep up to only 3 or 4 previous edit sequences. But this is in itself a workaround.
>But a reasonable goal should be to make eighty percent of what eighty percent of editors do be
>real-time.
Not sure if this is a good thing or a bad thing. One of the reasons FCP was so aggressively developed earlier on, was because of then Microsoft's investment into Avid. ProApps sell pro hardware. Steve Jobs knows that, and that's why Apple bought KeyGrip.
Years ago, when FCP came out with the 3 way color corrector, many folks on the other platforms, looked over and drooled. Then multi-cam came out, and a lot of guys made the leap over to FCP. And at one point in time, FCP had one big advantage over Avid- the ability to work easily with file based HD formats, and it was even more stable than the Avid on the Adrenaline. That was great. What was once seen as "the poor man's Avid", now could do practically everything that used to require expensive proprietary hardware and workstation, and in some regards even held its own.
One good thing about Snow Leopard, is that Apple is laying the groundwork to better utilize the hardware that we have today- OpenCL, Grand Central, the push towards Cocoa, etc... And then, there's this business structure where ProApps uses the built-in infrastructure in OSX to sell the Pro hardware. Then there's the other side of Apple's business structure, where Apple consumer/mobile hardware uses the infrastructure in OSX (QTX, scaled down OSX). Abandoning ProApps would mean to rely solely on Avid, or Adobe to develop software to push sales of the Apple pro hardware range, and we know that's not going to happen. And the average consumer is as interested in buying a high end MacPro, as they are in learning Chinese ballet, not really, but you get the picture. So the development of Apple's ProApps, and capturing a sizeable chunk of the target market, is extremely important to the sale of Apple's Pro hardware range.
On the other hand, FCP always had a few outstanding bugs- the inability to trim properly with Media Manager, the inability to work with large project files, etc... To some degree, it does seem as if the ProApps folks have been caught napping, as Avid came fighting back with ScriptSync along with an audio transcriber to run it on, and the open timeline, Avid Media Access, amongst other features... Adobe has an audio transcriber in Premiere, and AE is able to utilize all the multiple processors available to render. The new FCS had some neat additions, but the ability to use iChat with your producer is no magic bullet (no pun intended). I sure hope that the FCP development team has been paying close attention to all this, because many of us do want those new bells and whistles in the other platforms, including a faster renderer.
I have a love/hate relationship with the rest of the FCS Apps. I love most of it, especially Color, and I am slowly discovering Motion more and more (after helping a friend do a lower third on a reel the other night). I use Motion when I'm lazy to send the files over the AE guys. And I used to really hate Motion. If FCP is the poorer man's Avid, then Motion completely falls below the poverty line. It was unstable, crashy (I had a Motion project that would crash upon launching, and it consists of only 1 shot with a tracker on it), and Motion has been temperamentally worse than that nightmare ex-girlfriend. I'm not sure how much improvements it has made in the latest incarnation.
Then once, I made a foray into Soundtrack Pro. I just couldn't get it to work on a 22 and a half minute video that I sent out as a soundtrack pro multi-track project. It will open, then it will beachball for ages, before sending out a love letter to Apple employees. Perhaps if I compressed the video into a low resolution Mpeg4, it may have worked, but since then, I've always used it as an indie mastering tool on the overall dialog mix.
For me, using FCP together with the whole extended family- including Motion for extended type, visual effects and compositing; Soundtrack for a nice compressed, puffy audio mix; Color for that beautiful look... is like trying to work a long distance relationship- troublesome and usually unsatisfying. I'm not up to it in many regards, and it seems to take a lot of time and patience. In some parts due to the cumbersome workflow, and in others, due to seemingly erratic software behavior.
I do like the FCS apps, just that I hope they eventually make the cross app relationship between the apps more functional and less temperamental. But overall, it is because of the FCS apps that makes FCP so much cooler than Avid.
I think I've digressed.
www.strypesinpost.com
|
Re: Uh Oh! Not Good... February 19, 2010 09:57AM |
Quote
the inability to handle a large project file
I've never done a feature-length job, nor one with a billion skrillion media files, so I haven't run up against this myself. I've heard about it, though, and obviously I agree that it needs fixing. I question whether it's a RAM thing, though. Final Cut can address two gigabytes of RAM. I know we all have machines with between four and thirty-two gigs of RAM these days, but two gigs is a lot! I wouldn't be surprised if the problem isn't actually related to RAM at all, but is actually a consequence of some data structure design choices. But that's pure speculation on my part. In any case, I'm pretty certain that merely recompiling Final Cut as a 64-bit binary wouldn't fix it.
Quote
Apple is laying the groundwork to better utilize the hardware that we have today
To wander even further away from the topic, I heard a fascinating bit of speculation this week. We all know the iPhone/iPad operating system is Mac OS X with many of the computer-specific frameworks removed, yeah? The speculation I heard was that Apple is preparing to roll out a future version of that operating system that totally reworks how multitasking is done, in order to make the devices more reliable and energy efficient.
Back in the bad old days, the Mac had cooperative multitasking; that is, each application had to voluntarily give up the microprocessor for any other tasks to run. This was a problem because an application that, due to a bug, got hung up somewhere would never get back around to the part of its run loop where it relinquished control of the processor, so your Mac would lock up.
This model was replaced in Mac OS X with preemptive multitasking: The operating system interrupts running applications many, many times every second, so unresponsive applications can be killed by the OS without bringing down the whole computer.
But it's not at all easy to figure out which applications are running normally and which are totally unresponsive. So the OS is especially bad at automatically killing runaway applications. Grand Central Dispatch puts a layer of abstraction into the tasking system: Applications submit individual task components to the dispatcher, and the dispatcher queues those tasks up on a managed pool of execution threads. Call it even-more-preemptive multitasking, if you want.
The speculation I heard was that a future version of the iPhone/iPad/whatever it's called OS will incorporate GCD, and in fact that that will be the only way of doing parallel and asynchronous tasks on those devices. Right now you can't fire off an asynchronous background task on the iPhone or iPad at all, because those devices have no way to manage background tasks. If one misbehaves, you'd have no choice but to reboot the device, which would suck. But in the future, applications will be able to submit tasks to the main dispatcher, which will be able to wrangle tasks to maximize battery life, guarantee real-time responsiveness of the UI and maintain a secure environment.
This isn't a rumor; it was just pure speculation by a guy who freely admitted he was making it up. But it was a very neat idea.
Quote
On the other hand, FCP always had a few outstanding bugs
You know, I wonder if the collaboration between the "pro apps" developers at Apple and the OS engineers isn't closer than we realize. Final Cut doesn't have these outstanding bugs ? or limitations, I think is a better way of putting it; "bugs" are things that aren't working as designed, and what we're talking about are for the most part design choices that make no sense or seem like bad decisions ? because the Final Cut developers are stupid or lazy. They have these "bugs" because writing big computer programs is hard! Like, harder than it really has any right to be in the 21st century. Writing crappy computer programs is easy, but writing programs that are complex, well designed and reliable all at the same time is really, really difficult.
I wonder if Apple's OS folks don't observe this up-close and spend their time thinking of ways to make application development easier. GCD, again, is a great example. There's nothing in GCD that was impossible before. It's just that in order to do parallelization right you had to spend ages writing your own thread pooling and queuing system, and oh by the way you had to do it very carefully to make sure it wasn't buggy, and every minute you spent doing that you weren't working on your application proper, so nobody bothered. The trend with Mac OS X ever since the NeXT days has been to take as much of the mundane work out of the developers' hands as possible, letting them focus on those parts of their application that actually did interesting things.
It's 2010, and nearly all computer software sucks. And it's not because people are stupid. It's because writing computer software sucks. Seems like Apple is aware of this, and working to improve it. But it's a long, slow process.
Your experience with the other Studio apps parallels mine, Strypes. To me, Soundtrack and Motion just don't feel done. They've been incredibly unstable for me in the past, and consequently I'm left with the feeling that I have to do everything really slowly and carefully with them, saving after every mouse click, 'cause they're gonna fall over any second and take my work with them. I'm just not comfortable in those applications, because I don't trust them.
|
Re: Uh Oh! Not Good... February 19, 2010 10:17AM |
I dub this "The Jeff Harrell Thread". Wow.
When life gives you dilemmas...make dilemmanade.
When life gives you dilemmas...make dilemmanade.
|
Re: Uh Oh! Not Good... February 19, 2010 10:32AM |
>Apple has never directly competed with Avid.
I would disagree with this point. When Apple bought KeyGrip, it had to do with Microsoft's move on trying to shut out Quicktime and involvement with Avid. And Adobe shifted away from the Mac platform to focus on publishing..
When editors like Shane started cutting broadcast programs on FCP, it made a huge difference. It broke the monopoly that Avid had in the NLE market, and it was making huge inroads into broadcast editing. It made Avid give up the dongle, abandon its reliance on hardware, reduce the price on the MC, and years ago, we've seen Avid port some of the color correction tools down from the Symphony line, bring in fluid motion, etc..
On a microscope, we could split the market up into sections- one for broadcast, one for high end theatrical releases, one for the web publisher, one for indie work, one for short form, and probably one for home enthusiasts. And on that level, you could say that FCP takes the broadcast and the indie market, and in the last FCS release, we saw Apple trying to strengthen its grip on that indie market.
However, on another level, you could say that the difference between broadcast and the higher end market isn't very big, and they share a lot of similarities- creative editorial. Then again, when we're talking about a suite of apps performing a certain set of cross-the-board post production workflow, Adobe is eating into a certain chunk of it, with their Production Premium.
You could say that neither Adobe nor Avid are direct competitors with FCS, since Adobe's offerings tend to favor designers and motion graphic artists, while the Avid Media Composer favors folks who strictly want an offline machine for creative editorial, and if they completely dominate each market. It leaves FCS in between a rock and a hard place- folks who don't want to spend that $1- $2K more on an Avid machine, and motion graphics and shortform guys who currently prefer using FCP as an assembly (and sometimes an audio mixing) tool.
The price difference between an Avid and an FCP setup isn't as steep as it was years ago, where an Avid station could buy you three FCP stations. And lots of folks started buying into FCP because it was that much cheaper compared to an Avid, and it was proven that it could deliver in the broadcast world.
So to a large degree, they are competitors, no matter how we look at it.
www.strypesinpost.com
I would disagree with this point. When Apple bought KeyGrip, it had to do with Microsoft's move on trying to shut out Quicktime and involvement with Avid. And Adobe shifted away from the Mac platform to focus on publishing..
When editors like Shane started cutting broadcast programs on FCP, it made a huge difference. It broke the monopoly that Avid had in the NLE market, and it was making huge inroads into broadcast editing. It made Avid give up the dongle, abandon its reliance on hardware, reduce the price on the MC, and years ago, we've seen Avid port some of the color correction tools down from the Symphony line, bring in fluid motion, etc..
On a microscope, we could split the market up into sections- one for broadcast, one for high end theatrical releases, one for the web publisher, one for indie work, one for short form, and probably one for home enthusiasts. And on that level, you could say that FCP takes the broadcast and the indie market, and in the last FCS release, we saw Apple trying to strengthen its grip on that indie market.
However, on another level, you could say that the difference between broadcast and the higher end market isn't very big, and they share a lot of similarities- creative editorial. Then again, when we're talking about a suite of apps performing a certain set of cross-the-board post production workflow, Adobe is eating into a certain chunk of it, with their Production Premium.
You could say that neither Adobe nor Avid are direct competitors with FCS, since Adobe's offerings tend to favor designers and motion graphic artists, while the Avid Media Composer favors folks who strictly want an offline machine for creative editorial, and if they completely dominate each market. It leaves FCS in between a rock and a hard place- folks who don't want to spend that $1- $2K more on an Avid machine, and motion graphics and shortform guys who currently prefer using FCP as an assembly (and sometimes an audio mixing) tool.
The price difference between an Avid and an FCP setup isn't as steep as it was years ago, where an Avid station could buy you three FCP stations. And lots of folks started buying into FCP because it was that much cheaper compared to an Avid, and it was proven that it could deliver in the broadcast world.
So to a large degree, they are competitors, no matter how we look at it.
www.strypesinpost.com
|
Re: Uh Oh! Not Good... February 19, 2010 11:33AM |
>we're talking about are for the most part design choices that make no sense or seem like bad
>decisions
A media manager tool that trims what it likes, the crooked playhead in the viewer window motion tab, speed ramping a clip with different field order produces weird stuttering motion, multi-clips that cannot be sent to Color even after collapsing the multiclips. These don't look like design choices...
A while ago, I had a chat with a guy who ran a post house/tape facility, and he mentioned that one of the fundamental things in an NLE, is the ability to decompose a sequence remotely and re-capture. It makes a lot of sense when you offline/online at a facility. In those cases, it makes sense to send them a project file and the tapes, and they'll decompose and recapture. In FCP's case, you have send them the tapes, along with the project file, and a hard drive with the offline resolution media. But granted, this part is kind of a weird dance that we've grown so accustomed to working with FCP, and changing it will feel like using the new speed tool (copy, go to end of sequence, change speed, go back, paste over).
www.strypesinpost.com
>decisions
A media manager tool that trims what it likes, the crooked playhead in the viewer window motion tab, speed ramping a clip with different field order produces weird stuttering motion, multi-clips that cannot be sent to Color even after collapsing the multiclips. These don't look like design choices...
A while ago, I had a chat with a guy who ran a post house/tape facility, and he mentioned that one of the fundamental things in an NLE, is the ability to decompose a sequence remotely and re-capture. It makes a lot of sense when you offline/online at a facility. In those cases, it makes sense to send them a project file and the tapes, and they'll decompose and recapture. In FCP's case, you have send them the tapes, along with the project file, and a hard drive with the offline resolution media. But granted, this part is kind of a weird dance that we've grown so accustomed to working with FCP, and changing it will feel like using the new speed tool (copy, go to end of sequence, change speed, go back, paste over).
www.strypesinpost.com
|
Re: Uh Oh! Not Good... February 19, 2010 12:38PM |
The news leaks into more channels:
[www.macdailynews.com]
[distorted-loop.com]
ak
Sleeplings, AWAKE!
[www.macdailynews.com]
[distorted-loop.com]
ak
Sleeplings, AWAKE!
|
Re: Uh Oh! Not Good... February 19, 2010 01:50PM |
Jeff needs a job, so that he can get back to SHORTER posts that I feel like I have time to read. Not the NOVELS he is spouting now.
Someone hire Jeff please? In the DC area. Or Dallas. He likes Dallas.
www.shanerosseditor.com
Listen to THE EDIT BAY Podcast on iTunes
[itunes.apple.com]
Someone hire Jeff please? In the DC area. Or Dallas. He likes Dallas.
www.shanerosseditor.com
Listen to THE EDIT BAY Podcast on iTunes
[itunes.apple.com]
|
Re: Uh Oh! Not Good... February 19, 2010 02:44PM |
Quote
Jeff needs a job, so that he can get back to SHORTER posts that I feel like I have time to read. Not the NOVELS he is spouting now.
Jeff's posts have elevated my ADHD to the point where I have to close out of the forum to calm down
When life gives you dilemmas...make dilemmanade.
|
Re: Uh Oh! Not Good... February 19, 2010 02:59PM |
FCP isn't going anywhere. Can we stop the GLOOM AND DOOM when people are laid off (who's to say the project they have been hired for hasn't just been completed?) or when the app hasn't been updated in two years? People freaking out that ProApps are dying and Apple is letting it go in favor of the iPhone.
Stop being reactionary. Just like people saying Avid is dying. It ain't. They are changing, shuffling people, reorganizing. Hell, look at the last two updates! They blow FCP away with features now. I wanna offline edit with that now, lemme tell you. By offline, I mean everything BUT color correct. That is still...well... They need to work on that.
www.shanerosseditor.com
Listen to THE EDIT BAY Podcast on iTunes
[itunes.apple.com]
Stop being reactionary. Just like people saying Avid is dying. It ain't. They are changing, shuffling people, reorganizing. Hell, look at the last two updates! They blow FCP away with features now. I wanna offline edit with that now, lemme tell you. By offline, I mean everything BUT color correct. That is still...well... They need to work on that.
www.shanerosseditor.com
Listen to THE EDIT BAY Podcast on iTunes
[itunes.apple.com]
|
Re: Uh Oh! Not Good... February 19, 2010 03:31PM |
>Kind of interesting that for last few years, always around this time of the year, we tend to
>speculate the end of Final Cut Pro.
Hay fever?
www.strypesinpost.com
>speculate the end of Final Cut Pro.
Hay fever?
www.strypesinpost.com
|
Re: Uh Oh! Not Good... February 22, 2010 03:38AM |
>same project in Fcp 6 and Fcp 7 ?: Fcp 6 = 343MB / Fcp 7 : 85 MB
Nick made a discovery that he could dramatically reduce the size of the project file in FCP 6 by copying everything into a new project file. And wow, 300 MBs? I try to keep everything in the region of 50 MBs.
www.strypesinpost.com
Nick made a discovery that he could dramatically reduce the size of the project file in FCP 6 by copying everything into a new project file. And wow, 300 MBs? I try to keep everything in the region of 50 MBs.
www.strypesinpost.com
|
Re: Uh Oh! Not Good... February 22, 2010 09:15AM |
Quote
strypes
Nick made a discovery that he could dramatically reduce the size of the project file in FCP 6 by copying everything into a new project file. And wow, 300 MBs? I try to keep everything in the region of 50 MBs.
And I had a project that was over 100MB that had nothing in it. No sequences, clips or anything. I haven't been able to prove it conclusively but my intuition tells me it's related to multiclips. Project size ballooning is something I have talked about here and I think I've said a couple of times that multiclips is one area that I find FCP to be significantly buggy.
ak
Sleeplings, AWAKE!
|
Re: Uh Oh! Not Good... February 26, 2010 01:29PM |
Pete also released "Pete's Plug-ins"...a free batch of AE plug-ins that I have used many times over the years. Yeah...I would trust what Pete says.
When life gives you dilemmas...make dilemmanade.
When life gives you dilemmas...make dilemmanade.
Sorry, only registered users may post in this forum.
