-
Version 1.0 is the new 0.9 – CNet Article
-
[Herb Sevush] “By jove, I think you’ve coined a new phrase, and I’m proud to have been a part of it’s gestation.”
Thanks for posting it. It gave me some great chuckles.
-
[Bill Davis] “I know I’ve stretched into new work areas and even have a few completely new clients based on the fact that this particular tool is AMAZING for producing certain types of content.”
So this is the only NLE on the market that allows you to have moved into these new areas, and it’s the only software that is well suited for producing that “certain types of content”? And for clarity, what types of content is it, and what is the metric you measure FCPX against?
I say, if your metric is FCP7 then it’s a false comparison, for FCP7 – at its death – was woefully behind the other major players both in features and speed.
—————-
Michael Hancock
Editor -
[David Lawrence] “Agree that the big 2012 update will tell us a lot. But I wouldn’t use broadcast monitoring as the main indicator of Apple’s seriousness. I’d also look at the project bloat bug.”
I’m not sure I understand what, exactly you mean by “bug”, David.
As I understand it, the main problem with “project bloat” in X is people who are doing something they think works one way – only to come to the understanding that the “bloat” is the natural result of their failure to understand how the software functions under the hood.
As I understand it, it’s kinda like if I have a word document, and as I make my changes, I’m not noticing that instead of being sensible by dumping all my revisions and false starts, I leave all that crap at the head of the main file. Then with that overly bloated and complex document (timeline) to start with, I then start doing a “select all” and copying and pasting that bloated document so that it concatenates over and over increasing it’s size wildly. That’s not a BUG in the program so much as it’s my ignorance of what I’m doing.
Maybe there’s an actual “bug” in FCP-X that I don’t understand, but I read here pretty regularly, and after following the discussion as well as I can, that’s the understanding I’ve come to.
When X users start making compound clips, cutting and pasting the results – and otherwise truncating them not understanding that they are actually pointers to larger files, and so, they end up duplicating big files by a factor of 2, then 4, then 8, then 16, ets – they’re getting really big files – precisely because their specific actions have told the program that’s what they want.
The solution is to change ones actions. To learn how not to inadvertently double your file sizes.
If there are actual memory leaks causing files to blow up – that’s one thing.
But if users are just mis-understanding the nature of how the program works, and adopting bad editing habits – how can that be the programs fault?
Just wondering.
“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] “As I understand it, the main problem with “project bloat” in X is people who are doing something they think works one way – only to come to the understanding that the “bloat” is the natural result of their failure to understand how the software functions under the hood.”
Like using markers? https://forums.creativecow.net/readpost/344/5732
If the guy in that thread is just holding it wrong, how does he get around the problem? Markers can be very valuable – best practice to just not use them, I suppose?
And if it is just a case of people holding it wrong then Apple really needs to step up and explain how their software should be used and practices to best avoid so you don’t lose your work and have your project file bloat out of control. They’re pretty mum on the whole subject, considering.
—————-
Michael Hancock
Editor -
[Michael Hancock] “was woefully behind the other major players both in features and speed.”
Finally some corroboration.
-
[Michael Hancock] ”
Like using markers? https://forums.creativecow.net/readpost/344/5732If the guy in that thread is just holding it wrong, how does he get around the problem? Markers can be very valuable – best practice to just not use them, I suppose?
And if it is just a case of people holding it wrong then Apple really needs to step up and explain how their software should be used and practices to best avoid so you don’t lose your work and have your project file bloat out of control. They’re pretty mum on the whole subject, considering.
“I believe this bloat is a bug. It is an non-optimized XML structure. There’s no reason for all of the repeated data.
Apple themselves are holding it wrong on this one.
-
I hope it’s a bug. If it’s hardwired into the code it may be incredibly difficult to fix. EDIT: By hardwired I mean, if that’s how it’s supposed to work. Seems like an incredible oversight. How was it not caught during beta testing?
—————-
Michael Hancock
Editor -
[Michael Hancock] “I hope it’s a bug. If it’s hardwired into the code it may be incredibly difficult to fix. EDIT: By hardwired I mean, if that’s how it’s supposed to work. Seems like an incredible oversight. How was it not caught during beta testing?”
I could insert a snide half joke here about how that’s exactly the location this bug was caught.
-
[Michael Hancock] “I hope it’s a bug. If it’s hardwired into the code it may be incredibly difficult to fix. EDIT: By hardwired I mean, if that’s how it’s supposed to work. Seems like an incredible oversight. How was it not caught during beta testing”
Exactly.
Bill, I’m calling project bloat a bug because I want to be optimistic. If it’s a bug, it’s fixable. If it’s a deep engineering failure, it could easily kill the product.
The bloat problem seems deeper than an XML optimization bug. An XML export is simply a list that gets generated at export time reflecting the current state of the timeline. This bloat problem is clearly tied to the database architecture and the data model at the foundation of the program. This is why it’s a bit scary. It’s a lot more difficult and expensive to fix a bad foundation after a house is built than it is to get it right to begin with.
The database design for compound clips is broken. This is a simple fact. A “Your holding it wrong” argument doesn’t change or fix it. Hopefully Apple’s engineers can and will.
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl -
[Jeremy Garchow] “I could insert a snide half joke here about how that’s exactly the location this bug was caught.”
Hah! Where I come from, bugs like this are considered alpha! 😉
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl
Reply to this Discussion! Login or Sign Up