Hey brains,
Has anybody experience in working with multiple artist on the same framestore and shared libraries?
It’s a long time ago I’ve tested it. But it seems to be quite unstable back then.
Is it more stable today?
How are you working with that?
Are you generating multiple workspaces on the same project?
Are there any pitfalls and tricks to be aware of?
Thanks,
Cheers,
Chris
I used to rock the heck outta this when I was staff on a team of 6-13 Flames. For me it was never not stable, it was always network performance driven. Yes, multiple workspaces. The biggest pitfall for me was changing artist behavior and eliminating the stigma of it. But, for me, it was the #1 way to eliminate ridiculous amounts of dupe data and substantial archiving waste.
We use shared libraries to transfer stuff between each other all the time without issue. That said it’s more of a dumping ground to easily push things to/from each other for a given project.
Having multiple artists connecting to their own workspace on a single “hero” Flame isn’t something I have experience with but I know places that do it. I love the idea but as @randy pointed out, best to have that network cranked to 11.
Aren’t multiple workspaces duplicating physical data on the framestore?
Did you mount a network server as framestore?
Or was it a dedicated shared raid system?
Did you cache?
Thanks! What do you mean by cranking up network to 11?
(Im not really the IT guy :D)
No, they are all reading from the same data. That’s the brilliant part of it. There’s never any wiring ever again.
The Framestore could be whatever. For example, it could be as simple as 2 Mac Pro’s where one of them has something simple like a 4 banger NVME RAID 0, which is what I use, on the same 10 gig network. So, one Mac Pro is the hero, with fast storage, and the 2nd Mac Pro on the same network sees that Flame and you can set THAT Flame’s storage as your own. And that’s it. That works pretty damn well.
Or, it could be a huge central SAN which everybody uses and bangs on, which is rare, but common only in a handful of facilities, I believe.
And the network cranked to 11? It’s all about the network bandwidth since the main Framestore will be serving images over the network to your machine, not locally via pcie. In other words, you can’t suck grapefruit through a straw.
A bad Spinal Tap reference! You need a lot of throughput as @randy said. Multiple people pulling from the same source.
That’s @ALan’s jam. He’ll for sure chime in. We’re relatively small and do it often enough to the point lately that I’ve been considering building a high availability sw server to house all projects. The zero media duplication and single archive alone make it worth its weight in gold. Compressed caches seemed to also aide in blowing your network bandwidth up but interfaces can be trunked and get faster everyday… as do those nifty high point cards…
Solid whenever we have used a single framestore. Some slowdown occasionally felt if one is playing back 3k footage at16-bit whilst another is also trying but probably down to hardware more than anything.
In my experience with shared libraries, they don’t give you anything beyond an assistants ability to push material to your framestore as opposed to pulling (wireing). Too much running from room to room asking for access to be turned on from memory.
We have settled on everything writing to the server now. All renders and setups go straight onto the central storage. Cache on import if you need to but never archive those and your archives become super tiny.
Thank you all!
Well,regarding smaller project sizes and archive sizes it sound really worth a try.
Combined with a fast network seems to be the go to solution for long and large projects.
But how is your experience with those shared libraries? Are those only usable when everybody is using the same workspace?
I’ve used shared frame store back when our flares didn’t have their own. I found it painful. Slow playback and interaction when hero flame is playing a clip to complete freeze up when the main flame had crashes.
Shared libraries work with issues. Sometimes get bugs where you can’t wire. If target flame is playing a clip you can’t wire.
There is a case building in my head for a shared server storage. Would suit smaller setups probably but it would really cut archive size down if all media is on the server along with setups. And in theory should make it easier to restore rather than looking for the needles in the hay-stack/archive.
By writing everything to server you mean, that you mounted the serves as your framestore?
Or are you working linked only and use a smaller local framestore for faster playback?
That sounds like my experience in the past.
I think there are two things to seperate:
Last one makes archiving a lot easier, if I understand correctly. But besides that, it’s more or less a own project for each flame station.
I think you either have a FAAAT pipe and can playback direct from server or you play from RAM. RAM does have that pause whilst you cache which isn’t ideal.
This sentence is none sense just so I can link up this as a reply
Isn’t that a Preference? Protect Playback?
Again, it’s all down to network performance. I’ve never had a clip not play because the host Flame was also playing. At my last place we had to tell the Artist on the hero machine that we were doing something, like, changing slates or relaying audio on their machine, not because of performance degradation, but because they wouldn’t know we were in the back of their machine so it was just a courtesy.
@johnt I know your experience was different but something ain’t right with that because that doesn’t need to be the case.
To be fair, the last time I hung a flare off a flame was 2013.
Probably pre AE too.
Smaller framestore 
We’ve been using a dedicated central framestore for years now. 72 x 1TB ssd, 100gigE network. Works great. None of our flames have local storage at all. I’ve made several videos and presentations regarding this.
