Activity › Forums › Apple Final Cut Pro Legacy › Known Issues. Enough is enough already! Wake up Apple.
-
Known Issues. Enough is enough already! Wake up Apple.
Martin Baker replied 18 years, 8 months ago 15 Members · 29 Replies
-
Herb Sevush
September 13, 2007 at 9:11 pmWalter –
Of course Apple would have to change the underlying data structure to fix the innumerable bugs and annoyances that plague this product. I never thought they were so stupid as to intentionally annoy their user base — if it were easy they would have fixed things years ago. And I know that it’s very expensive and time consuming – but I don’t really give a shit — none of my clients care if a necessary revision is hard / time consuming / expensive to do – if there’s a problem that I created I either fix it or look for new clients.
If Apple doesn’t address their underlying structural problems they will loose out to either Adobe or some other player that is willing to do the work. And I will not be among the last to jump ship.
Herb Sevush
Zebra Productions -
Walter Biscardi
September 13, 2007 at 10:45 pm[Sean ONeil] “Like the idiotic design of what happens when you put 486 clips on a 480 timeline (it scales it instead of cropping it).”
Actually, that’s a User Pref, just turn that off and it goes back to cropping it like before. I found that FCP kept scaling my still images when I didn’t want it to. Now it leaves them alone like before.
Walter Biscardi, Jr.
https://www.biscardicreative.com
HD Editorial & Animation for Broadcast and independent productions.All Things Apple Podcast! https://cowcast.creativecow.net/all_things_apple/index.html
Read my blog! https://blogs.creativecow.net/WalterBiscardi
-
Paul Dickin
September 13, 2007 at 11:54 pm[Sean ONeil] “They can fix whatever they want in it. The choose not to. Simple as that. There is not some weird XML limitation. They just haven’t spent enough on development and QC.”
Hi
I’m not sure about that.
They’d probably have to ‘fix’ the QuickTime file format first… 🙁
And give OS X a robust file database that tracks media-file metadata (like timecode).Because if you just ‘fix’ FCP on top of a quicksand of OS murkiness, you perpetuate a situation where FCP can’t track its own Undo History across multiple Sequences/Projects, or Property Inspect its own constructs like multi-layer-derived Freeze Frames.
Or share Project or asset files in a multi-user SAN situation.If project clip timecode data is derived from Start+offset, then any speed ramping or fundamentally altering the offset will be perpetually fraught until the QT format allows new meta-data to be locked into the altered instance.
Which needs to be an OS file-level property.That’s my through-a-glass-darkly perception of why these things are so hard to fix… 😉
-
Jeremy Garchow
September 14, 2007 at 12:04 amHey Paul, I like your style.
[PaulD] “And give OS X a robust file database that tracks media-file metadata (like timecode).
“Well, don’t you think they are taking a step in the right direction with allowing Quicktime to display timecode within the app these days or is that update merely a convenience that covers up the lack of this OS level database you speak of?
And through your looking glass, any chance of any the aforementioned OS database updates in Leopard?
-
Paul Dickin
September 14, 2007 at 12:15 amHi
It seems to me that when Fast(>Pinnacle>Avid Liquid) and Avid considered how to make their NLEs more robust they locked everything into inscrutable file structures that aren’t accessible at OS level, only through their application.Apple do things quite differently, creating new Studios of applications communicating only at OS level. So all the things Avid and Liquid have done to get the Tim Wilsons of this world enthused have to be done at OS level by Apple.
The Filemaker Pro community seems to be hopeful about Leopard finally allowing multi-user databases, so maybe there IS hope… 🙂
-
Jeremy Garchow
September 14, 2007 at 12:27 amThank you, Paul.
It’s nice to hear someone who actually thinks things can get better, rather than the gloom and doom of things like ‘our world’s going to hell in a hand basket, wanna buy a PC?’.
-
Paul Dickin
September 14, 2007 at 12:48 amHi
I’m ever the old hippy at heart 🙂
I escaped the Jesuit give me the child to the age of seven and I’ll give you the man influence, and likewise my age made me miss the give the child Windows from eight to fourteen and their ours for life M$ principle.
So I’ll stick with loving my Mac’s empowering essence, whatever… 😉 -
Tom Daigon
September 14, 2007 at 1:11 amWow, after this conversation I think I’ll just upgrade my Avid DS to HD and not even consider what I thought was an alternative.
-
Sean Oneil
September 14, 2007 at 1:12 am[walter biscardi] “Actually, that’s a User Pref, just turn that off and it goes back to cropping it like before. I found that FCP kept scaling my still images when I didn’t want it to. Now it leaves them alone like before.
“Yeah but I like that preference. That’s how FCP has always worked, and it’s very convinient. It also takes the guesswork when using the new multiformat feature (at least its supposed to). But it shouldn’t do it in this case. 486-480 isn’t meant to be scaled. Ever.
FCP 4-5 didn’t have this problem. It was aware of the concept. Remember the message “You are about to transcode between 486 and 480, do you want to perserve the proper frame size”?
-
Sean Oneil
September 14, 2007 at 1:15 am[PaulD] “That’s my through-a-glass-darkly perception of why these things are so hard to fix… 😉
“I’m not going to pretend to know how hard or easy it is to fix. But I will say with the utmost confidence that they have more than enough resources to make it happen – regardless of how hard it is.
That said, if they do feel it’s too hard to fix, then they have to accomodate that into the program. Like what I said before. Show a warning message before you try to MM something with speed changes.
Reply to this Discussion! Login or Sign Up