The Offset Podcast - The Offset Podcast EP003: Multi-Site Workflow

Episode Date: February 1, 2024

A postproduction finishing workflow can be complicated especially when you factor in the need to manage multiple sites and work locations. In this installment of The Offset Podcast, Robbie & Joey share the main points of the workflows they use daily in their boutique post & finishing company DC Color

In today's episode, we're talking workflow and not just a generic workflow, but the one that Joey and I actually use every single day on our projects. Stay tuned. Hey there, I'm Robbie Carmen. And I'm Joey Deanna. And welcome back to another episode of the Offset podcast. Joey, today, we are talking workflow. This is something that people bandy about, I mean, every single day in our circles and post-production and finishing. And there's a lot to workflows, obviously.

but we get asked, I mean, I think pretty much weekly, about the workflow that we do between, you know, ourselves and our different locations. And I want to kind of explore that today because we answer a lot of questions, like I said about it. And we're not doing anything as far as we're concerned super special. We're just kind of linking together a lot of, you know, sort of disparate pieces to kind of make things more efficient.

But before we go into our part of the workflow, So let's talk about what the kind of situation that we're facing is and some of the challenges that we're trying to conquer because there's a few of them. So everybody knows we have an office, you know, it's kind of our main office facility where we do a lot of our reviews. We work from there. That's where our whole audio team is based. But as you can see, Joey's room right there is in the basement of his house. I have a similar setup in the basement of my house. And so we have these three locations, but we're constantly.

needing to have media in one place and media and projects in another place. And for years, Joe, I think, I don't want to say we struggled because we had some workarounds. But why don't you describe kind of the old way of doing things and how we got that. And then we'll jump into what we're doing these days. Yeah. So like Robbie said, we've been kind of doing a multi-site shared workflow for a very long time. Both of us started working from home before the pandemic. And we've been moving media around, moving projects around, and working together on projects in various different ways over the years.

You know, early on, it would be as simple as, okay, here's all the client media. We're going to download it. I'll download it on my end. Or Robbie might download one. Or drive. Or drive. And I'll copy the drive and then move the drive over to the office or give it to Robbie so he can take it to his house. and I would maybe set up a project on my end,

organize all the folders, how I felt like organizing them on my storage, right? And then Robbie would do the same thing on his end. And when we needed to move something back or forth, we would export a DRP, a resolve project. And then he would open it on his end, relink all the media. Sometimes that was an easy process.

Sometimes it was not depending on if we had used different naming or different drive lettering or, you know, going from different platform to platform. And we would do that, back and forth. So when it would have to come back to me for any reason, I would have to do the inverse and basically undo all that Robbie did to make it work on his end, to make it work on my end. And there was a lot of inefficiency involved there. So we've gone through both as the software's evolved and as our process has evolved internally, a couple of really important steps to make all of

this basically seamless. Yeah. And I mean, I think there's a couple of things that, you know, early on, you know, we were both of us kind of, you know, we've been working, you know, together for almost 10 years now. And I think, you know, there was things that you like to do in the way that you named things and organized things. There was things that I like to do. And, you know, I think we got our shorthand down pretty well, but there was still sometimes, you know, some detective work. Okay, like, where did you put these, you know, these patches that came from the client? Or, oh, you got audio mix from the audio team. Where did, where does that go? And so there was some organizational things besides just the mechanical stuff of like how we how we push stuff around.

And I think my, you know, my biggest pain point from that period of time was especially with Resolve and DRPs and projects files is staying in sync, right? Knowing kind of this is the latest version of this project, this is the latest timeline. Oh, that's the one that you did X, Y, and Z on. And that was a real challenge. And we'd end up at the time, end up with a folder of, you know, 20 or 30, DRPs from, oh, after review session, post review session, and we'd call it different things, and it got super confusing real quick, and we said, no, no, we got a, we got to fix it. That kind of collaboration kind of discouraged the teamwork aspect a little bit, right?

Because if it's a process to go from one site to another and back, I can't say, hey, Robby, can you look at this shot on this timeline real quick? You know, it might take me less time just to figure out my problem myself, or vice Versa. These days, we share very small components of projects really regularly. Oh, can you work on this masking problem while I finish coloring this act of the show? Can you do act one and I'll do act two? You know, basically, in our day, if we need help, we can always reach out to the other one for help. And because the workflow is seamless, there's no inconvenient penalty to doing that. Whereas with the old DRP way, it's kind of like, the problem has to be big enough to justify.

