Forum Replies Created

Page 130 of 132
  • David Lawrence

    July 3, 2011 at 7:16 pm in reply to: the event browser

    [Andrew Richards] “True. Two-up only happens when using the Trim tool.”

    Hmmm, I’m not seeing it. Is there a preference somewhere I’m missing?

  • David Lawrence

    July 3, 2011 at 7:12 pm in reply to: the event browser

    [Andrew Richards] “No apology needed. This has become a non-linear conversation!”

    LOL!

  • David Lawrence

    July 3, 2011 at 7:11 pm in reply to: the event browser

    [Andrew Richards] “I agree the superfluous animations need an off switch. The chrome was design with a touch-based future in mind, methinks.”

    Yes! Just let us switch it off and things would immediately start feeling better. Agree about touch being a driver in this.

  • David Lawrence

    July 3, 2011 at 7:04 pm in reply to: the event browser

    [Andrew Richards] ” You still have access to a two-up viewer, but it is only active when you are manipulating an edit in the timeline.”

    Not really, You see two filmstrips in the timeline in that view, but it only monitors whatever side you’re trimming. There’s still no way to visually match.

    [Andrew Richards] “You can rightly argue that your way is akin to the old discipline necessary for an edit when the editor was physically cutting celluloid, but the flexibility of non-destructive non-linear editing permits an alternative method that Apple is clearly embracing. “

    I’d argue just the opposite. My way of working is totally non-linear and heavily multitask-oriented. I can’t think of anything germane to non-linear editing in removing the source monitor. It’s a design mistake, pure and simple. Let’s see how long it takes to come back. My guess is around the time multicam returns.

  • David Lawrence

    July 3, 2011 at 6:29 pm in reply to: the event browser

    [Aindreas Gallagher] “(and seriously why, when I delete a clip – does it do a dissolve off? Its better to delete than to fade away apple. Give us a stripped chrome option too. that should be a priority – like graphite in OSX – this thing needs not to be quite so GUI sluggish on recent hardware and anyway The GUI is just too much. there are bloody animations everywhere I look for gods sake. Just turn off the glows, the dissolves, and the bevels, you can hide the option in a preference we need to use a shift key to access.)”

    Spot on. Why does this modern application with all this horsepower feel more sluggish than FCP4 HD on OS9 on a PowerPC?

    Why when I arrow-key to next edit do I need to see the time indicator animate to the next edit? Why the chrome and curved corners on objects? Details like this give the application an overall feeling of sluggishness and imprecision.

    And keep in mind that all these details are intentional. Someone needed to write the code to make the time indictor do that animated swoosh. Who were they coding that for? The answer to that question tells you everything you need to know about Apple’s priorities and who this application is designed for.

  • David Lawrence

    July 3, 2011 at 6:16 pm in reply to: the event browser

    [Andrew Richards] “A two-up view is only functionally necessary when you are comparing two abutting clips, the out frame of the first and the in frame of the second. “

    This assumes you’ve already selected your source and have cut it into the timeline. But what if you’re looking for what source to use?

    For example, when I search for B-Roll, I always want to see what I’m cutting into AND what I’m cutting from at the same time. I can find the perfect cut point just by looking at both as I select from source. It’s incredibly efficient. There’s no way to do that now. The new layout is not an improvement.

  • David Lawrence

    July 3, 2011 at 5:58 pm in reply to: the event browser

    [Aindreas Gallagher] “there really should be one. getting rid of it is a mistake. It’s not something to get your head around, or find alternate methodology for. it’s a mistake.”

    Absolutely correct. One of many!

  • David Lawrence

    July 3, 2011 at 4:21 am in reply to: Magnetic timeline logic

    OK playing around with it I see that control clicking forces the entire clip to be selected. This is why it adds transitions to the head and tail of the clip.

    So to clarify – if you click a transition point — i.e. clip head or tail it stays selected and keeps focus so you can apply a transition. But if you right click or use a modifier key, the entire clip is always selected no matter what. How innovative.

  • David Lawrence

    July 3, 2011 at 3:04 am in reply to: Magnetic timeline logic

    I dunno. I have 25+ years experience as both a UI/UE designer and user. In GUI syntax, you always want consistent behavior based on the user’s expressed intention. So if I select the clip head and use a context menu to apply a transition, I don’t think it could be any more clear what my intention is — put a transition at the head of the clip. It’s not rocket science. Frankly, I’m pretty shocked at some of the UI mistakes in this program; stuff that feels wrong not because it’s been made easier, but because it feels like the designers didn’t know what they were doing or didn’t test this with real users.

  • David Lawrence

    July 2, 2011 at 11:54 pm in reply to: Magnetic timeline logic

    [Andriy Toloshnyy] “Is it me stuck in the grandpa’s editing edge and cannot understand the logic behind it?”

    I don’t think it’s you. I’m finding many UI inconsistencies that are frankly, either bugs or just poor design. Another example: Control-clicking puts a transition at both the head and tail of the clip, not at the transition point you selected. It makes no sense.

Page 130 of 132

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy