I think I’m not understanding. When I say name I’m referring to the nodename in the schematic… the name that is displayed directly to the right of the timebar with the text node before it. The segment name updates in the schematic with the version name though when you change it.
Is that what you’re talking about? That’s the same behavior for me in batch as it is in the timeline. Or am I misunderstanding something?
Here’s batch->
…and here’s the timeline->
this is what I don’t understand and why it can’t take name>_v<iteration###> as the name if you export that clip you will just end up with a file named gr_010 the iteration doesn’t follow but is somewhat hidden under the clip, shouldn’t the name be dynamic as well?
Ok, now I understand—sorry for being dense. Guess the logic is that the openclip has its own name and that name is what Flame is referencing–it’s not the Nuke version-syntax where the actual source being read from disk is changing directly in the app. An openclip is a static file being referenced whose content is dynamic.
At minimum it seems like there should be an update to the match function that would pull the actual source out through the openclip instead of just the openclip itself. It’s a glaring omission…
I could argue the entirety of open clip needs to be simplified , this coming from someone who regularly rolls and builds these systems but if ask the average flame artist what is the different between rename and rename shot and what each aspect of those operations hold I bet 90% of the artists wouldn’t have an idea, then applying those characteristics to open clip you get maybe 5%
Exactly.
My other issue is when re-imported an openclip will set the name what’s defined in the XML under the <name> field which is always going to the <shot name>. So while in your case you get a lovely gv_0010 as your shot name is such, the way we work we’d only get 0010 as we seperate shot name from film name (in Nim speak). I’d personally like to option for the name to follow the name of the openClip file as opposed to what’s defined in the XML.
this is exactly my hangup I don’t get why name can’t be dynamic it makes it so difficult, and why do they need two naming conventions for shots seem way to complicated, could one just be called group shots and the other shot name seems or something like that
Done!
Something I’ve just noticed is the way Flame interprets the name of the openClip is different in all 3 cases:
-Desktop (i.e. MediaHub): Only uses whatever <name> is as the clip name.
-Batch, Import: Uses filename with version indicator
-Batch, ReadFile: Uses the full name of the target file, but seems to lock on a version. In this case the version active was v003 but it’s displaying v002.
On that note, I’ve made a feature request to be able to define what goes into the <name> field so we can decide regardless of workflow. FI-03159.
FWIW I don’t sweat what the openClip segment is named. I always have a burn metadata tool show me the info in timeline or batch. New metadata tool shoul work similar id bet.
Seems like situation above w read file limitation makes sense since it’s the result that the xml pointer needs to read?
Import and read having diff strengths can be a helpful option. Similar to action w import/read of geo etc.
Just my 2 cents.
I’d argue that the software should behave the way regardless of how the clip is brought into the system. It used to. I feel like the behavior has changed recently…but maybe it’s all in my head.
All good man. We all work differently.
The same clip can be viewed in conform, timeline, image or batch and that context changes its capabilities. To me that’s a strength but understand your point.
One man’s feature is another’s software bug.
Indeed, all good. One thing to point out, however, is in the screenshot the readfile node is looking at v003, not v002 but the display name is v002. So that, I’d say, is a bug.
Just for shits and giggles I just did the same on my end. I get the following →
The read node is the only one that doesn’t give me any version info in the display which is an inconsistency. Otherwise it seems to be behaving for my particular pub template. I don’t know why you get the results you’re getting but I can imagine that shit would be infuriating.
Really? Well that makes it even more annoying, haha. Is it safe to assume your <shot name> is gv_010?
Regarding the ReadFile, I don’t recall there being any options for .clip files in terms of name, etc. so unsure where how I’m seeing the full name and you’re not.
I’d be curious to see what your publish template looks like if you’re willing to share.
Insanely annoying I’d say—gv_010 is indeed my shot name. The clip name options are all greyed out for open clips so I’m getting whatever Flame gives me. Is your pattern browsing on by any chance?
Here’s a copy of our Shotgrid DPX template →
FlameSG_10bit_Dpx_Sequence_Publish.xml (2.5 KB)
…ironically based on my old NIM template lol.
Would it be a completely terrible idea to script something where you could right click on an open clip and say convert to mov? Then the script would look for all the s Import Image Sequences, Export movs, and then change every “.[####–####).ext” to “.mov”? I did a manual test on an open clip with one mov and it worked fine, but I have a feeling it’s not a good idea.
I’ll let others chime in but if you created a movie from an openClip do you want all published versions or only most recent?
Might be easier ways to get what you want.
I think a better script would be an import generated from the currently selected version of an openclip.
Think match function that respects version referenced in an openclip and not the openclip itself.
Thanks Guys!
If you two don’t think it’s crazy, I might look into it.
The Read File node is in deprecation mode so please use the Import Node instead.