the back and forth before we collaborate, whereas now it can just be like, great, you do this, I do this, we get it all done quick. Yeah, and to be clear, I think a lot of people might be listening going, well, yeah, I do that every day in my facility. It's easier to do when you're down the hallway from somebody and you're working off the same shared storage and all that kind of stuff. Harder to do when you have two people in different locations and in our case, actually have multiple locations that we might not even be at every day that we want the media there.

Like I want to be able to go to the office, you know, and not have to move anything over or do anything and just sit down at the desk at the office and go, oh, yeah, there's where the projects where I left it last night or Joey left it last night at home and we're off to the races. So I think for me, Joey, kind of we can break this down into a number of parts. And I think the hardest one for a lot of people to kind of get their head around is the idea of sinking media, right? So of course, for the longest time, everybody knows the phrase sneaker net. That was the way it was done, right? Here's a thumb drive or a hard drive. You move it from one system to another system. There's lots of problems with that approach, though.

I think you hit on one of them, and that is simply different platforms, different drive mapping. Can you expand on that a little bit? Yeah. So one of the things we haven't mentioned yet that I think is important to kind of add into this overall equation is not only do we have three different sites. We have two, and it sometimes, depending on how we've configured machines, three different platforms. We might have a Linux resolve, which we've had on and off in the past just for various reasons. But right now, primarily we're on Mac resolves and Windows resolves. In my suite here,

I've got one Windows resolve and one Mac resolve. At the office, we have just a Windows resolve. At Robbie's suite, he's got two Mac resolves, and they all address media differently. So the big problem with storage is multifaceted. One, getting all of the information for a project, basically all of the files to all three sites. And when one changes

somewhere, making sure that change happens everywhere. So if I download mixes, I need those mixes to be sent to the office and to Robbie's house. I need Robbie to be able to download a patch from the client, and then I get it and the office gets it without us having to do any kind of manual

intervention. That's one part. That's one part. The next part is file paths and drive mapping. And that kind of takes two things. One is a technical thing and one's an organizational thing. The technical issue is Macs and PCs do drives differently. You could have like the D drive or the E drive on a Windows machine. And then on a Mac or Linux, it's slash volume, slash whatever, slash MNT, slash whatever, however you mount the system.

Now, resolve has some really great features for, dealing with this called mapped mounts. And you can basically define all your storages and also what they are on other systems. So, for example, on our systems, on the Macs and Linux's, it's slash volumes slash DC color, right? And if we get under a Windows system, we have the map mount set to that. And on the max, we have the map mount set to R drive. The reason why we have R drive is because all of our Windows machines have the DC color stored folder as R. That way we're only transposing paths between Unix style paths and Windows

style paths. On Mac and Linux, it's always in the slash volumes folder. On Windows, it's always on the R drive. So we only have to do one mapped mount, and that's to associate between different platforms, not setting up mapped mounts between My House and the Office, the Office and Robbie's house, my house and Robbie's house. Totally. And I think there's a few things to kind of further explore there. Number one, we do not operate with working off of external removable drives, right? I think that's a challenge that a lot of people find themselves saying, like, well, I had this drive, then I unplugged it. Like, this whole idea that we're about to expand a little bit more detail is predicated on the idea that we essentially have fixed storage. We have a NAS at the facility. We have a NAS at

your house, a NAS at my house. And so those file paths once set up are kind of always the same, right? They don't change, right? You know, slash volume slash DC colors, always there, slash R or R colon slash lashes, always there on the on the windows boxes. And then two, because I think of some people might be new to mapped mounts and resolve. But I'm always, to this day, I'm surprised how many people are like, whoa, I had no idea you could click on that little file thing and it changed it's been in there since like version six. And it's, and I don't understand why every other platform in the world doesn't do this. Doesn't do this. It's so simple, but it's such a time saver. It is. And just, I mean, the simple way of saying it is that once you set up a

