A software that treats timelines like a action with multiple outputs, one for each track.
Then you can pipe timeline tracks to different timelines and build a big relationship nodegraph.
Lets say you make a master timeline with graphics and subtitles for 10 different languages, then you can just pipe v1 (image) and v5(spanish) and A5 (spanish audio) to a new timeline, name it _spanish and off you go, need to swap a shot? easy. Its just like nested timelines but more visual, and more flexible as each track is its own nested thing.
Media should also be treated the same way, ea h timeline has media input with a pool/bin of media it should conform to, you get updated grades? just hook up the pipe to the new media bin.
Maybe I am crazy but we need better ways to handle this version nightmare, it keeps getting more, Nowadays its not just 1 9:16 but 5 because every platform has other safe margins.
No finishing software has solved this.
You can have this idea for free, I just want to be a beta tester
I would already be happy if we had that thing in the TL that used to be ( or still is ) in Lustre, where one could, on a per shot bases, highlight what layer the output should show. And when that’s there, give me multiple versions of that in the same TL and when I then export the TL, it’ll export all the versions of that TL at once.
I know you are suggesting something a lot more complex, but Assimilate Scratch has a simple version of what you are suggesting, a node based output engine.
I had a feature request years ago for Flame which would have worked a bit like the way IMF works, you would have a master timeline that you could build multiple timelines from. A bit like how you might have multiple language versions and a textless version within the one IMF delivery and you just select the appropriate CPL depending on what version you want to output.
Connected Conform isn’t the same as what I am suggesting either. There is definitely some crossover but I haven’t found a way of achieving the result I’m after.
hmm yea the output module in scratch is not it… same in mystica workflows… it just like different codecs and burnins and stuff, which is great but no good for dealing with 300+ Versions of a commercial
I wonder if a combination of connected conform with some kind of node based output engine would get you most of the way there?
To be honest, the thought of a node tree with 300 pathways on it actually sounds more complex and troublesome than having 300 timelines.
A scriptable output engine would make a look more sense for efficiency for this sort of thing. Where you could say have 4 versions of shot 003, 12 versions of shot 008 and 8 versions of shot 012. Then program the script to give you every combination of that. You’d need to have a lot more metadata tagging available though to be able to do this and a scriptable text module to be able to slate the whole thing properly.
I think export needs a whole lot of love. I wish you could queue a whole lot of exports to export in the foreground. For instance, I might have 3 versions of a 1 hour episodic show that I want to bake in a letterbox on the exports only. I don’t want to pretender that for each and every version.
Connected conform is OK but its not as flexible as what I dream of, so far the best is nested timelines, and nested clips, its not ideal but it seems to be the fastest way to do this with reconform from bins in resolve, I can fix most things that crop up during finishing/Versioning pretty quickly now.
This can also be done rather elegantly in Nuke with some python magic, just the editing part… really sucks but its doable thats how i did a 2000 version job, took like a week to build and prep the script but I was able to replace 1 clip/Graphic/Comp whatever and have it ripple through all the versions in a pinch, including a BUNCH of precomp nodes that would minimize rendertimes.
Included thousands of different legals and graphics in all the languages… it was ridicolous but that whole setup was pretty much what I want. Moslty created nuke scripts from master timelines in Nuke studio then copy pasted the scipt into the master render script so in the end I had 2000 write nodes for all the versions then just threw them all on the renderfarm and let it rip.
Back in the 2000s there was an ingenious piece of software called Traffic that was the beginnings of what you’re talking about…
It was a node based editorial package that essentially edited xml edits from fcp at the time, using nodes. One of the more interesting features to me at the time were the for each loops you could run to say automatically add a bin of tags to a certain edit at a specific time spitting out a new bin of edits.
It was clever, too clever, but a place I’ve wished Flame would go ever since. Conceptually owning the finishing space, Flame could easily push into those areas and really redefine the process and methods—still having the solid foundation in has in traditional editorial but expanding what tracks and layers mean, exposing the relational nature of everything we do and give us the tools we want to procedurally manipulate those relationships.
Sadly Traffic was short lived and I found nearly no info on it except a few articles at the time of release…
…and what we are talking about continues to remain on the periphery of what people are thinking about.
