Newb OpenClip question for you all. I accidentally created a new version (02) for a clip that I meant to write over with a fix (01). Is there any way to edit the version structure to delete v02 since I don’t want to keep them both? Or am I kind of stuck with a v02 now?
Oh, and a bouns question - is there an easy way to see what versions are currently available for a clip while in Batch - preferably from the Write node? I know I can find the OpenClip in the desktop and interrogate it, but this seems less than ideal.
If you look in the Logik Portal there is a script to delete OpenClip versions. After installing, you need to be in the MediaHub, right click on the clip and select ‘delete versions’ from the menu. You have two options - either select a specific version, or delete all but the current version. You can never delete the current version though.
This updates the XML the remove the version(s) and also deletes the .exr sequence from the disk.
Alternatively you can also just do it by hand, edit the XML file to remove the version you didn’t like. There are two places in the file you need to edit.
Lastly, you can just overwrite version 1, remember that 2 is bogus, and then overwrite 2 at some future point.
@allklier Thanks for pointing out the script. I will give that a try for sure.
I guess I was hoping there would be more robust Version tracking in Batch / the Write Node. As of now it’s a bit rough how you keep track of existing versions.
I know a specific write node isn’t married to a specific open clip, but it would be extremely helpful if when you’re pointing to a current open clip path and are working with versions you could see the versions that already exist and edit/modify names, delete versions etc from that Write Node.
To take it a step further, being able to open a version based on it’s history in Batch, make a change to that version and resave, etc would all help Open Clip/Versioning to be more user friendly and more robust/powerful.
If a feature request does not exist I’ll file one and add it here in case anyone has any interest in seeing some of these features introduced.
This is possible in batch.
Select an openclip.
Go to the ‘Extended’ menu.
Choose the version of the openclip that you wish to modify.
Append to the batch.
Modify the nodes for the desired outcome.
Render the write file node again, overwriting the previous version.
This also has the potential to break the openclip xml.
That script mainly exists so you can declutter old versions that are no longer in use.
There is one option - you can tie versions to the batch iteration, instead of having independent versions. And that gives you what you describe as matter of batch iterations, where you can go back to older versions, look at them, and even re-render them. Look at the version setup in the write node. There’s an option to make these two versioning features be linked.
Thanks to you both for the recommendations. I will explore them both again, but as @philm mentioned I found that both had a tendency to break the open clip when I tried messing with them.
In the end though this all seems like workarounds for the fact that the versioning system is a bit of a Wild West… the fact that I can’t easily see a little table of all my existing versions for an open clip and I have to start digging around to view past versions, what they’re labeled, what number is the next free version, etc is a missed opportunity to make this system more functional and user friendly.
MediaHub seems to have a nice version tab with some good info. Would be great to just have access to this in Batch/Write Node with additional options to edit/delete/rename/open, etc…
@philm Thanks for the suggestions and I really appreciate you taking the time to help try to figure a better solution out. I tried versions to iterations when I first dipped my toe in to open clip but that does not necessarily fit into how we work and it wind up breaking the open clip in certain instances. Of course I can alter that workflow (and will most likely wind up doing so), but in the long run I don’t think it addresses the fact that additional tools to handle and monitor versions would make them much easier to track and implement how you need to.
For example, right now it’s very easy to accidentally create a version (that can easily create confusion), and it’s not very easy/impossible to remove that version. Yesterday I accidentally forgot to change my version back to 01 and created a revision at 02 with the same name. Granted I just told the other artist that v02 was the correct one to use, but now there’s an incorrect v01 that I don’t need, that could be mistaken as the correct version, with a name I can’t change (that’s the same as v01) and it’s taking up space that’s not needed on my storage.
I agree, but I honestly think the versioning system as is is lacking in tools that would make it a lot easier to use for those of us who are forced to implement it in our own ways.
It’s a wonderful system with lots of great potential. I think some additional functionality could help more of us tap that potential.
If anyone is interested, the Improvement is FI-03404
As always @philm thanks for sharing your wisdom and thank you for your continued commitment to lending us all a hand.