mapped mount, if it's, so for example, if you're trying to map, you know, volume slash DC color to R and you set that R up as your math mount, basically the way it works is that anytime in a file path it sees slash volume slash DC color, it goes, oh, I know, I'm going to swap that out with R or vice versa, right? And so the real advantage of that mapped mount workflow, uh, part of this is that, as we'll explain in a second once we start syncing media, is that we never have to relink anything, right? As long as that mapped mount is set up, I just open up the project,

even if I'm on a different platform, it knows, right? Yeah, and that's where the standardization part of this comes in. Remember I said there was two things. There's kind of the technical part, which is the mapped mount, and then the operational part, which is standardization. One, we can use the mapped mounts because we standardize mount points across all of our platforms. Like I said, all the Linux, all the windows,

all the Macs have the same mount path within their ecosystem. So we're just using mapped mounts to go between them. But the other thing that took us a long time to kind of really commit to, but I think it's really, really, really important when you work with a team.

Even if that team is just two people, is we now have a dedicated, templated out project folder structure. And what that means is every project gets the same folder structure. And the first people, you you know, it's kind of like using a fixed node structure in resolve, right?

When you first think about it, you're like, well, that's going to be really limiting. But it's not if you build it out oversized. So our folder structure basically has a dedicated folder for anything we would ever need in a project. In any given project, we might use 10% of those folders. But one thing I've found over years of working at post-production is the best way to be organized is to automatically have a place to put things that is the right place. if there's a right place to put things, that becomes your default. So even when you're under the gun,

even when you're rushing, you just jump to the right place first. Instead of jumping to, oh, God, I got to get this done quickly. I'm going to just throw it on my desktop or I'm going to do something disorganized. So because now the project folder structure is the same in any site that we have the project,

the maps are the same, the mounts are the same. It really is, I can open up a project on my desk, I can walk over to my assistant, station desk, which is a Windows machine, open up the same project. I can drive to the office, open up the same project, and I can call Robbie and say, Robbie, can you look at shot number two on this project? And he can literally just open it up and go to shot number two, and we're all on the same page with no relinking of media. Totally. And I think that it's, you know, that how we have that organized, so we're using a tool called Post-Haste, that popular tool on the Mac platform

people have known about for a long time. It's just, it allows you to automatically create those, the folder structures, however you want. That's a good point to make is that we basically organize things for client provided stuff and then stuff that we create or organize on ourselves. So in the client folder, we have a folder for, you know, consolidated media folder if they give us like a Premier Pro project or something like that. We have a folder for baked files. We have a folder for, you know, fixes and VFX and stuff like that.

And in our folder, we have, you know, folders for audio and graphics that might receive. from other vendors. We have a folder for screeners and final output. The point about this is not to kind of, you know, lock in, you know, for people to take our folder structure. It's more so just to think about that folder structure that works for you on your end and then sicking to it, right? That if you know every time, oh, well, I'm looking for the reference file

for this timeline, well, guess what? It's in client stuff and references and there you go, right? And it's just that repeatability in is. easy to find. And it did take us a while to get to this point, and it was for no reason except that we were working, right? So we were working good enough. Projects were coming in, projects were getting done, projects were going out. There wasn't a dramatic issue to solve. So we never just sat down and said, okay, let's pause, think about the actual workflow, the folder structure, and standardize. Once we did that, we did a couple iterations, right? We tried

some things, tried it with some real projects, evolved it, and then kind of locked it in. And that's important. Anytime you're kind of building a templated workflow, try it, be ready to make changes. Eventually you're going to lock it in. But, you know, we have some early projects that might not adhere to the structure exactly because we were still wiggling around and playing with it. And that's fine. It's always going to be a process. But just making the effort to have everyone on the same page makes a huge difference. And I think it's kind of like a diet or an exercise plan. right? Like I'm more guilty than you are of like sometimes just being getting lazy and going, ah, I'll threaten. But you know, it's one of those things. The more that you do it, the more it becomes

habit and the more you see the benefits from it, just like a diet or an exercise plan or whatever, you know? And I think that, you know, that iteration is important. You know, we just, early on, for example, like I didn't realize that like lowercase folder names drove you crazy, right? And, you know, it's like, which is completely irrational, but I just, I like uppercase folder. I don't know. All right. So we've covered the part about mapped mounts and file paths. We've talked about sort of a standardized folder structure.

