Right, but in the UI you also get the drop-downs to select your version. If they had something similar to select which batch render goes into the connected segment….
Anyway, one can dream and I’m over my quota for feature requests 
All roads lead to openclips and unmanaged workflow…
1 Like
@cnoellert I’m rapidly coming to the same conclusion.
It’s the unifying structure of today’s multi-app workflows, it’s transparent and resilient, and it’s not a problem with today’s infrastructure.
In the current Flame implementation you are limited to sequential codecs like EXR though, correct? While versatile, I’ve always disliked them for their I/O overhead and unwieldy presence. And MXF containers for EXR are still in the distance.
They have their place for sure, but for some intermediate render, the simplicity of a stream container would be preferable.
Does that bother you? If the WriteFile node could support ProRes, would you prefer that?
Doesn’t bother me at all. For 90% of my work—commercials where color is delivering rec709 in ProRes—I would prefer it. I understand the puritanical origins of the no-container policy but as you said times have changed.
There was a time when you could only buy storage from Discreet and somehow we moved on from that.
1 Like
Not to beat a dead horse but even the notion of batchFX in an unmanaged workflow could be replaced by adhoc batch group and corresponding write-node/openclip creation. Select a segment on the timeline and rather than create BFX, you select promote to batch group and off you go. Maybe there isn’t a back node… oh well. What you gain is a multichannel write directly to the timeline.
If you extrapolate further than down that line of thinking a multi-channel is just a stack of timeline versions/tracks on top of each other which sounds like something I’d love to have access to in a timeline environment—even it their just presented as a contained segment.
If the software could just be a little more pipeline friendly—be open to being told where to put stuff in a user definable way a world of possibilities opens up.
1 Like
Funny you should say that. After reading your earlier post this morning, I made a test project and created a few batch groups and replaced the render node with write nodes to test the versioning. All works seamless.
Except, writenodes/openclip doesn’t seem to mesh well with connected conform workflows, since they largely depend on renders, not openclips. There’s no way of having the back node be a a combo of write node + openclip.
I was able to jerry rig this, by creating the batch groups without adding new segments to the timeline, replace render with write node + open clip, bring the openclip in on top of the original in the timeline, start a fresh segment connection and then copy that to other timelines. Works as expected. If you change versions in one segment it updates everywhere else.
But seems you still lose some of the magic of connected conform workflows. Enough to make it work, but not as slick. Could be fixed by having connected conform work with unmanaged storage.
Still sorting through it. Might have missed a detail.
PS: and from there it wouldn’t be far to modify the open clip with an alternate path, so you could roundtrip through Nuke or other app if you wanted. Have the write node generate the export, and the openclip read the return render instead of the original export and batch is just a container in that case (or layered workflow). Yet, keep that all within the nice workflows of connected conform. Of course already possible through manual intervention, but not baked in at scale.
It does.
…if you create that shot sequence from your open sequences, pub that with those sequences open, you get a new track with the openclips referenced and connected. Sorry if my link didn’t make that so clear. I was covering a lot of ground.
Ah yes, that’s a good and comprehensive setup. I’ll have to experiment with that further. A lot of ground to cover there for certain.
In the meantime, a simpler adaptation for the lack of openclip back-clip is this:
Simply put the openclip right before your standard back clip.
Not as transparent has having openclips on the timeline - your versioning is inside the batch group, and you need to re-cache the batch render if you change versions.
But you get all the benefits of unmanaged storage and versioning, while remaining with established connected conform workflows. The managed storage is merely a pass-through cache.
Long-term your setup is probably better, but this is a faster adaption of workflow in the meantime.
Also rewatching the fxphd course on workflow for some of those tidbits that I didn’t catch when I watched it a while ago. Making sure my understanding of all of this is more solid.