Activity › Forums › Creative Community Conversations › Editing scenario
-
Jeremy Garchow
May 22, 2012 at 6:49 pm[Walter Soyka] “Is there a difference?”
There is today, an I think that’s Philip H’s point.
Everything is associated to that clip. It’s how it works, at least for now. Favorites are simply a “sort” or an alternate display of data assigned to that clip.
An in/out range is no different. So, if X could remember piops on every single instance of one clip, in order to keep track of all this info on the near infinite combinations of data “sorts”, it seems that FCPX would have to create some sort of io category, and then constantly track all those changes and update them.
Maybe that sort of thing is possible, but is it really necessary?
-
Walter Soyka
May 22, 2012 at 7:11 pm[Jeremy Garchow] “There is today, an I think that’s Philip H’s point. Everything is associated to that clip. It’s how it works, at least for now. Favorites are simply a “sort” or an alternate display of data assigned to that clip. “
But — the interface can present those alternate displays of data as if they WERE clips, even though it may not represent them as clips internally. This can create a problem any time you might want to consider a clip as an instance of a specific range of content (from a UX perspective), as we see here.
Although your “everything is associated to that clip” line may explain why favorites can’t overlap. You’d have to show either a partial range (which would be false and misleading), you’d have to show the entire range (which would erroneously extend the current favorite), you’d have to not show the range at all (which breaks the association back to the clip), or you’d have to come up with a new way to indicate that the other range is incomplete (which could be too confusing or complicated).
[Jeremy Garchow] “An in/out range is no different. So, if X could remember piops on every single instance of one clip, in order to keep track of all this info on the near infinite combinations of data “sorts”, it seems that FCPX would have to create some sort of io category, and then constantly track all those changes and update them. Maybe that sort of thing is possible, but is it really necessary?”
Is it necessary? Of course not. It’s a feature request. Developers ignore them all the time.
My version of the question is this: is the app better or worse without PIOPs? If users really want them, will it hurt the application to include them? Was it a good idea to design the app so it couldn’t have them in the first place?
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
Jeremy Garchow
May 22, 2012 at 7:47 pm[Walter Soyka] “But — the interface can present those alternate displays of data as if they WERE clips, even though it may not represent them as clips internally. This can create a problem any time you might want to consider a clip as an instance of a specific range of content (from a UX perspective), as we see here.”
I think we are losing focus here.
There’s a clip in FCPX. On that clip, everything happens.
FCPX does not treat alternate displays as new clips, everything always “attaches” to that one clip.
So, in that picture that I sent earlier, even though you see 5 instances, the data assigned to any instance, is universal to that clip. If I added a marker to what looks to be the 5th “clip” in favorites view, I could assemble the 4th clip on to the timeline, and if I extended that clip long enough, that marker would also show up in the timeline, even though I added the information what looks like the “5th” clip. If I unfavorite one of those clips, that range disappears from the master clip, not just that one favorite.
So now, if you want piops, let’s say I set a range on the 5th instance, I set a range on the 4th instance, I set a range on the 3rd instance, and since FCPX now remembers everything, I sort to “all clips”.
This means I now am viewing the master clip. This means that I will now have three ranges on that one clip. I select a range on the master clip that happens to fit in to one of the favorites. Does this create a new range, or does it add to the ranges that already exist? Let’s say it creates a new range.
I now want to sort back to favorites, so I do.
Now, the range I just made on the master is replaced with the range I made when I was sorted by favorites not a moment ago.
See what I mean? Why do we need all of this? Why not simply hold on to the ranges you want to with some favorites or keywords that will stick with you as you intended instead of X trying to guess what you want all of the time?
[Walter Soyka] “My version of the question is this: is the app better or worse without PIOPs? If users really want them, will it hurt the application to include them? Was it a good idea to design the app so it couldn’t have them in the first place?
“Again? I’ll get guff for this but:
It DOES have them, but it works differently. It works differently as it has to.
The whole application works differently than FCP7.
It is up to an individual to see if it’s better or worse.
-
Walter Soyka
May 22, 2012 at 8:14 pm[Jeremy Garchow] “I think we are losing focus here. There’s a clip in FCPX. On that clip, everything happens. FCPX does not treat alternate displays as new clips, everything always “attaches” to that one clip.”
On the contrary, I think this is the crux of the PIOP argument.
People are expecting FCPX’s clips (and clippish objects like favorites) to work like clips in other applications. They do not. They are not clips in the same sense as traditional apps. They are windows into the One True Media. They are not discrete entities of their own.
[Jeremy Garchow] “Why do we need all of this? Why not simply hold on to the ranges you want to with some favorites or keywords that will stick with you as you intended instead of X trying to guess what you want all of the time?”
We don’t need it. Some people want it, because now retaining a range that you marked requires one more step than it used to.
Marking IOPs used to be an action that created metadata. Now the same actions that used to mark points simply define a selection, and the metadata must be created in a separate step.
FCPX wouldn’t have to guess. It would have to store the PIOPs where the user put them, because PIOPs are a property of clips, not media.
[Jeremy Garchow] “It DOES have them, but it works differently.”
It doesn’t have them. FCP had PIOPs, FCPX had favorites. They work differently because they are different — but they can be used to serve the same function.
I think the trouble comes from being different enough that traditional methodologies don’t work, but being similar enough to the old metaphors to make users feel like they might.
[Jeremy Garchow] “It works differently as it has to.”
It works differently as it is designed to. This behavior is a side effect of Apple’s design decisions. It could be different than it is.
I can get by without classic-style PIOPs. I can embrace the F key (and its comedic companion, the U key). Doesn’t mean my blood pressure didn’t spike every time I relied on muscle-memory and clicked away without pressing F first.
My personal issue with the lack of PIOPs is not that I can’t use favorites — it’s that I don’t think the NLE should destroy user information (which was potentially time-consuming to create) so hastily.
Maybe this wouldn’t be such a big deal if resetting a clip’s range were added to the Undo stack, so those errant focus-changing and range-resetting clicks could be undone and the prior range immediately restored?
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
Walter Soyka
May 22, 2012 at 8:22 pmAnd Jeremy — thank you for continuing this discussion with me so long. I have never thought about the why behind the how so deeply.
Please understand that I do agree with you that the problem is pretty much solved with FCPX, speaking functionally and possibly excluding the overlapping favorite issue.
My objection is not that FCPX can’t remember a range; it’s that it has demoted the traditional process of marking points down to making a selection, making important editorial metadata very fragile.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
Jeremy Garchow
May 22, 2012 at 9:28 pm[Walter Soyka] “People are expecting FCPX’s clips (and clippish objects like favorites) to work like clips in other applications. They do not. They are not clips in the same sense as traditional apps. They are windows into the One True Media. They are not discrete entities of their own.”
Yep. And that’s why PIOPs as they are now in FCPX, and as Philip hints to in that blog post, simply work differently. If you want them, they are there, but they are now a tool of intent, and a different intent than FCP7. It’s one more keystroke. It’s all it is.
If people don’t like the way that works, great, but they are there, and if you ask me, they are more persistent than before.
[Walter Soyka] “FCPX wouldn’t have to guess. It would have to store the PIOPs where the user put them, because PIOPs are a property of clips, not media.”
But, if you follow my previous post, you can see where it simply is not an “easy” task. So, the way that FCPX works now (or iMovie Pro, whatever the kids are calling it these days) is actually the way it is supposed to work, not an engineering foul up, which has what has been alluded to. It’s not that easy to say “OK. Today, Me Apple Engineer is going to add PIOPs to every single instance of a clip in FCPX ad inifinitum.” It would cause more problems with them, then without them, especially from a programming standpoint.
[Walter Soyka] “It works differently as it is designed to. This behavior is a side effect of Apple’s design decisions. It could be different than it is.”
Well, no shit. The whole entire application could be different than it is, but it’s not. When you learn WHY they aren’t in there, it might start to make more sense.
If for some reason, that bothers an editor as to why they were designed to work differently, then X will simply never work for you. Ever.
[Walter Soyka] “My personal issue with the lack of PIOPs is not that I can’t use favorites — it’s that I don’t think the NLE should destroy user information (which was potentially time-consuming to create) so hastily.”
It is hear we just see things very differently. I see favorites as adding useful information with intent, other people see them as simply unnecessary. Having FCP7 holding on to an i/o range was also a tool of intent. In FCPX, that concept simply works differently. To each their own. Adapt to the new keystroke or not.
Jeremy
-
Walter Soyka
May 22, 2012 at 10:10 pm[Jeremy Garchow] “It’s one more keystroke. It’s all it is.”
Funny how many keystrokes here that one keystroke can inspire.
[Jeremy Garchow] “But, if you follow my previous post, you can see where it simply is not an “easy” task. So, the way that FCPX works now (or iMovie Pro, whatever the kids are calling it these days) is actually the way it is supposed to work, not an engineering foul up, which has what has been alluded to. It’s not that easy to say “OK. Today, Me Apple Engineer is going to add PIOPs to every single instance of a clip in FCPX ad inifinitum.” It would cause more problems with them, then without them, especially from a programming standpoint.”
I totally understand that PIOPs could be ponderously difficult to implement. But that’s a developer problem, not a user problem.
[Jeremy Garchow] “When you learn WHY they aren’t in there, it might start to make more sense.”
Agreed. I get why they’re not in there. The favorites implementation does make sense. That’s separate from the value judgment of whether the design is beneficial to the user or not, or to what degree it might be improved.
[Jeremy Garchow] “It is hear we just see things very differently. I see favorites as adding useful information with intent, other people see them as simply unnecessary. Having FCP7 holding on to an i/o range was also a tool of intent. In FCPX, that concept simply works differently. To each their own. Adapt to the new keystroke or not.”
I agree that favorites are useful, and a really good fit for the FCPX methodology. We shouldn’t lose favorites in order to gain traditional PIOPs. You are right to point out that favorites cover it.
I doubt that the traditional PIOP vs. favorite thing is going to be the issue that stops adoption. I am ok with learning how new applications work and changing my mental model and muscle memory accordingly. I am constantly doing this on the playout side, and I can do it in editorial, too.
Really, the more I think about it, popping browser clip selection onto the undo stack could eliminate (totally made up number) 90% of PIOP/favorite-related expletives without requiring rethinking the entire data model.
I will fight no more.
Unless this comes up again next week.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
Jeremy Garchow
June 5, 2012 at 11:51 pm[Jeremy Garchow] “I’ll try and do an Apples to Apples bloat test.”
I finally had a minute.
Here’s the Project. :30 spot, 143 “items” listed in the Index:
Project Size = 14.2 MBs:
Compounded, and cut in to 20 pieces:
Project Size = 114.2 MBs:
This is OS 10.7.4, FCP 10.0.4
Jeremy
-
David Lawrence
June 6, 2012 at 7:21 amJeremy, thanks for testing. Yes, these are definitely better results. I tested again with simpler sequences on three systems – 10.6.8, 10.7.3 and just now with 10.7.4. Looks like it’s 10.7.4 that’s making the difference. On the 10.7.4 machine, I get similiar results as yours. I still think it’s a problem but it’s definitely improved. Thanks again.
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl -
Alban Egger
July 22, 2012 at 8:16 am[Aindreas Gallagher] “FCPX is a souped up iMovie. It is, by definition, and the fact that it is trying to empower consumer hobbyists to step it up a gear by employing near identical methodologies to their free consumer video product, a prosumer solution. it is trying to lead consumers into more powerful capabilities, while still offering them the simplified hand holding amateur software environment they are used to.”
Haha….you are funny….I am sure the same was said by “pros” when the NLEs came out on Amigas and Pentium2 computers that were suddenly affordable. Or when we started shooting broadcasts with DV-cameras…..the shockwaves in the industry can still be heard…and amplified recently with the DSLR revolution. A lot of people who started on miniDV are now on F3s and C300s and REDs. All the power to the people, if you ask me. So if someone comes from iMovie fine.
I have tried iMovie once with my son. It is unusable for me and VERY far from anything any NLE does. It has events, yes. But so does any other NLE, only they call it Project library or something else.
The difference is how you fill these bins and how this helps you in the end to make better editing decisions. Had Apple called it Project Library and the Project Library Timeline Library would that make you happier? Hanging on these semantics is a bit childish if you ask me and most of your complaints about FCPX are matters of taste. If you tried it and don´t like it and have nothing constructive to add why do you come back to an FCPX forum? I mean I tried AVID, didn´t like it and don´t hang out over there bashing their tool. It works for them. Fine.
Reply to this Discussion! Login or Sign Up