How are we actually getting media from point A to B to C? How does that actually work? So everybody knows there's lots of solutions for this. And the right answer for you is whichever one is right for you. But for us, our needs in general were we don't want to go to a cloud provider. don't want to mirror everything in the cloud because that's either going to get really slow or really expensive. We needed to be able to reliably go between three different places, and we needed to be able to kind of control it because, you know, we have a lot of really huge

projects that don't ever need to move. Like, I might be working on a film for a long time and never need to touch it at the office or at Robbie's place. And we don't want to just sink the entire pile of everything we always work on. We want to be able to see. say, okay, this project checkbox goes to the office, goes to Joey's house, goes to Robbie's house. This project goes to Robbie's house in the office. So we need to be able to kind of direct

what projects we're putting to what storage because like Robbie said, we have NASS at each location and while storage has gotten really cheap, it's not free. And media files are doing nothing but getting bigger. So we do need to be able to do

some management. First we started using Resilio Sync back when it was still called BitTorrent Sync originally. That's right. And Resilio Sync is a pretty cool product. A lot of people use it very successfully. We ended up switching off of that because we had some various technical problems with it.

And we had also... I should add that we were also running Resilio Sync locally on not on our NASS systems, but on a computer that was at that particular location. So there was a Mac. a spare Mac or a PC wherever on those various locations that was running Resilio Sync as an application. Yeah, so to manage it, you'd have to go to that computer. Right.

So what we ended up settling on is a really cool piece of open source software called Sync Thing. And what Sync Thing does is basically it runs in the background on any system, which also means we can run it inside a virtual machine on our actual NASS systems. And this works on various NASS platforms. So if you're on Synology, QNAP, True NAS, which is what we use, most of them have virtual machine capability, and you can run Sync Thing right on your NASS, which means it's super fast, indexing files, scanning files, sending files back and forth, and it doesn't put a load on your grading system. And what Sync Thing does is it presents you with a WebUI. You can access the WebUI from anywhere in your network so I can, like, jump on my iPad and say, hey, Robbie, I'm sending you this project, click. and it's done because all the paths are available

on my NAS and sync thing is running on the NAS. And we can just basically have a, we just have a running list of projects where they're synced to. And if we make changes, it watches the folders, uploads the files to and from different locations. It has a trash functionality

that has saved us in the past because let's say somebody deletes something at a remote site, then it's going to ripple that delete to the other sites to keep everything in sync. Well, you can set a preference in there to have it instead of delete it, move it to a hidden trash folder. That way, if I delete half the project, guess what? I might have deleted it from my system.

It's still at the office. It's still at Robbie's house because it didn't delete them from his storage. It just moved it into the trash folder. That's a good point. I'll expand on that in just one second. So I think it's important to make note of a phrase that's often used with this kind of technology. And that it distinguish itself from other ways that people might be working. you know, this is a peer to peer kind of setup.

We are going from my NAS to the office NAS to Joey's NAS, wherever this client's running directly. We are not using a relay point first. You know, so people might go, oh yeah, sure, I collaborate media, but I first sync it to, you know, my Google Drive or Dropbox or Frame I.O. Well, in that situation, you're going up to some point, relay point in the cloud, and then the other end is having to pull that down.

So you have three stops along that chain as opposed to two. And we have noticed that from a speed perspective, it's as fast as the pipes on either end can support. And so for us, that basically means gigabit speeds, you know, to and fro. And so, you know, we- Yeah, seeing pro-res files move at 900 megabits a second on sync thing is pretty cool because it's like, Robbie, can you send me that project?

Do you want me to have a look at? sure click yes okay cool I've got it if it's a small project yeah and I think the I think the added benefit of as you mentioned that of running this on your NASA systems too is that those those machines those boxes are generally going to be running all the time so there's not a concern of oh that computer went to sleep or somebody on you know took that laptop off the network or whatever it is these are kind of fixed assets they're always listening and watching for media to come in and I think you mentioned the trash thing the other thing I think is a really important thing that we've gotten in trouble with in the past with tools like Resilio was how these these sync tools handle conflicts, right?

