openClip woes

Flame Flame Questions
1

I know we have quite a few threads about openClips but I wasn’t sure where to include this one, so apologies for yet another one.

We’ve been a long time managed media shop but we’re coming around to an unmanaged workflow. The pieces have been in place for a while but now we’re kicking the tires on a massive project.

One thing that is hanging us up is the loss of tape name from the openClip as well as the inability to match-out the underlying version from the openClip container.

I’d say 95% of the time we work ungraded and then send our conform/comps to grade along with an EDL/AAF. This allows us to keep our shot names, etc. Works a treat, even when the client wants to grade with another supplier.

Currently, this workflow isn’t as viable for shots that are being populated by an openClip. The write node doesn’t include the tape name nor does Flame put it into the openClip file via said node. There’s also no option to have Flame look at the underlying file to derive the tape name. Finally, when you match out the clip from a timeline it doesn’t actually match out the underlying source version that one could then export to grade, it’s just the openClip container (which has a use as well)

Am I missing something? Sometimes I feel like we just work quite differently than others, especially with how we use <shot name> which also complicates matters with publishing and openClips being created in that manner (as opposed to the write node creating the first version of a .clip)

I feel like this could be solved by a few changes:

  1. Have the option to match out the source version (i.e. what the openClip is actually pointing to)
  2. Have the option to get the tape name from the actual source version file
  3. Add the tape name field to the write node
  4. Allow the <segment name> token to be used when populating the name pattern in the openClip section of the sequence publish export menu. (This one isn’t related to the above issue but it messes other things up for us)

By the way, I realize we could alter the tape name to be the file name but I want to keep the original tape name. We get revised edits all the time or new edits towards the end of a project so it’s vital for us to keep this.

I hope I’m just missing something and someone can tell me to just click a button or I’m overlooking something obvious…

2

And we’ve been promised Pattern Browsed Published for years, which would solve many issues.
@Slabrie

3

@kyleobley : please make sure all these are logged on Flame Feedback and reference the current thread in your request.
@ALan: we sadly got distracted by other priorities (some of which were related to some of your other challenges) and our initial investigation for this request was showing other issues which we have not yet found a solution for. Note that this would solve most of Kyle’s issues but would be good for other workflows.

5

This is manually setting the tape name. My issues are with the existing sequence publish workflow as well as the write note and openClip implementation.

6

Careful what you ask for @Slabrie

FI-3223 Add <segment name> token to Sequence Publish Clip Output

FI-3224 Write Node to have have tape name field

FI-3225 Option to match our source of openClip to desktop

FI-3226 Option for tape name of openClip to be inherited from source file

1 Like
7

Thanks a lot!

8

Hi @Slabrie

Could you expand on what these issues are. I’m not clear on that, and maybe if I was, then I wouldn’t harass this issue as much.

9

The Open Clip stores current version and Batch Setup references, which is not the case with Pattern Browsing content. These might not be used in your workflow but we need to ensure that multiple workflows are not negatively impacted when changing that kind of thing.

10

Thats the thing though. No need to remove OpenClip, just add Pattern Browsed Publish as an option, even with the Batch Group limitation. Let us choose. Shouldn’t the timeline internal metadata be able to store the Current Version?

11

The idea is not to remove anything but add to the current workflows and let you choose which capabilities you want to use in your workflow. But this creates multiple workflow forks and we need to ensure all these options would work in the various workflows we do support. A great fun thing until you find issues :wink:

12

I’d be interested in the over/under odds of which one of us retires first before this functionality is added.

13

The text module rewrite will come first!:rofl:

2 Likes
14

Challenge accepted :wink:

2 Likes