Ok I spent half the day trying to get something that actually would work for us from a user standpoint and I found some stuff that sort of worked… and stuff that didn’t at all work… but I finally figured out how I think I draft can be setup to be both usable for studios which don’t have a brimming team of eager young computer scientists and those who do. The latter is obviously easier to solve since they can just make Python do their bidding exactly how they want. The larger trick is getting it to work at more organic and less mechanical pipelines like our own where rigid expectations and automatic everything is the exception not the rule.
Here is my concept of how a Draft Package works: a draft template is a collection of modules and default settings. Modules are developed both by Thinkbox and by individual studios. This is akin to the “cookbook” system that you’re already working on, but less techy and more flexible from a user standpoint. I can take the cookbook and make something useful for my fellow artists. Most of my fellow artists don’t even know how to open a python script let alone edit it. So if I make them a 720p H264 with slate draft script they can’t make themselves a 720p h264 without slate. Or if I make them one with a thumbnail output or a filmstrip they can’t do anything with that either. So what I need is a system that lets me give them presets that they can use, but also the capabilities to tweak those presets.
Another challenge I saw with a system is how do you get the information the user needs but eliminate redundancy. From a user standpoint there are two components to this idea: 1) Output Modules 2) User Settings.
Let’s define a couple Output Modules:
“Movie”
“Thumbnail”
“Contact Sheet”
“XML”
“Source Scene”
“Shotgun Version”
Now each of these Output modules represents a Draft Module. But each of these output modules have needs (don’t we all).
Movie (inFile , getSlateFromSG , outFile , userName , projectName , versionName ) [ Codec , outResolution , bitrate slate , guidesRatio, outputpath , resizeSource <int (1:none,2:stretch etc…) ]
Thumbnail (inFile ) [outResolution , sourceFrame ]
Contact Sheet (inFile ) [numFrames , rows , scale ]
XML (inFile , getSlateFromSG username , projectName , versionName )
Source Scene (inFile )
Shotgun Version (inFile , versionentityID <string, sg_Browser.py>)
Some of these needs overlap with one another. They all need an inFile so that can be consolidated. But some of these aren’t consolidatable, some of them are actual module settings, for example each instance of the Movie Module might have unique guides. For instance the Movie Module has a “Slate” checkbox it’s wanting to know about.
Now to add one final level of complexity each of these modules can be saved out as a module preset equal in stature to the source module “movie”. For instance if I’m an artist I can add a movie module to my Draft Package. Set its output height to 720p and the codec drop-down to h264 and the bitrate to 10,000 and save that then as “Vimeo 720p”. Now they can in the future add “Vimeo 720p” to their list of output plugins.
Now for the consolidation. Both the XML and the Movie file output modules need the “projectName” field. So at the top of the output list you have one single “projectName” flag. And it dynamically removes redundancy. That way the artist is presented with a single list of the information the current batch operation can accept. And some paths could be configurable for different scenarios. For instance the “inFile” field could be hidden in the context of a deadline submission window since it will pull that from the job info. Some modules might need special info and call a separate python process to get it that info. Not entirely clear yet on that last bit how to handle those sorts of situations. Needs more thought, but those are the rarer instances.
And of course you can save this set of Output modules/presets as a “Package”. So if I have an 720p h264 and a proRes with a slate I can call this a “Client Deliverables”. Maybe I just need an unslated ProRes in the input resolution then I setup a “ProRes Movie” module, customize it so that the resize flag is false and leave the slate unchecked. Don’t fill in any of the “Project Name” etc and it can do a quick sanity check maybe for each module that gives an error, or has some logic so that each output module has its own settings intelligence/sanity checking before submission. And then remember I also need a web version to send to a client with a slate so I add a “client review h264” preset (which is a customized “movie” module). So I have two outputs, one customized and one just an existing preset. And I hit Submit.
Now is where the real magic happens behind the scenes. All of the modules get packaged up into groups. In the last scenario we have one module but two presets. But presets are just instances of a module with specific default settings. So both the ProRes and the Slated h264 get passed to the same module as two “Actions” which is to say a collection of flags.
Deadline (ProRes, Slated H264) -> MovieModule.py
So into the Movie Module we get a list of lists.
[[infile = “blah blah blah”, outFile = “blah blah blah”, codec=“h264”, Project=NULL, etc],[infile = “blah blah blah”, outFile = “blah blah blah”, codec=“ProRes”, Project=NULL, etc]]
Now it’s completely up to the MovieModule.py to deal with this data. If you are a good developer (which of course we all are) we will come up with an algorith that efficiently only loads the source images once and only slates all of the outputs which need to be slated once etc etc… But you could just brute force do one after the other. I assume the default Thinkbox modules would be pretty clever and intelligently decide how to process a bunch of outputs for instance.
“For o in ActionList where FastStart==True do (Draft.QTFastSTart(o[‘outFile’],o[‘outFile’]))”
So that’s an example of existing Draft syntax working perfectly but with multiple video output requests. But it’s ultimately 100% customizeable this whole paradigm shift doesn’t reduce flexibility it simply presents a more artist friendly way by default to present the capabilities of Draft, and as a Developer suggests a more flexible design to your Draft scripts than they would probably think to do on their own. I mean, one way or another this is how all of my draft scripts are going to be setup, I’m going to abstract all of this out so that it supports this workflow even if the UI is hardcoded for all possible scenarios. It just makes it much more flexible to make it more objecty.
For o in ActionList where o.guides == TRUE do (SF.AddGuides(frame)) else (frame)
But this will save me having to create 100,000 different draft templates for slightly different situations when really I should just write a general purpose “Movie maker” draft script that can be called in different fashions for different situations, and most importantly called multiple times for the same submission so that I don’t have to create an infinite number of draft scripts for the infinite number of draft combinations of deliverables. It also empowers the users to create their own custom draft scripts without touching any code while hiding the complexity from them if they don’t need the distraction.