So like, you know, if for example, you're syncing something while it's still downloading or, you know, you created a folder at the exact same moment that I created a folder. Sync thing has a robust set of tools to kind of manage that too. You know, hey, I noticed that this file's out of sync. You might need to look at this and address this. And that's saved our butts a few times as well. Yeah, and because it's on this nice web-based dashboard, like a lot of times we can actively manage it really easily. Like, if we are rendering a hour-long ProRes 444 file, I'll just click pause on that sync because I don't want it trying to scan that file while it's still being rendered. Totally. Right? And then have to figure it out at the end and re-scan it again.

So it's just it's always there. It's always running. It's always in the background. And it's very easily accessible. I can even VPN in and grab it from myself. phone because all we're doing is telling sync thing what to do. We're not moving data around on that actual machine we're accessing it from. Yeah. And so from a practical point of view, if let's just, as Joey mentioned earlier when we first started talking about the ability to ask for help or get

a fix on something, in that sense, what we usually do is, hey, Joey, I need you to whatever, do some magic, you know, some VFX magic on the shot. His reply will, okay, sure, just sync the project over to me. I click two buttons. And then in just a matter of moment, you know, again, depending on the project is, it's over to him. And vice versa, let's say I get a client who sends a drive to my house, but I'm going to be reviewing with them at the office. Well, that's easy. I'll just copy the drive here, hit sync to the office, and when I go to the office tomorrow morning, guess what? Everything's there already ready to go. So it's very valuable in kind of moving that data around. And I think combined with the two other things you mentioned earlier,

the file path stuff and the fixed, you know, the fixed folder structure. it's like working on you know really it's like working on the same system everywhere you sit down all the time the media is just there which is which is killer yeah and I think that's kind of a great

lead in to the other big big big massive ingredient for this that is relatively recent but is conceptually very very important and that is how do we interact with the projects

across multiple sites. Yeah, and as you said earlier, you know, it used to be this mental gymnastics that you had to play of, you know, is this the right version of the project? What's the timeline in that sequence? Like we, you know, I think at the time, we were just like, God, this could be so much better.

And, you know, we've, you know, covered, I know we've done a lot of training about like the true collaborative workflow and setting that up and resolve. But that's all been predicated on the idea that you're working on the same network. right, that you're in the same place. And we went down this rabbit hole for a year. I'm trying to set up our own VPN cloud-based shared database server,

and we could never get it to perform at the level we needed it to, because the Resolve database connection to PostgresSQL, which is a industry standard database, but the way Resolve talks to it is very important. And that was never fast enough over high-latency connections like the Internet. Resolve 17, I believe it was it 17? I think it was 17. Resolve 17 completely rewrote that connection

specifically to make it fast enough to use over the internet. And that's what allows the Blackmagic cloud to work. Yeah. But it also would allow you to make your own private cloud database server if you wanted. Yeah. And so we decided after looking at that for a long, as you said, we had tried VPN.

We had tried all sorts of things. When the Black Magic team came out with Blackmagic. Magic Cloud and supporting databases there. You know, I think the first thing we thought of is, well, we don't want to pay anybody extra money to do anything and we'll. Yeah, we could build this ourselves. We can build it. Now that it's possible.

Right. We'll build this themselves. And where did we land with that and why did we land on what we did? I started spooling up virtual machines, VPN servers, and we were going to do it all in-house because, again, the technology and resolve that allows the cloud to work will also work on a private database server. There's nothing different between the two. So you can do this privately.

Once I got through all the kind of IT side and dealing with, okay, do I want all three offices on the same VPN? And then that all the time? Probably not. What if I want a VPN into my own house from my phone for other reasons? Do I want to have three different VPN servers running? Do I want to actively manage and secure all this? No.

If you have a big IT, staff and, you know, kind of an already done cloud infrastructure for other things. That's a great option. But for us, $5 a month per database and you just log in. So we're on Blackmagic Cloud for essentially all of our projects. They're all hosted on the cloud database. We still do local backups of everything just to be safe. But, I mean, for the money, it is just, it's not worth our time to become ITX.

experts to do that. And also, it's not worth the risk of exposing our networks to security problems. Yeah, and I think there are some people who, for whatever reason, they're in a TPN situation, or they have to be air-dapped for other security reasons. You know, there are valid reasons to recreate this kind of technology internally where it's under your control and, you know, you have a little more, you know, security to throw at it. With that said, Black Magic is using, you know, kind of industry standard AWS kind of backbone for this kind of stuff. You know, so it is secure, easy to use, as you said, the cost $5 per database, which I think, correct me if I'm wrong, but I think that supports, what, at $5, you get 10 users per database, something like that. 10 shared users and infinite projects in the database. In that database. From a practical perspective, we've been creating a new database basically like per major version of resolve.

