Adobe changed the folder structure for the presets files, again, which is a huge pain in the ass when migrating to a newer version of Premiere Pro, etc. Especially when the presets are not carried on automatically (as they should!)
Navigate to your current presets folder and copy all the presets you’ve got there into your clipboard.
Then navigate to this folder:C:\Users\<username>\Documents\Adobe\Adobe Media Encoder\11.0\Presets and paste them there.
Done, now your presets will show up in Premiere Pro CC 2017 as well as in Media Encoder CC 2017.
As a pipeline TD you might need to setup task status auto updates in Shotgun. It isn’t as simple as it may sound, because Shotgun, out of the box, doesn’t provide this functionality. However, it can be done with Shotgun Event Daemon and some scripting.
So, first off, a bit of background. As a pipeline guy, automation is essential. You need processes to work automatically, ideally in context and further more in a certain order. That happens all the time. Shotgun, and many other tools, provides a great backend for such automation, however, Shotgun itself doesn’t provide too much automation for its own tasks, versioning, events in general.
Luckily for us there is a large community of TDs working on such tools that can save us a ton of time and effort. (more…)
Since february this year my studio pipeline went 100% virtual. Due to several reasons I had to get rid of my physical, dedicated render farm, disk station, rack, pretty much the entire server room, and moved to cloud computing.
It goes without saying that it wasn’t as simple and straight forward as I had hoped. Setting up everything took several days (mostly trial/error), but in the end, I moved my entire license server, render farm, Deadline etc. to Amazon’s cloud computing platform.
I picked Amazon for no particular reason. I just had the most experience with it and didn’t really look elsewhere. The setup is so complicated that I didn’t want to invest any more time and money into setting up Azure or Google cloud. The only reason would, potentially, be the cost. Because, let me tell you, virtual computing isn’t exactly cheap.
I’ll discuss my setup, my experience and my reasoning for going to the cloud in my later posts.
I’ve done quite lot of work with teams using Shotgun, the production tracker, and I’d like to share some of my experiences, tips, tricks and how-tos in context of a Technical Director gluing everything together in a pipeline full of various tools using mainly Python and also MAXScript.
I hope to keep this section of my blog alive as much as possible, so, please, stay tuned.
Ever needed to select a specific frame range of rendered files on your hard drive (say, only frames 280 through 455)?
I do, all the time. It’s not a problem for a single sequence of, say, only the BEAUTY renders. But what if you have a ton of AOVs (render elements) on your disk and you need to select the same frame range for copying/renaming/moving/deleting/etc…? That can be a real pain in the ass.
Luckily we have Total Commander.
If you invoke the quick select (expand selection) window (by the way, this tool will ADD to your selection, which is also handy), you can utilize Regular Expressions. This expression will select only those files within (including) the range of 280 – 455:
It's really that simple and I think you get the logic. You can expand this technique to any kind of sequence of any length. Works every time.
Have you seen this error while trying to export your project to a QuickTime movie?
Here’s a simple tip how to continue using this piece of shit of software on higher-end machines:
- Simply open up the Task Manager
- Search for the Adobe Premiere Pro process
- Change its affinity in a way that you disable a few CPU cores for the process
That’s it. Premiere will, suddenly, magically, allow for QuickTime exports.
I hate this software so much…
As a followup to my previous post about the new licensing scheme in Nuke 9.0 and up, here’s another, little tip that might help you speed up Nuke launch times:
Watch for the port you’re looking for the licenses on. I know this sounds obvious, but I just recently had to restart my license server after a long time and suddenly Nuke started booting up very slowly. Not as slow as before (as discussed in the previous article), but noticeably slower.
After some investigative work on the server (read: I had no idea what was going on) I launched the FTL tool and ran diagnostics. Everything seemed OK at first, but then I noticed the service was running on a different port than what I had it setup in my environment variables.
After adjusting for this error, all runs as smooth as butter now once again.
So, just a heads up, keep an eye on the port you’re asking for the license on, it will find the license eventually, but it’ll take a lot longer than if you explicitly set the correct port number up.
If you’ve upgraded to Nuke 9.0 or even Nuke Studio, like I did, recently, you might’ve bumped into some licensing and boot-up issues with Nuke. So, allow me to share my experience with this upgrade.
First off, Nuke 9.0 is just fabulous. I’m really in love with the software, even though there are a few issues I’m having from time to time. So, after upgrading to NukeX and Nuke Studio 9.0 I also had to update my licenses and with that, the license server. I’m not sure whether The Foundry completely abandoned the FLEXlm license server, or not, but I transferred all my licenses to the newer RLM licensing scheme. With that came a few issues. The most notable one was that Nuke simply did not start up. Easy fix:
- Stop the foundry FLEXlm server
- Uninstall any older FLT software, completely, delete your old licenses, especially from the C:\ProgramData\The Foundry\RLM and C:\Program Files\The Foundry\RLM locations on your license server
- Install the latest version of the FLT software
- Run the FLT tool and drag-drop the newest license in there. It should install automatically for you.
- Restart the RLM server
Now this worked. Nuke started booting up, but it took terribly, terribly long. I mean, Nuke 8.xx took about 2-3 seconds to check for the license on my server (via VPN) and boot up. Nuke 9.0v1 took over 20 seconds (!!!) to check for the license and even longer (!!!) for Nuke Studio to fire up.
Something was wrong and I wasn’t sure what. All I suspected was that my setup was acting up as I’m sure The Foundry would’ve done something about this if it were a bug.
And sure enough! I found the issue.
I’ve recently upgraded my GPU to a TITAN Black with 6GBs of RAM, which is awesome, however, Adobe does not “support” this card in its current CC 2014 version.
However, there is no reason this card should not be supported, it’s only that Adobe hasn’t tested the card yet and thus does not provide any support towards it. But, fear not, TITAN Black will render the GPU accelerated previews and everything just fine. You just have to force-enable it in Premiere (and the likes). Here’s how:
- Go to your Premiere Pro CC 2014 installation folder, in my case: C:\Program Files\Adobe\Adobe Premiere Pro CC 2014
- Shift + Right-Click in that folder in order to launch the Command Line, from the menu, starting in that folder (this tip is free of charge )
- Execute the gpusniffer.exe program and see what name of your card it lists at the top
- Mine said “Renderer: GeForce GTX TITAN Black/PCIe/SSE2
- In the very same folder, locate the “cuda_supported_cards.txt” file and open it for editing
- Simply add your card at the end of the list. Do not include the “/PCIe/SSE2″ parts, just the name of the card
Done. Now Premiere Pro CC 2014 recognizes the card for Mercury playback and uses the GPU for acceleration.
Note: If you rather own an OpenCL GPU, edit the “opencl_supported_cards.txt” file instead of the “cuda_supported_cards.txt”.
If you’re, like me, on the Creative Cloud subscription, you’ve most likely upgraded your applications to the CC 2014 version. Which is all fine and dandy, because your shortcuts and settings got migrated over or synced via the Adobe Sync feature, right? Wrong! For some, unknown, reason the media encoding presets in Premiere and Media Encoder did not get transferred over, so your most favourite and most used presets are just gone and you have to re-do them one by one again.
But fear not, my friends, there is a very simple way (not so obvious, unfortunately, because Adobe chooses NOT to share this info with anyone).
Simply go to your local user directory:C:\Users\<username>\AppData\Roaming\Adobe\Common\AME\7.0\Presets
And copy everything from there to the new one:C:\Users\<username>\AppData\Roaming\Adobe\Common\AME\8.0\Presets
Done, now your presets will show up in the Premiere Pro CC 2014 as well as in the Media Encoder CC 2014.