and backing up the old one. But, I mean, at any given point, we have one or two databases, so five or $10 a month. So in practicality now, all this really means is that inside of resolve, instead of opening up a local database or a shared database, you know, from a server that's on my network or on the network I'm on, we're just pointing that logging into the Blackmagic cloud. It operates and functions just like any other database,

you know, SQL database that you might have in resolve. But here's the benefit, right? So I go ahead and I sync a project over to Joey and let's just call it for lack of better term project XYZ. I put it in that database. I add some media to it. Again, that's on my NAS. So first thing I do is I'm clicking in sync thing to share that folder from my NASS over to Joey's. Again, standard folder.

In a few minutes, Joey gets that folder. All he has to do on his end is open up resolve, find the project that I just created. He opens it up. And guess what? through the beauty of path mapping and all that other stuff, everything's online. He simply slacks me or texts me and says, hey, Rob, what shot was it?

I go, it was 17. He goes, cool, I've done a pass on that. Open it up, see what you think. In fact, it works so well for doing this that I can open the project in read-only mode if he has it open and just look at what he's on. But it gets even better than that because the cloud database, of course, also supports true collaboration mode, which prior to this was really kind of limited,

the developments that you spoke about, was really limited to doing collaboration on a single network, right? You have a shared database server on that network, everybody in that facility or places we can do that. But now we can replicate all of those true collaboration features through our cloud database. So if we want to work at the same time, for example, I'm like, Joey, can you follow behind me, you know,

doing this roto work and fusion because I don't know fusion at all, you can go, sure. And all the features that we're used to in collaboration, how timeline ownership, how clip ownership works, all that stuff works like a charm. Yeah. And performance-wise, I cannot emphasize this enough. I can't tell that I'm working on a cloud database versus a local database.

Oh, yeah. It's just they've figured out the caching and the data flow so well that it just works seamlessly in single user, or in collaboration. One last thing before we kind of talk about collaborating and some of the gotchas involved is I do want to mention you talked about TPN and air gaping and stuff like that. There is a happy middle ground to be had with that

because while we're not doing specific like major studio TPN certified things, we still very much care about our clients' data security and privacy and making sure that we don't, get anything out in the world that it doesn't belong and things don't happen security-wise that are bad. So as a general policy, we don't have our resolve systems connected to the internet. My main resolve system is not online.

I bring everything in and out and do all my email and everything else on a Mac studio that's sitting next to it. But that brings up the question, well, if the main resolve isn't online, how can you do cloud database? Well, the main resolve isn't online, but it's on the network. And I've actually created firewall rules that say, okay, do not let any internet traffic in or out of this Mac Pro on this Ethernet port, right?

But allow connections to and from the Black Magic Cloud database. And that was like a five-minute configuration in our firewall. You could probably do that in any, you know, firewall, maybe even on like your home internet router. It's not a very complicated thing of combination of ports and hosts to. add kind of to the white list to say, hey, allow this, don't allow everything else. So yeah, if I open up a web browser on my main machine, can't see anything. If I try to do MacOS updates, can't see anything. If I try to download a file, can't see anything. I open up Resolve. It just pops up with the cloud login. I put in my username and password, and I'm in. So you can get to a

reasonable middle ground of security, convenience, and mostly air-gapping your machine without being like, I'm going to put this thing in a prison and only bring things in and out with certified thumb drives. Yeah, that's a great point. And one more thing that I just thought of before we get to the collaboration gotchas real quick is, you know, I think working in the cloud instills some fear in people in terms of like, well, what if, you know, Black Magic or AWS goes down or, you know, what can I do? you know the normal suggestions about project backup whether that's you know obviously a live safe thing or an actual project backup or however else you want to do it by exporting d rps all of those practices are still germane of course to working in the cloud just because you're in the cloud i wouldn't depend on that as you know your sole your sole reliable backup system so one thing i don't think a lot of people realize that is possible because in the you know in past you'd have to take the whole database and then you'd have to export that. It makes that tarb zip thing. It's big. It takes a while.

Or you'd have to export individual DRPs. There's actually an easier way to do this that plays into the drag and drop nature a lot of us is you can simply just highlight a project or even a folder of projects or even everything in the project manager window and resolve now. And you can simply just drag that to a location of your choosing. So, you know, if you want to just,

first thing you do in the morning when you open up Resolve, just take something, drag it to your Dropbox or Google, Google Drive or wherever else you want to back up, that's an easy way to back up. And like I said, it also respects folder organization within the database too. So if you want to just take the whole thing and back it up, that's an easy, easy solve as well. Yeah, and we've done that for various reasons of doing full backups or backing up a set of DRPs or for archiving purposes. And what I usually do is I just bound a hotkey to export DRP.

So once I'm like, oh, cool, I'm making great progress on this project. bang out of DRP to my default export folder, which is then synced to a cloud file share just to have. So I've just got a running DRP backup of everything that I'm doing just in case. If the internet goes down,

I can just import that DRP and be back to work because, again, our storage isn't relying on the cloud. Our storage is synced to the three locations locally. So as long as I have that project information somewhere, if the entire internet goes down, I can still continue working. That's such a great point.

about the sync stuff back and forth is that, you know, I know both of us, but I'm going to make fun of you a little bit. You are about as data security, uh, I'm going to say conscious, but really what I mean is anxious, paranoid, yeah. Anxious. Yes. About losing, losing stuff more than anybody I possibly know. Folks, I'm not kidding you. Like Joey will back up things seven times and still be sweating at night, uh, thinking about losing data. One of the added benefits, especially when you're working on a big sand or something like that that could take days to rebuild,

is that sinking does have that extra layer of security for us that, hey, if I lose everything, if my NASS just blows up, guess what? I'm still sinking that two other places. And so it's kind of, you know, kind of inherently a little bit of a backup system, not a great one, but a little bit of a backup system because it's there. Now, Joey, two last things before we wrap up here. we had mentioned some collaborating function gotchas. Now, specifically what I mean by that is not the way that we've set things up, but collaboration mode inside of a result project when you're in collaboration mode. What are some of the gotchas that you've noted?

I've noted a couple, but I'm curious to hear your thoughts. Yeah, so it is important to remember that collaboration is kind of its own thing in resolve. There's collaborative projects and non-collaborative projects, and you need to switch that on. And when you switch it on, it does have some implications. The biggest one is that it doesn't let you do dynamic project switching when you're in collaboration mode. So just be aware of that.

If you don't need to have a project set to collaboration, probably don't put it on collaboration because you lose that convenience of dynamic project switching. The way we usually do it is if we need to both be in the same project at the same time, we'll say, okay, I'm going to turn on collaboration. we both go into the project and then when it goes back to only one of us working on it we'll manually go ahead and turn off collaboration for that project

because it does make some other things easier. The other thing that we've seen issues with is if you have an external mat coming from the media pool into your node tree, we've had some odd issues only on collaborative projects where that doesn't link correctly across other machines.

And if you turn off collaboration. It's back to normal. It will work. We had this. There was a project a couple weeks ago where I was working on some keys while Robbie was working on some color and I'm like, cool, Robbie, keys are all done. They look great. We're ready to go. And he opens it up and he's like

trying to be polite about it. He's like, are you sure they're all done? Are you sure you're great at this? Because on his end something in the node tree wasn't communicating right over the collaboration mode and all of the keys in color looked completely nuts. Yep. While on my machines, they were fine. So we backed out, turned off collaboration, and went back in, and it was fine.

So the only thing I would say is, one, we do know that the cloud part of this is still technically in beta. Yep. And two, the collaboration features are evolving pretty rapidly as well. So if you see something that's a little on the week, weirder side. Don't panic. Think critically about it. Be like, okay, maybe this is a bug or a workflow problem on collaboration.

Let's try and troubleshoot it. Don't immediately think that Joey went blind and graded everything insane. Yeah, no, that's definitely a gotcha. I have noticed a similar, a similar issue with, the only way I can describe it is moving too fast. And so all the normal rules, all the normal rules about clip ownership, especially on the color page timeline, apply with collaboration mode as they do locally, right? So while I'm on that clip, I own that clip.

For you to see changes on that clip, I need to move off to another one, and then you need to refresh or whatever, right? I have noticed sometimes if I'm just, you know, next clip, next clip, next clip, oh, previous clip, next clip, next node, whatever bouncing around. Resolve and collaborative mode can sort of get a little confused. If you give it a second, it usually sorts itself out, but sometimes that's an issue. And then the other one I've noticed that I'm sure is just a matter of how the AWS login works with Resolve and how often it needs to re-authenticate.

I've noticed a couple times I've logged in, nothing seems to work. Like I'm toggling grades on and off. It doesn't seem to work. And I'm not getting any warnings from Resolve, right? I have found that nine times out of 10, if I quit Resolve, the next time that I launch it, it's asking me to re-authenticate to the cloud database and just re-logged back in. Why it doesn't do that the first time when it doesn't want to respond, I don't know. But that seems to be the fix for most of those problems.

Yeah, and the good news here is you don't have to be too scared because the common thread in all of these kind of gotchas is that resolve isn't going to let you break the project if it doesn't have a good connection to the database. So like if you're doing what Robbie was saying and jumping back and forth between a clip really, really fast, and for some reason, it doesn't take ownership of the shot, the color controls won't change anything, right?

If you get logged out of the database and you try to delete a bunch of stuff out of the project, it won't let you because it doesn't have the permission to go to the cloud and say, hey, delete all this stuff. So, if you get into some of these kind of weird things that we've seen, just back out,

re-log in, and come back in, and your project will still be intact. It's really, really good about doing what I think is the most important part, which is not let you break it. And this is not just like, you know, promotion for black magic and, you know, toting the company line or whatever.

They're not doing anything for us. It's, I, honest to God, truth, in a year plus of using the cloud database, I have not lost a single project or lost any work or data from that. And when I've lost something, it's been like super stupid, normal, you know, color of screw up stuff like, you know,

rippling something to 4,000 grades. and then, you know, messing that kind of thing up, right? Not because... Yeah, I've even had an issue where AWS went down, right? So our connection to the database just went away. AWS went down. Or my internet connection went down. And Resolve will come up and say,

hey, I can't get to the database. Do you want to, A, export a DRP of your project because it keeps the project in memory. So even if it disconnects from the cloud, when it errors out, it will let you export a DRP of that project to your local machine, which is a huge saver.

Awesome security blanket to have. But when that came up, when either my internet connection went down or when AWS went down, what I did is I just backed away

from the system and waited for AWS to come back. And sure enough, the second it could see the database again, it was like nothing had happened.

Actually, the error went away and I just kept on working. Just like we... I exported the backup and then I kept working. Just like we spoke about a few minutes ago with the inherent data security of syncing media,

that is one, last thing that I think we can wrap on is that, you know, there's nothing saying that you can't have multiple layers of protection within your database, too. And so, you know, one thing that I think a lot of people are doing or thinking about doing is they're working locally in a local day, whether that's, you know, a local SQL database, a network SQL database or even a project derived database. There's nothing saying that when you want to then share that with the rest of your teammates or whatever, you can't simply, you know, command, Control C, Commander Control V, and paste that into the cloud database, right?

It might be... Yeah, and you can do that across databases right in the Resolve Project Manager. You don't need to export and import anymore. In fact, there's now a button in the top right to copy selected projects to any of your other database. Exactly. So if you're a type of person that's like, you know, really antsy about other people in your facility, maybe, you know, looking at it, you know, and when you're not ready yet or messing it up somehow, work locally and then copy that to the shared database when you need to do this.

the rest of this workflow. So Joey, I think hopefully everybody kind of gronked what we're talking about here. We're exceedingly happy with this workflow. And I think that if you guys have any questions about it, we're happy to answer those. Again, not reinventing anything from scratch, but kind of putting these various pieces together. And it's allowed us to be incredibly efficient across multiple locations with multiple users with limited amount of headaches. And so for the time being, that's how we're rolling. We're really happy with it. And let us know if you adopt, you know, this in part or in all of it. And for sure, let us know if you have any questions. All right, guys, well, that's it for this installment of the Offset podcast. I'm Robbie Carmen.

And I'm Joey Deanna. Thanks for listening.