Improve & Simplify "Relink BRAW Clips within an EVENT" Toolbox

[tangierc]

Using v1.0.6 (44) on Mac Book Pro / M2 Max / macOS 13.2.1 / FCP 10.6.5

Many of my previously online clips go offline with all of my drive sources connected.

• One event has with the missis effect alert. The BRAW Toolbox effect in the inspector has no parameters to view. Only the Effect name is showing.
• I attempt to reimport all of clips again and create a new folder and after doing so the new event also has the same results - all clips don't have the effect applied and they're unviewable.
• The clips were viewable and playable in the BRAW Toolbox playback window.
• I also attempted to apply the BRAW Toolbox effect from the FCP effect palette onto one of the clips, but that yielded no results either.

Attached is an image of a freshly imported event with FCP playback settings set to Optimized/Original

[tangierc]

Going back through my events it seems that all of my BRAW clips report missing the effect in the browser. However the ones that are on the timeline do play in the FCP viewer, but also have no BRAW Toolbox effects in the inspector. I've had no crashes of any sort. Only a normal restart after quitting all apps.

The folder that contains my library, backup files, and cache files was on an external SSD. I moved that to my internal SSD before launching this library. Would that cause an issue?

[tangierc]

Really at a loss here. I did an uninstall and reinstall of BRAW Toolbox and all of its pieces. Launched FCP. The new event I created above now has the effect, but all of the clips say "No BRAW ice selected". I tried to change global settings to allow access to the drive where the clips are. That didn't change anything. The most strange is I attempted to take that new event into BRAW Toolbox and relink, but got an error that no BRAW clips were detected so I can't relink an event of clips that BRAW Toolbox created.

[latenitefilms]

Again, apologies for the delayed reply!

No BRAW File Selected should only really ever appear if you manually apply a BRAW Toolbox effect (this will be the default image). The only other way it could appear is if you click the Select BRAW File button on an already imported clip, and then something goes wrong.

Are you sure you haven't accidentally added the BRAW Toolbox effect manually to the clips?

The screenshots in your first post show an error message from Final Cut Pro essentially saying it can't load the BRAW Toolbox effect. This could either be because the FxPlug4 effect hasn't loaded properly, or it's failing to open the Apple Motion template for whatever reason.

[tangierc]

Thanks for responding Chris. I have never used the effect. I’ve had no reason to. Every clip I bring in has been with the workflow extension. Things go offline for reasons unknown and relinking feature, even when I can drag the updated event into the library after granting access my clips don’t get updated. What I’ve been doing is creating new libraries just for a shoot day. Importing clips again, running them through sync-n-link if need be then moving those clips to the problem event.

Reconnecting clips has been a very scary issue for me whereas sometimes I’ll open a project and braw is just offline so I revert to an older copy of the library hoping there’s something maintained, then rebuild my notes from there. I’m afraid to move the project to a faster (thunderbolt) hard drive for fear of things breaking.

When granting access does it have to be directly to the folder containing the braw or can it be drive level? Sometimes it seems FCP needs time to update events and draw the timeline even with existing cache files and manipulating the icon view to work around that bug.

I’m not using that 2013 Mac Pro any more. I’m on an MBP M2 Max with Ventura.

Thanks again Chris.

Tangier

On Apr 2, 2023, at 4:40 AM, Chris Hocking @.***> wrote:

Again, apologies for the delayed reply!

No BRAW File Selected should only really ever appear if you manually apply a BRAW Toolbox effect (this will be the default image). The only other way it could appear is if you click the Select BRAW File button on an already imported clip, and then something goes wrong.

Are you sure you haven't accidentally added the BRAW Toolbox effect manually to the clips?

The screenshots in your first post show an error message from Final Cut Pro essentially saying it can't load the BRAW Toolbox effect. This could either be because the FxPlug4 effect hasn't loaded properly, or it's failing to open the Apple Motion template for whatever reason.

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1493307999, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTQSAX3O4LS4HSHOSB3W7FJRLANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[latenitefilms]

Generally speaking, I would only ever use the Relink BRAW Clips within an EVENT Toolbox feature as a last resort. I basically only added this as a fail-safe if people ran into problems and needed a workaround, as opposed to manually re-linking each file individually. I generally recommend just trying to keep a consistent file path if moving things between machines - i.e. if you have two editors working on the same job at the same time, just work off SSDs that have the same volume name. This is how we've been working with BRAW Toolbox and it works great. If you can't do this for whatever reason (maybe at work you have a NAS, but at home you're working off an external SSD) - you can use Sym-links so that the file path is consistent.

When granting access does it have to be directly to the folder containing the braw or can it be drive level?

It can just be at the drive level.

[tangierc]

Thanks for the response Chris. I am about to move all files for this project from two USB 3.2 type C drives to one Thunderbolt 3 RAID for all assets. What do you suggest so that all of the braw doesn’t fall apart when I do this?

Thanks,

Tangier

On Apr 2, 2023, at 6:48 PM, Chris Hocking @.***> wrote:

Generally speaking, I would only ever use the Relink BRAW Clips within an EVENT Toolbox feature as a last resort. I basically only added this as a fail-safe if people ran into problems and needed a workaround, as opposed to manually re-linking each file individually. I generally recommend just trying to keep a consistent file path if moving things between machines - i.e. if you have two editors working on the same job at the same time, just work off SSDs that have the same volume name. This is how we've been working with BRAW Toolbox and it works great. If you can't do this for whatever reason (maybe at work you have a NAS, but at home you're working off an external SSD) - you can use Sym-links so that the file path is consistent.

When granting access does it have to be directly to the folder containing the braw or can it be drive level?

It can just be at the drive level.

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1493522626, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTWX4WIHPKKF7OJUYRDW7IT7LANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[tangierc]

Hey Chris. I’m not sure how to force use Sym links. I could really use some guidance on how to properly move everything from two drives to a single new Raid drive without having to manually relink each clip. There’s way too many and would take too much time and I haven’t been able to get the relinking toolbox to work.Sincerely,TangierOn Apr 2, 2023, at 6:48 PM, Chris Hocking @.***> wrote: Generally speaking, I would only ever use the Relink BRAW Clips within an EVENT Toolbox feature as a last resort. I basically only added this as a fail-safe if people ran into problems and needed a workaround, as opposed to manually re-linking each file individually. I generally recommend just trying to keep a consistent file path if moving things between machines - i.e. if you have two editors working on the same job at the same time, just work off SSDs that have the same volume name. This is how we've been working with BRAW Toolbox and it works great. If you can't do this for whatever reason (maybe at work you have a NAS, but at home you're working off an external SSD) - you can use Sym-links so that the file path is consistent.

When granting access does it have to be directly to the folder containing the braw or can it be drive level?

It can just be at the drive level.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[latenitefilms]

Easiest solution would just rename your new drive to be the same name as your old drive, and only have new drive connected. Alternatively another easy workaround would be to export a FCPXML of your entire library, open it in a Text Editor and do a find and replace. If BRAW Toolbox has sandbox access to a drive, it will just use the file path, as opposed to security scoped bookmarks.

[tangierc]

Ok thanks. That takes care of one drive , but my project spans two drives. So when I migrate to the new drive it can only take one name of the two drives it replaces. Won’t an XML big support some generators used in the edit?Lastly, how do I insure that BRAW Toolbox has sandbox access before I start this process and is that even possible?You mentioned using sym links earlier. What’s that process?One other possible solution that I do not think it’s ideal, but I wonder if it would work is if I make disc images of my current two drives, and then move those to the new read. Then those will mount with the same names as the two drives, but will be running from the red. What do you think of that idea? Of course, these would have to be images that can expand. Again, this is not an ideal solution. An ideal solution would be some kind of Way to re-link all of the clips to their source files, no matter which volume that they’re on. TangierOn Apr 3, 2023, at 1:18 PM, Chris Hocking @.***> wrote: Easiest solution would just rename your new drive to be the same name as your old drive, and only have new drive connected. Alternatively another easy workaround would be to export a FCPXML of your entire library, open it in a Text Editor and do a find and replace. If BRAW Toolbox has sandbox access to a drive, it will just use the file path, as opposed to security scoped bookmarks.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[latenitefilms]

Ok thanks. That takes care of one drive , but my project spans two drives. So when I migrate to the new drive it can only take one name of the two drives it replaces.

Ah, I see.

Won’t an XML big support some generators used in the edit?

I'm not exactly sure what you're saying here. FCPXML does have some limitations/issues - but mostly related to titles.

Lastly, how do I insure that BRAW Toolbox has sandbox access before I start this process and is that even possible?

You can just reset the sandbox access, and add the two drives if you want.

You mentioned using sym links earlier. What’s that process?

You can use sym-links to "trick" macOS to thinking something is in one place, when it's actually in another. For example, if at work your media is stored in /Volumes/NAS/MyMedia, but at home your media is stored in /Volumes/DAS/Work/MyMedia, you could create a sym-link so that /Volumes/NAS/MyMedia points to /Volumes/DAS/Work/MyMedia.

One other possible solution that I do not think it’s ideal, but I wonder if it would work is if I make disc images of my current two drives, and then move those to the new read. Then those will mount with the same names as the two drives, but will be running from the red. What do you think of that idea? Of course, these would have to be images that can expand.

This is definitely an option, but as you say, less than ideal.

Again, this is not an ideal solution. An ideal solution would be some kind of Way to re-link all of the clips to their source files, no matter which volume that they’re on.

Agreed - I'll look into ways to improve relinking.

[tangierc]

Thanks Chris. Sorry for the typos. I using Siri to dictate while at the Academy of Motion Picture Museum. I don’t know the XML limitations by heart and coincidentally this project will use Dylan Bates’s (Final Cut Pro) Pro Zoom plugin a lot which uses Motion Titles to achieve what we want.

I haven’t created sym-links on my own to my knowledge so that’s new to me, unless I just didn’t realize it. That process is where I got a little lost in what you’re describing I should do. I assume you mean to ussr the Terminal app. Is this an easy process for all of the clips.

Is improved relinking on the feature request? I don’t want to add something already being discussed. Another editor from Georgia (USA) reached out to me about similar issues today.

Thanks,

Tangier

On Apr 3, 2023, at 7:44 PM, Chris Hocking @.***> wrote:

Ok thanks. That takes care of one drive , but my project spans two drives. So when I migrate to the new drive it can only take one name of the two drives it replaces.

Ah, I see.

Won’t an XML big support some generators used in the edit?

I'm not exactly sure what you're saying here. FCPXML does have some limitations/issues - but mostly related to titles.

Lastly, how do I insure that BRAW Toolbox has sandbox access before I start this process and is that even possible?

You can just reset the sandbox access, and add the two drives if you want.

You mentioned using sym links earlier. What’s that process?

You can use sym-links to "trick" macOS to thinking something is in one place, when it's actually in another. For example, if at work your media is stored in /Volumes/NAS/MyMedia, but at home your media is stored in /Volumes/DAS/Work/MyMedia, you could create a sym-link so that /Volumes/NAS/MyMedia points to /Volumes/DAS/Work/MyMedia.

One other possible solution that I do not think it’s ideal, but I wonder if it would work is if I make disc images of my current two drives, and then move those to the new read. Then those will mount with the same names as the two drives, but will be running from the red. What do you think of that idea? Of course, these would have to be images that can expand.

This is definitely an option, but as you say, less than ideal.

Again, this is not an ideal solution. An ideal solution would be some kind of Way to re-link all of the clips to their source files, no matter which volume that they’re on.

Agreed - I'll look into ways to improve relinking.

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1495260411, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTUJATJEVB7OYQLA73LW7ODHHANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[tangierc]

By the way, I am actually testing the sparse disk image idea while I wrote that last email. It’s not ideal, but I just can’t afford to have the links break again nor relink them one at a time. My new RAID for this project is on its way so I am trying to have an action plan in place and testing.

Thanks Chris

Sincerely,

Tangier

On Apr 3, 2023, at 7:53 PM, Tangier Clarke @.***> wrote:

Thanks Chris. Sorry for the typos. I using Siri to dictate while at the Academy of Motion Picture Museum. I don’t know the XML limitations by heart and coincidentally this project will use Dylan Bates’s (Final Cut Pro) Pro Zoom plugin a lot which uses Motion Titles to achieve what we want.

I haven’t created sym-links on my own to my knowledge so that’s new to me, unless I just didn’t realize it. That process is where I got a little lost in what you’re describing I should do. I assume you mean to ussr the Terminal app. Is this an easy process for all of the clips.

Is improved relinking on the feature request? I don’t want to add something already being discussed. Another editor from Georgia (USA) reached out to me about similar issues today.

Thanks,

Tangier

On Apr 3, 2023, at 7:44 PM, Chris Hocking @.***> wrote:

Ok thanks. That takes care of one drive , but my project spans two drives. So when I migrate to the new drive it can only take one name of the two drives it replaces.

Ah, I see.

Won’t an XML big support some generators used in the edit?

I'm not exactly sure what you're saying here. FCPXML does have some limitations/issues - but mostly related to titles.

Lastly, how do I insure that BRAW Toolbox has sandbox access before I start this process and is that even possible?

You can just reset the sandbox access, and add the two drives if you want.

You mentioned using sym links earlier. What’s that process?

You can use sym-links to "trick" macOS to thinking something is in one place, when it's actually in another. For example, if at work your media is stored in /Volumes/NAS/MyMedia, but at home your media is stored in /Volumes/DAS/Work/MyMedia, you could create a sym-link so that /Volumes/NAS/MyMedia points to /Volumes/DAS/Work/MyMedia.

One other possible solution that I do not think it’s ideal, but I wonder if it would work is if I make disc images of my current two drives, and then move those to the new read. Then those will mount with the same names as the two drives, but will be running from the red. What do you think of that idea? Of course, these would have to be images that can expand.

This is definitely an option, but as you say, less than ideal.

Again, this is not an ideal solution. An ideal solution would be some kind of Way to re-link all of the clips to their source files, no matter which volume that they’re on.

Agreed - I'll look into ways to improve relinking.

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1495260411, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTUJATJEVB7OYQLA73LW7ODHHANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[tangierc]

Chris, I can conform that using Carbon Copy Cloner to make a READ/Write sparse disk image of an APFS volume using the same name worked. Also replacing the directory path of an exported XML worked after importing it into a new library and my Titles were still there. I only tested this on a few clips however. I need to research what FCP XML doesn’t support to figure out what could be lost in the process if I go this route.

Tangier

On Apr 3, 2023, at 7:55 PM, Tangier Clarke @.***> wrote:

By the way, I am actually testing the sparse disk image idea while I wrote that last email. It’s not ideal, but I just can’t afford to have the links break again nor relink them one at a time. My new RAID for this project is on its way so I am trying to have an action plan in place and testing.

Thanks Chris

Sincerely,

Tangier

On Apr 3, 2023, at 7:53 PM, Tangier Clarke @.***> wrote:

Thanks Chris. Sorry for the typos. I using Siri to dictate while at the Academy of Motion Picture Museum. I don’t know the XML limitations by heart and coincidentally this project will use Dylan Bates’s (Final Cut Pro) Pro Zoom plugin a lot which uses Motion Titles to achieve what we want.

I haven’t created sym-links on my own to my knowledge so that’s new to me, unless I just didn’t realize it. That process is where I got a little lost in what you’re describing I should do. I assume you mean to ussr the Terminal app. Is this an easy process for all of the clips.

Is improved relinking on the feature request? I don’t want to add something already being discussed. Another editor from Georgia (USA) reached out to me about similar issues today.

Thanks,

Tangier

On Apr 3, 2023, at 7:44 PM, Chris Hocking @.***> wrote:

Ok thanks. That takes care of one drive , but my project spans two drives. So when I migrate to the new drive it can only take one name of the two drives it replaces.

Ah, I see.

Won’t an XML big support some generators used in the edit?

I'm not exactly sure what you're saying here. FCPXML does have some limitations/issues - but mostly related to titles.

Lastly, how do I insure that BRAW Toolbox has sandbox access before I start this process and is that even possible?

You can just reset the sandbox access, and add the two drives if you want.

You mentioned using sym links earlier. What’s that process?

You can use sym-links to "trick" macOS to thinking something is in one place, when it's actually in another. For example, if at work your media is stored in /Volumes/NAS/MyMedia, but at home your media is stored in /Volumes/DAS/Work/MyMedia, you could create a sym-link so that /Volumes/NAS/MyMedia points to /Volumes/DAS/Work/MyMedia.

One other possible solution that I do not think it’s ideal, but I wonder if it would work is if I make disc images of my current two drives, and then move those to the new read. Then those will mount with the same names as the two drives, but will be running from the red. What do you think of that idea? Of course, these would have to be images that can expand.

This is definitely an option, but as you say, less than ideal.

Again, this is not an ideal solution. An ideal solution would be some kind of Way to re-link all of the clips to their source files, no matter which volume that they’re on.

Agreed - I'll look into ways to improve relinking.

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1495260411, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTUJATJEVB7OYQLA73LW7ODHHANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[latenitefilms]

Regarding:

Hey Chris. I thought I'd send you a screen recording. I am really nervous about the inability to relink all of my braw clips if I move the content to a larger and faster drive.

In the video you are seeing an FCP library and files that I first created on the SSD of my MBP M2 Max, but migrated to my OWC RAID. I made sure to delete the copy on the SSD so that it was the files weren't present for FCP to find.

Am I misunderstanding how grant access should work? My hop was that if I do it one BRAW Toolbox clip the rest will update. Having to manually relink every shot would cause a huge delay in time for this project due to the number of clips.

Granting sandbox access, just gives Final Cut Pro direct access to a file, without needing security scoped bookmarks. For example, if you're on a laptop, and import some BRAW clips from an external SSD called "SSD", the path to the BRAW file might be /Volumes/SSD/clip1.braw. When you import BRAW clips using the Workflow Extension, the users act of dragging a BRAW file into the Workflow Extension, or by importing a clip via the Import BRAW Files button basically tells macOS that BRAW Toolbox has permission to that file, and gives us, what's called a security scoped bookmark - essentially a special code that we can later use to access that same same file on the same machine. So now, on the laptop, for each frame, rather than BRAW Toolbox asking macOS for /Volumes/SSD/clip1.braw, we actually just give it the "secret code" (aka the security scoped bookmark) and it gives us access to the file, without any discussion of the actual file path. This is how you can, for example, move media around at the Finder level on an open Final Cut Pro Library, and things magically stayed linked - it's not referencing a "path" - instead internally Final Cut Pro is dealing with bookmarks.

Now let's say you connect that SSD onto another machine - lets call it your iMac. Unfortunately when you open the Final Cut Pro library, all the BRAW clips will now say "Missing BRAW File - The Security-Scoped Bookmark could not be resolved". This is a security protection on the macOS side - to prevent the user from opening dodgy files from another machine. So now, our security-scoped bookmark is invalid. However, if you Grant Sandbox Access to the SSD, if BRAW Toolbox can't resolve the security-scoped bookmark (i.e. macOS is rejecting the "secret code") - but it has read access to the SSD, it'll instead use the path, and you're all good to go.

Long story short - this is generally how we recommend handling collaboration with BRAW Toolbox. Keep the file paths the same between machines, and use the Grant Sandbox Access feature. It keeps things simple.

So how does Apple get around these limitations? Well... they break their own rules. Final Cut Pro isn't actually sandboxed. It's one of the very few apps on the Mac App Store that's not sandboxed. This goes against their own App Store policies, but hey, they own the App Store.

The Relink BRAW Clips within an EVENT toolbox attempts to get around this issue, by allowing you to adjust file paths and create new security-scoped bookmarks.

For example, lets say I have an event, and all the media is showing "Missing BRAW File - The Security-Scoped Bookmark could not be resolved", because I've moved it to another machine.

When I drag that event into the Relink BRAW Clips within an EVENT toolbox, I'm presented with:

In this case, the path is actually correct - BRAW Toolbox just doesn't have sandbox access to those files.

So I click Refresh & Request Permissions. I'm presented with a dialog box accessing for access to my Desktop, which I allow.

Now I get:

I can now click the Relink BRAW Files button to generate a new FCPXML. I now get this:

When I drag the icon into the Final Cut Pro library, I now have two events - the original event with the offline media, and a new event with the "fixed" media:

Now the reason I said this was a "worse case scenario" tool is because in the current implementation, you end up with two events, and if you want your project/timeline to relink to the new media, it needs to be in the same event that you dragged in. So if you've got BRAW files in lots of different events, and you have your projects/timelines in another event - this won't really solve your issue.

Is improved relinking on the feature request? I don’t want to add something already being discussed. Another editor from Georgia (USA) reached out to me about similar issues today.

Given all of the above - yes, I think we definitely need to make relinking a LOT easier - it's just quite technically challenging because of the locked down and secured nature of the Mac App Store. Also, because the only way we can really "communicate" with Final Cut Pro libraries is via FCPXML - it gets complicated, because FCPXML has its own set of bugs and limitations.

For example: https://github.com/CommandPost/FinalCutPro/issues/3

Regardless, I'll do my best to try and make it a lot easier/simpler as quickly as I can.

[tangierc]

Thanks for the detailed reply. I completely get and follow all of it and understand the problem with having duplicate events. Granting access didn’t work for me and I’d usually just have to manually relink every clip from the inspector. Often it will green light only some clips even though all of the clips are in the same directory. I only got that feature to work one time. Something else I’ve noticed is a sort of delay to wait for FCP to work m. There has been times when things still seem offline, I’ll keep repeating ting attempts at any relinking process by granting access or the relink toolbox. Nothing changes. I restart the computer then launch the library and offline clips magically appear. FCP hasn’t always been great at feedback to let one know what it’s doing and I listen to my drives closely.I’ll keep monitoring my process.Thanks.TangierOn Apr 4, 2023, at 12:17 AM, Chris Hocking @.***> wrote: Regarding:

Hey Chris. I thought I'd send you a screen recording. I am really nervous about the inability to relink all of my braw clips if I move the content to a larger and faster drive. In the video you are seeing an FCP library and files that I first created on the SSD of my MBP M2 Max, but migrated to my OWC RAID. I made sure to delete the copy on the SSD so that it was the files weren't present for FCP to find. Am I misunderstanding how grant access should work? My hop was that if I do it one BRAW Toolbox clip the rest will update. Having to manually relink every shot would cause a huge delay in time for this project due to the number of clips.

Granting sandbox access, just gives Final Cut Pro direct access to a file, without needing security scoped bookmarks. For example, if you're on a laptop, and import some BRAW clips from an external SSD called "SSD", the path to the BRAW file might be /Volumes/SSD/clip1.braw. When you import BRAW clips using the Workflow Extension, the users act of dragging a BRAW file into the Workflow Extension, or by importing a clip via the Import BRAW Files button basically tells macOS that BRAW Toolbox has permission to that file, and gives us, what's called a security scoped bookmark - essentially a special code that we can later use to access that same same file on the same machine. So now, on the laptop, for each frame, rather than BRAW Toolbox asking macOS for /Volumes/SSD/clip1.braw, we actually just give it the "secret code" (aka the security scoped bookmark) and it gives us access to the file, without any discussion of the actual file path. This is how you can, for example, move media around at the Finder level on an open Final Cut Pro Library, and things magically stayed linked - it's not referencing a "path" - instead internally Final Cut Pro is dealing with bookmarks. Now let's say you connect that SSD onto another machine - lets call it your iMac. Unfortunately when you open the Final Cut Pro library, all the BRAW clips will now say "Missing BRAW File - The Security-Scoped Bookmark could not be resolved". This is a security protection on the macOS side - to prevent the user from opening dodgy files from another machine. So now, our security-scoped bookmark is invalid. However, if you Grant Sandbox Access to the SSD, if BRAW Toolbox can't resolve the security-scoped bookmark (i.e. macOS is rejecting the "secret code") - but it has read access to the SSD, it'll instead use the path, and you're all good to go. Long story short - this is generally how we recommend handling collaboration with BRAW Toolbox. Keep the file paths the same between machines, and use the Grant Sandbox Access feature. It keeps things simple. So how does Apple get around these limitations? Well... they break their own rules. Final Cut Pro isn't actually sandboxed. It's one of the very few apps on the Mac App Store that's not sandboxed. This goes against their own App Store policies, but hey, they own the App Store. The Relink BRAW Clips within an EVENT toolbox attempts to get around this issue, by allowing you to adjust file paths and create new security-scoped bookmarks. For example, lets say I have an event, and all the media is showing "Missing BRAW File - The Security-Scoped Bookmark could not be resolved", because I've moved it to another machine.

When I drag that event into the Relink BRAW Clips within an EVENT toolbox, I'm presented with:

In this case, the path is actually correct - BRAW Toolbox just doesn't have sandbox access to those files. So I click Refresh & Request Permissions. I'm presented with a dialog box accessing for access to my Desktop, which I allow. Now I get:

I can now click the Relink BRAW Files button to generate a new FCPXML. I now get this:

When I drag the icon into the Final Cut Pro library, I now have two events - the original event with the offline media, and a new event with the "fixed" media:

Now the reason I said this was a "worse case scenario" tool is because in the current implementation, you end up with two events, and if you want your project/timeline to relink to the new media, it needs to be in the same event that you dragged in. So if you've got BRAW files in lots of different events, and you have your projects/timelines in another event - this won't really solve your issue.

Is improved relinking on the feature request? I don’t want to add something already being discussed. Another editor from Georgia (USA) reached out to me about similar issues today.

Given all of the above - yes, I think we definitely need to make relinking a LOT easier - it's just quite technically challenging because of the locked down and secured nature of the Mac App Store. Also, because the only way we can really "communicate" with Final Cut Pro libraries is via FCPXML - it gets complicated, because FCPXML has its own set of bugs and limitations. For example: CommandPost/FinalCutPro#3 Regardless, I'll do my best to try and make it a lot easier/simpler as quickly as I can.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[tangierc]

Chris, I reread your email. I haven’t changed drives or location of my library and many of my braw clips have the security issue. I granted access and nothing happens. Something could be happening, but it’d be unknown to the user. None of the clips were updating playback ability. They stayed with the red alert. I then reset the access. Everything went offline. I went to one of my events that has content on my secondary drive, granted access for one of the clips for that and other clips started to update. Even the ones on Drive 1 that were offline. Though not all of them were fixed between the browser and the timeline.

Some timeline clips will have the security alert, but a Reveal in Finder will show that it’s linked and playable (see pic). Sometimes playing the clip in the timeline will cause FCP to flicker between the security alert and the actual playback. Yet in the browser the same clip from a reveal in finder plays just fine. Just trying to get my project to full connected health. It seems exporting the entire project as an XML, modifying the directories and bringing it back in may be the only way, but any attempt of any kind leaves me unsure if something else will break.

This got me to thinking. A user can only grant access to one drive at a time. Some events may have footage bound to one drive and other events to another drive. When granting access to one drive it seems that technically I am only granting access for the content to that drive. If I grant access again for other events on another drive, does that negate the first granting of access. Can you build a library level access whereas a user a say, this library is granted access to multiple drives. The dialogue window for granting access doesn’t allow multiple selections so it’s really unclear how this entire process is working. 

Tangier

On Apr 4, 2023, at 7:10 AM, TC Gmail @.***> wrote:

Thanks for the detailed reply. I completely get and follow all of it and understand the problem with having duplicate events. Granting access didn’t work for me and I’d usually just have to manually relink every clip from the inspector. Often it will green light only some clips even though all of the clips are in the same directory. I only got that feature to work one time. Something else I’ve noticed is a sort of delay to wait for FCP to work m. There has been times when things still seem offline, I’ll keep repeating ting attempts at any relinking process by granting access or the relink toolbox. Nothing changes. I restart the computer then launch the library and offline clips magically appear. FCP hasn’t always been great at feedback to let one know what it’s doing and I listen to my drives closely.

I’ll keep monitoring my process.

Thanks.

Tangier

On Apr 4, 2023, at 12:17 AM, Chris Hocking @.***> wrote:



Regarding:

Hey Chris. I thought I'd send you a screen recording. I am really nervous about the inability to relink all of my braw clips if I move the content to a larger and faster drive.

In the video you are seeing an FCP library and files that I first created on the SSD of my MBP M2 Max, but migrated to my OWC RAID. I made sure to delete the copy on the SSD so that it was the files weren't present for FCP to find.

Am I misunderstanding how grant access should work? My hop was that if I do it one BRAW Toolbox clip the rest will update. Having to manually relink every shot would cause a huge delay in time for this project due to the number of clips.

Granting sandbox access, just gives Final Cut Pro direct access to a file, without needing security scoped bookmarks. For example, if you're on a laptop, and import some BRAW clips from an external SSD called "SSD", the path to the BRAW file might be /Volumes/SSD/clip1.braw. When you import BRAW clips using the Workflow Extension, the users act of dragging a BRAW file into the Workflow Extension, or by importing a clip via the Import BRAW Files button basically tells macOS that BRAW Toolbox has permission to that file, and gives us, what's called a security scoped bookmark - essentially a special code that we can later use to access that same same file on the same machine. So now, on the laptop, for each frame, rather than BRAW Toolbox asking macOS for /Volumes/SSD/clip1.braw, we actually just give it the "secret code" (aka the security scoped bookmark) and it gives us access to the file, without any discussion of the actual file path. This is how you can, for example, move media around at the Finder level on an open Final Cut Pro Library, and things magically stayed linked - it's not referencing a "path" - instead internally Final Cut Pro is dealing with bookmarks.

Now let's say you connect that SSD onto another machine - lets call it your iMac. Unfortunately when you open the Final Cut Pro library, all the BRAW clips will now say "Missing BRAW File - The Security-Scoped Bookmark could not be resolved". This is a security protection on the macOS side - to prevent the user from opening dodgy files from another machine. So now, our security-scoped bookmark is invalid. However, if you Grant Sandbox Access to the SSD, if BRAW Toolbox can't resolve the security-scoped bookmark (i.e. macOS is rejecting the "secret code") - but it has read access to the SSD, it'll instead use the path, and you're all good to go.

Long story short - this is generally how we recommend handling collaboration with BRAW Toolbox. Keep the file paths the same between machines, and use the Grant Sandbox Access feature. It keeps things simple.

So how does Apple get around these limitations? Well... they break their own rules. Final Cut Pro isn't actually sandboxed. It's one of the very few apps on the Mac App Store that's not sandboxed. This goes against their own App Store policies, but hey, they own the App Store.

The Relink BRAW Clips within an EVENT toolbox attempts to get around this issue, by allowing you to adjust file paths and create new security-scoped bookmarks.

For example, lets say I have an event, and all the media is showing "Missing BRAW File - The Security-Scoped Bookmark could not be resolved", because I've moved it to another machine.

https://user-images.githubusercontent.com/22286696/229713198-a9312e2b-0239-4862-8098-35ed620a7eb4.png When I drag that event into the Relink BRAW Clips within an EVENT toolbox, I'm presented with:

https://user-images.githubusercontent.com/22286696/229713324-fee396ca-8ae0-4f4c-89b5-1f55f7a7ddcb.png In this case, the path is actually correct - BRAW Toolbox just doesn't have sandbox access to those files.

So I click Refresh & Request Permissions. I'm presented with a dialog box accessing for access to my Desktop, which I allow.

Now I get:

https://user-images.githubusercontent.com/22286696/229713571-3b91b772-6b27-4f9d-ad28-1a76fc09051a.png I can now click the Relink BRAW Files button to generate a new FCPXML. I now get this:

https://user-images.githubusercontent.com/22286696/229713752-8445b42b-2675-445c-89da-e49bd89f9da0.png When I drag the icon into the Final Cut Pro library, I now have two events - the original event with the offline media, and a new event with the "fixed" media:

https://user-images.githubusercontent.com/22286696/229714048-20da46cc-730c-403e-aa3f-138ac2191846.png Now the reason I said this was a "worse case scenario" tool is because in the current implementation, you end up with two events, and if you want your project/timeline to relink to the new media, it needs to be in the same event that you dragged in. So if you've got BRAW files in lots of different events, and you have your projects/timelines in another event - this won't really solve your issue.

Is improved relinking on the feature request? I don’t want to add something already being discussed. Another editor from Georgia (USA) reached out to me about similar issues today.

Given all of the above - yes, I think we definitely need to make relinking a LOT easier - it's just quite technically challenging because of the locked down and secured nature of the Mac App Store. Also, because the only way we can really "communicate" with Final Cut Pro libraries is via FCPXML - it gets complicated, because FCPXML has its own set of bugs and limitations.

For example: CommandPost/FinalCutPro#3 https://github.com/CommandPost/FinalCutPro/issues/3 Regardless, I'll do my best to try and make it a lot easier/simpler as quickly as I can.

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1495467908, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTWRPA6DQWRDRIXXTDLW7PDI3ANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[tangierc]

I think some of this may be nothing you can control Chris, but is Apple’s doing. It’s unnerving. I’ll go over a clip in the timeline that shows with the security issue then scroll and come back and then it plays just fine with the security alter no longer there. Not all clips, but some.

Tangier

On Apr 4, 2023, at 3:42 PM, Tangier Clarke @.***> wrote:

Chris, I reread your email. I haven’t changed drives or location of my library and many of my braw clips have the security issue. I granted access and nothing happens. Something could be happening, but it’d be unknown to the user. None of the clips were updating playback ability. They stayed with the red alert. I then reset the access. Everything went offline. I went to one of my events that has content on my secondary drive, granted access for one of the clips for that and other clips started to update. Even the ones on Drive 1 that were offline. Though not all of them were fixed between the browser and the timeline.

Some timeline clips will have the security alert, but a Reveal in Finder will show that it’s linked and playable (see pic). Sometimes playing the clip in the timeline will cause FCP to flicker between the security alert and the actual playback. Yet in the browser the same clip from a reveal in finder plays just fine. Just trying to get my project to full connected health. It seems exporting the entire project as an XML, modifying the directories and bringing it back in may be the only way, but any attempt of any kind leaves me unsure if something else will break.

This got me to thinking. A user can only grant access to one drive at a time. Some events may have footage bound to one drive and other events to another drive. When granting access to one drive it seems that technically I am only granting access for the content to that drive. If I grant access again for other events on another drive, does that negate the first granting of access. Can you build a library level access whereas a user a say, this library is granted access to multiple drives. The dialogue window for granting access doesn’t allow multiple selections so it’s really unclear how this entire process is working. <Screenshot 2023-04-04 at 3.38.42 PM.png>

Tangier

On Apr 4, 2023, at 7:10 AM, TC Gmail @.***> wrote:

Thanks for the detailed reply. I completely get and follow all of it and understand the problem with having duplicate events. Granting access didn’t work for me and I’d usually just have to manually relink every clip from the inspector. Often it will green light only some clips even though all of the clips are in the same directory. I only got that feature to work one time. Something else I’ve noticed is a sort of delay to wait for FCP to work m. There has been times when things still seem offline, I’ll keep repeating ting attempts at any relinking process by granting access or the relink toolbox. Nothing changes. I restart the computer then launch the library and offline clips magically appear. FCP hasn’t always been great at feedback to let one know what it’s doing and I listen to my drives closely.

I’ll keep monitoring my process.

Thanks.

Tangier

On Apr 4, 2023, at 12:17 AM, Chris Hocking @.***> wrote:



Regarding:

Hey Chris. I thought I'd send you a screen recording. I am really nervous about the inability to relink all of my braw clips if I move the content to a larger and faster drive.

In the video you are seeing an FCP library and files that I first created on the SSD of my MBP M2 Max, but migrated to my OWC RAID. I made sure to delete the copy on the SSD so that it was the files weren't present for FCP to find.

Am I misunderstanding how grant access should work? My hop was that if I do it one BRAW Toolbox clip the rest will update. Having to manually relink every shot would cause a huge delay in time for this project due to the number of clips.

Granting sandbox access, just gives Final Cut Pro direct access to a file, without needing security scoped bookmarks. For example, if you're on a laptop, and import some BRAW clips from an external SSD called "SSD", the path to the BRAW file might be /Volumes/SSD/clip1.braw. When you import BRAW clips using the Workflow Extension, the users act of dragging a BRAW file into the Workflow Extension, or by importing a clip via the Import BRAW Files button basically tells macOS that BRAW Toolbox has permission to that file, and gives us, what's called a security scoped bookmark - essentially a special code that we can later use to access that same same file on the same machine. So now, on the laptop, for each frame, rather than BRAW Toolbox asking macOS for /Volumes/SSD/clip1.braw, we actually just give it the "secret code" (aka the security scoped bookmark) and it gives us access to the file, without any discussion of the actual file path. This is how you can, for example, move media around at the Finder level on an open Final Cut Pro Library, and things magically stayed linked - it's not referencing a "path" - instead internally Final Cut Pro is dealing with bookmarks.

Now let's say you connect that SSD onto another machine - lets call it your iMac. Unfortunately when you open the Final Cut Pro library, all the BRAW clips will now say "Missing BRAW File - The Security-Scoped Bookmark could not be resolved". This is a security protection on the macOS side - to prevent the user from opening dodgy files from another machine. So now, our security-scoped bookmark is invalid. However, if you Grant Sandbox Access to the SSD, if BRAW Toolbox can't resolve the security-scoped bookmark (i.e. macOS is rejecting the "secret code") - but it has read access to the SSD, it'll instead use the path, and you're all good to go.

Long story short - this is generally how we recommend handling collaboration with BRAW Toolbox. Keep the file paths the same between machines, and use the Grant Sandbox Access feature. It keeps things simple.

So how does Apple get around these limitations? Well... they break their own rules. Final Cut Pro isn't actually sandboxed. It's one of the very few apps on the Mac App Store that's not sandboxed. This goes against their own App Store policies, but hey, they own the App Store.

The Relink BRAW Clips within an EVENT toolbox attempts to get around this issue, by allowing you to adjust file paths and create new security-scoped bookmarks.

For example, lets say I have an event, and all the media is showing "Missing BRAW File - The Security-Scoped Bookmark could not be resolved", because I've moved it to another machine.

https://user-images.githubusercontent.com/22286696/229713198-a9312e2b-0239-4862-8098-35ed620a7eb4.png When I drag that event into the Relink BRAW Clips within an EVENT toolbox, I'm presented with:

https://user-images.githubusercontent.com/22286696/229713324-fee396ca-8ae0-4f4c-89b5-1f55f7a7ddcb.png In this case, the path is actually correct - BRAW Toolbox just doesn't have sandbox access to those files.

So I click Refresh & Request Permissions. I'm presented with a dialog box accessing for access to my Desktop, which I allow.

Now I get:

https://user-images.githubusercontent.com/22286696/229713571-3b91b772-6b27-4f9d-ad28-1a76fc09051a.png I can now click the Relink BRAW Files button to generate a new FCPXML. I now get this:

https://user-images.githubusercontent.com/22286696/229713752-8445b42b-2675-445c-89da-e49bd89f9da0.png When I drag the icon into the Final Cut Pro library, I now have two events - the original event with the offline media, and a new event with the "fixed" media:

https://user-images.githubusercontent.com/22286696/229714048-20da46cc-730c-403e-aa3f-138ac2191846.png Now the reason I said this was a "worse case scenario" tool is because in the current implementation, you end up with two events, and if you want your project/timeline to relink to the new media, it needs to be in the same event that you dragged in. So if you've got BRAW files in lots of different events, and you have your projects/timelines in another event - this won't really solve your issue.

Is improved relinking on the feature request? I don’t want to add something already being discussed. Another editor from Georgia (USA) reached out to me about similar issues today.

Given all of the above - yes, I think we definitely need to make relinking a LOT easier - it's just quite technically challenging because of the locked down and secured nature of the Mac App Store. Also, because the only way we can really "communicate" with Final Cut Pro libraries is via FCPXML - it gets complicated, because FCPXML has its own set of bugs and limitations.

For example: CommandPost/FinalCutPro#3 https://github.com/CommandPost/FinalCutPro/issues/3 Regardless, I'll do my best to try and make it a lot easier/simpler as quickly as I can.

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1495467908, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTWRPA6DQWRDRIXXTDLW7PDI3ANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[latenitefilms]

I think some of this may be nothing you can control Chris, but is Apple’s doing. It’s unnerving. I’ll go over a clip in the timeline that shows with the security issue then scroll and come back and then it plays just fine with the security alter no longer there. Not all clips, but some.

Is it just a matter of the thumbnails in the viewer being incorrect - but when you "hover" over the clips, they're correct in the Viewer?

[tangierc]

Sending you a quicktime in just a sec. It can show it better than I can explain it. Performance may be slow as revealed in the Quicktime because this project is on two USB-C 3.1 Gen 2 drives given to me (which is why I am moving the project to a single Thunderbolt 3 RAID) and I have Compressor working hard in the background making proxies on some ProRes files. There’s a lot more clips having this issue. In 15 minutes I’ll restart the computer. I’ve seen things change after just doing that.

This is an MBP M2 Max by the way.

Tangier

On Apr 4, 2023, at 4:28 PM, Chris Hocking @.***> wrote:

I think some of this may be nothing you can control Chris, but is Apple’s doing. It’s unnerving. I’ll go over a clip in the timeline that shows with the security issue then scroll and come back and then it plays just fine with the security alter no longer there. Not all clips, but some.

Is it just a matter of the thumbnails in the viewer being incorrect - but when you "hover" over the clips, they're correct in the Viewer?

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1496720600, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTWJSG2JWTTJFH53JZDW7SVC5ANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[tangierc]

I forgot to mention that the reason I have the playback in proxy preferred is so that FCP plays my Red proxies and plays the originals at 1/8th quality of the BRAW toolbox clips.

Tangier

On Apr 4, 2023, at 6:10 PM, Tangier Clarke @.***> wrote:

Sending you a quicktime in just a sec. It can show it better than I can explain it. Performance may be slow as revealed in the Quicktime because this project is on two USB-C 3.1 Gen 2 drives given to me (which is why I am moving the project to a single Thunderbolt 3 RAID) and I have Compressor working hard in the background making proxies on some ProRes files. There’s a lot more clips having this issue. In 15 minutes I’ll restart the computer. I’ve seen things change after just doing that.

This is an MBP M2 Max by the way.

Tangier

On Apr 4, 2023, at 4:28 PM, Chris Hocking @.***> wrote:

I think some of this may be nothing you can control Chris, but is Apple’s doing. It’s unnerving. I’ll go over a clip in the timeline that shows with the security issue then scroll and come back and then it plays just fine with the security alter no longer there. Not all clips, but some.

Is it just a matter of the thumbnails in the viewer being incorrect - but when you "hover" over the clips, they're correct in the Viewer?

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1496720600, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTWJSG2JWTTJFH53JZDW7SVC5ANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[latenitefilms]

Just watched the video - yeah, that's really weird.

What happens if you do some colour adjustments on the clips that have the "Missing BRAW File" message? Do they then show the correct frames, or does it colour correct the "Missing BRAW File" image?

I'm assuming you've already granted sandbox access to the drive containing the footage?

Given your audio wave forms are taking so long to update - my GUESS is that maybe Final Cut Pro is used older/cached frames (i.e. at a point where they were offline), and isn't updating the images in the timeline because it's still trying to catch up on all the waveform and thumbnails?

[tangierc]

Color correction didn’t do anything for that one clip at 00:02:48:11. It continued to flicker between missing and the footage. also granted access again after going inside that clip and selecting the braw toolbox component to reveal the global settings inspector.

I’ve going back through some clips in the browser and just manually relinked the ones that were missing with the security issue. They were still had the missing icon, but I just adjusted the scale a little and back to the lowest setting and they were fine. When I grant access, I think I expect to see an immediate change, but I don’t so it’s not clear what’s happening. The timeline definitely behaves differently than the browser.

Thanks,

Tangier

On Apr 4, 2023, at 7:07 PM, Chris Hocking @.***> wrote:

Just watched the video - yeah, that's really weird.

What happens if you do some colour adjustments on the clips that have the "Missing BRAW File" message? Do they then show the correct frames, or does it colour correct the "Missing BRAW File" image?

I'm assuming you've already granted sandbox access to the drive containing the footage?

Given your audio wave forms are taking so long to update - my GUESS is that maybe Final Cut Pro is used older/cached frames (i.e. at a point where they were offline), and isn't updating the images in the timeline because it's still trying to catch up on all the waveform and thumbnails?

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1496823316, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTSQAJ4LNMR52CCJBWTW7THURANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[tangierc]

I just went back to that same clip on the timeline and manually relinked it. It works now in the timeline.

Tangier

On Apr 4, 2023, at 7:30 PM, Tangier Clarke @.***> wrote:

Color correction didn’t do anything for that one clip at 00:02:48:11. It continued to flicker between missing and the footage. also granted access again after going inside that clip and selecting the braw toolbox component to reveal the global settings inspector.

I’ve going back through some clips in the browser and just manually relinked the ones that were missing with the security issue. They were still had the missing icon, but I just adjusted the scale a little and back to the lowest setting and they were fine. When I grant access, I think I expect to see an immediate change, but I don’t so it’s not clear what’s happening. The timeline definitely behaves differently than the browser.

Thanks,

Tangier

On Apr 4, 2023, at 7:07 PM, Chris Hocking @.***> wrote:

Just watched the video - yeah, that's really weird.

What happens if you do some colour adjustments on the clips that have the "Missing BRAW File" message? Do they then show the correct frames, or does it colour correct the "Missing BRAW File" image?

I'm assuming you've already granted sandbox access to the drive containing the footage?

Given your audio wave forms are taking so long to update - my GUESS is that maybe Final Cut Pro is used older/cached frames (i.e. at a point where they were offline), and isn't updating the images in the timeline because it's still trying to catch up on all the waveform and thumbnails?

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1496823316, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTSQAJ4LNMR52CCJBWTW7THURANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[latenitefilms]

I wonder if just changing any RAW parameter for those clips is enough to trick Final Cut Pro into trashing its internal image cache?

[tangierc]

I’ll give that a try. Can you tell me what to expect to happen when granting sandbox access? Should all other clips auto update?

I am testing a library with 4 clips between drives. In list view the braw looks like regular clips (no synced icon) In icon view the braw clips have the synced icon I go into one clip, the braw toolbox effect, global settings and grant access to the a local folder that contains a copy of the same braw files that made this library on another drive. Nothing updates, nothing changes. I adjust the icon view height and timing with no results. "Show parameters" hasn’t been working for any of my clips. Nothing happens when I click it.

Thanks. 

Tangier

On Apr 4, 2023, at 7:41 PM, Chris Hocking @.***> wrote:

I wonder if just changing any RAW parameter for those clips is enough to trick Final Cut Pro into trashing its internal image cache?

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1496841564, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTSPORU23P2GMGF6KNLW7TLUBANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[latenitefilms]

Granting sandbox access just gives FCPX explicit read access to whatever drive/folder you select. You won't see any instant changes - but the next time FCPX tries to render a frame that it previously didn't have sandbox access too, it'll now work. So, for example, if you're moving a library from one Mac to another, but all the footage is stored on the same external drive, if you grant sandbox access to that drive on the new machine before you open the library, everything should work out of the box. However if you open the library before granting sandbox access, any thumbnails FCPX renders will be error messages, and granting sandbox access after the fact won't instantly fix those thumbnails - you'll need to force FCPX to rebuild them.

[tangierc]

Understood. I don’t have that particular issue since I am not moving the library to a new computer. I am only moving the media. How would you grant access to BRAW Toolbox before opening the library? The only way I know to grant access is by going launching a library and going inside a clip to reveal that feature in the inspector. The application islet only has Install Motion Templates, Install LUTs, Metadataview, and Launch Final Cut Pro. If I were to launch Final Cut Pro it would open the last library I worked on automatically so the only way I can see doing this is to OPTION+Launch Final Cut Pro to force it not to launch my library, open the workflow extension, then granting access.

I don’t know if this solves my particular issue since I won’t be moving the library, but I am curious how one grants access before launching the library.

Something I noticed also as I wrote this is I launched the BRAW Toolbox app to see if there was a grant access option, is that Install Motion Template and Install LUTs were available for me to install instead of greyed out like the mediate view. I’ve already installed those when I installed BRAW Toolbox, so I found it strange that they weren’t greyed out. Would this have anything to do with why my “Show Parameters” doesn’t work? Even after clicking install on both of them only the LUTs installed goes greyed out afterward.

Tangier

On Apr 8, 2023, at 3:23 AM, Chris Hocking @.***> wrote:

Granting sandbox access just gives FCPX explicit read access to whatever drive/folder you select. You won't see any instant changes - but the next time FCPX tries to render a frame that it previously didn't have sandbox access too, it'll now work. So, for example, if you're moving a library from one Mac to another, but all the footage is stored on the same external drive, if you grant sandbox access to that drive on the new machine before you open the library, everything should work out of the box. However if you open the library before granting sandbox access, any thumbnails FCPX renders will be error messages, and granting sandbox access after the fact won't instantly fix those thumbnails - you'll need to force FCPX to rebuild them.

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1500860957, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTRFWBXF3FCFTIW4TT3XAE4CZANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[latenitefilms]

How would you grant access to BRAW Toolbox before opening the library?

The only way to do this is by the Global Settings button in the Inspector, so one way would be to just open up a dummy library, apply a BRAW Toolbox effect to something, then Grant Sandbox Access, and close the dummy library. Unfortunately I can't add the Grant Sandbox Access button to the Workflow Extension or the main installation application because they're technically seperate applications.

Something I noticed also as I wrote this is I launched the BRAW Toolbox app to see if there was a grant access option, is that Install Motion Template and Install LUTs were available for me to install instead of greyed out like the mediate view.

Ummm, that's strange. Were you previously using any of the BRAW Toolbox TestFlight betas on this machine, or has it's always just been the public version from the Mac App Store? I don't believe I've updated the Motion Templates, LUTs or Custom Metadata Views since v1.0.0 was released, so installing again shouldn't break anything - but it's odd that if after installing, they don't go grey and stay grey.

Any clues in this file?

/Users/YOUR-USER-NAME-GOES-HERE/Library/Group Containers/A5HDJTY9X5.com.latenitefilms.BRAWToolbox/Library/Application Support/Wrapper Application.log

Would this have anything to do with why my “Show Parameters” doesn’t work?

Based on all the information you've provided I think maybe Show Parameters might not work if Final Cut Pro only has access to the BRAW file via the Grant Sandbox Access feature (as opposed to using Security Scoped Bookmarks) - which would be a bug. I'll do some digging.

I'm guessing you might find a [BRAW Toolbox Renderer] FATAL ERROR: Failed to open IBlackmagicRawClip in parameterChanged. error in this log file after pressing Show Parameters:

/Users/YOUR-USER-NAME-GOES-HERE/Library/Group Containers/A5HDJTY9X5.com.latenitefilms.BRAWToolbox/Library/Application Support/FxPlug.log

I'll try reproduce and come up with a fix ASAP.

[tangierc]

The TestFlight betas were on my 2013 Mac Pro, not this computer. I sent the logs over for review. I didn’t find any red flags in the first one but found 24 error in the second log.

Tangier

On Apr 8, 2023, at 2:11 PM, Chris Hocking @.***> wrote:

How would you grant access to BRAW Toolbox before opening the library?

The only way to do this is by the Global Settings button in the Inspector, so one way would be to just open up a dummy library, apply a BRAW Toolbox effect to something, then Grant Sandbox Access, and close the dummy library. Unfortunately I can't add the Grant Sandbox Access button to the Workflow Extension or the main installation application because they're technically seperate applications.

Something I noticed also as I wrote this is I launched the BRAW Toolbox app to see if there was a grant access option, is that Install Motion Template and Install LUTs were available for me to install instead of greyed out like the mediate view.

Ummm, that's strange. Were you previously using any of the BRAW Toolbox TestFlight betas on this machine, or has it's always just been the public version from the Mac App Store? I don't believe I've updated the Motion Templates, LUTs or Custom Metadata Views since v1.0.0 was released, so installing again shouldn't break anything - but it's odd that if after installing, they don't go grey and stay grey.

Any clues in this file?

/Users/YOUR-USER-NAME-GOES-HERE/Library/Group Containers/A5HDJTY9X5.com.latenitefilms.BRAWToolbox/Library/Application Support/Wrapper Application.log

Would this have anything to do with why my “Show Parameters” doesn’t work?

Based on all the information you've provided I think maybe Show Parameters might not work if Final Cut Pro only has access to the BRAW file via the Grant Sandbox Access feature (as opposed to using Security Scoped Bookmarks) - which would be a bug. I'll do some digging.

I'm guessing you might find a [BRAW Toolbox Renderer] FATAL ERROR: Failed to open IBlackmagicRawClip in parameterChanged. error in this log file after pressing Show Parameters:

/Users/YOUR-USER-NAME-GOES-HERE/Library/Group Containers/A5HDJTY9X5.com.latenitefilms.BRAWToolbox/Library/Application Support/FxPlug.log

I'll try reproduce and come up with a fix ASAP.

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1500978569, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTQ53OKQKM4MDOKVMW3XAHH67ANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[tangierc]

Hey Chris, just bringing this up because of something that just happened. I got the NO BRAW File Selected message again on clips I just imported with BRAW Toolbox version 1.08 on my M2 Max running Ventura 13.3.1.

I’ve seen this happen before and I have yet to ever use an BRAW Toolbox as an effect. This happened directly after preparing the clips dragging over the event. I restarted my computer because there have been times when I have problems with my timeline clips appearing between FCP launches. I will restart and then they’ll appear. This time they did not. So after importing the clips BRAW Toolbox did not display them or make them playable at all which is so strange.

I didn’t upgrade to 1.1.0 because it seems like using BRAW Toolbox is incredibly fragile for me and I don’t see changes when I grant access. I am stuck always having to select / relink braw clips individually. I am terrified of things breaking since I have so much time already invested in this current project.

Wish I could offer more distinct details, but this was with a new library and a fresh import that I got the No BRAW File Selected message.

Tangier

On Apr 2, 2023, at 4:40 AM, Chris Hocking @.***> wrote:

Again, apologies for the delayed reply!

No BRAW File Selected should only really ever appear if you manually apply a BRAW Toolbox effect (this will be the default image). The only other way it could appear is if you click the Select BRAW File button on an already imported clip, and then something goes wrong.

Are you sure you haven't accidentally added the BRAW Toolbox effect manually to the clips?

The screenshots in your first post show an error message from Final Cut Pro essentially saying it can't load the BRAW Toolbox effect. This could either be because the FxPlug4 effect hasn't loaded properly, or it's failing to open the Apple Motion template for whatever reason.

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1493307999, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTQSAX3O4LS4HSHOSB3W7FJRLANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[tangierc]

Chris here’s another interesting find, but I don’t know if it’ll help. I was actually setting up a fresh library in FCP and a new project in Resolve with the intent of comparing the performance of the scrubbing / playback of braw clips in each app. I was using the same source braw clips for Resolve that I used to import them in FCP using BRAW Toolbox. I already mentioned that immediately after importing them in FCP I got the No BRAW File Selected icon on all of those clips. I also restored my computer. Guess, what, those clips that were online and connected in Resolve are also offline. Those same clips that BRAW Toolbox can’t find. The drive is mounted. There’s no reason for this. I found this very peculiar that both apps can’t find the media I imported, except when I imported those same braw clips in Resolve they were connected and stubbed/played just fine. The project was saved before restarting too.

These drives that were given to me with all of this media were already formatted in ExFat. Not that it should matter, but I thought I’d share in case it does. They’re two Glyphs USB 3.1 Gen 2 (USB-C) drives.

I was testing perforce because I wanted to know if there was a huge difference between playing the braw clips in resolve and playing those same clips in FCP. I am having some serious playback issues with my project on those BRAW clips whereas it’s very choppy. This may be due to the size of the timeline more than the individual clips themselves. I needed to do this to find out if I needed to purchase a Thunderbolt drive or RAID using FCP/BRAW Toolbox just to get the performance I’d get using braw natively in Resolve using the USB-C drives. There is a noticeable difference between the two which can hit someone in the wallet just to use BRAW Toolbox.

Tangier

On Apr 24, 2023, at 6:52 PM, Tangier Clarke @.***> wrote:

Hey Chris, just bringing this up because of something that just happened. I got the NO BRAW File Selected message again on clips I just imported with BRAW Toolbox version 1.08 on my M2 Max running Ventura 13.3.1.

I’ve seen this happen before and I have yet to ever use an BRAW Toolbox as an effect. This happened directly after preparing the clips dragging over the event. I restarted my computer because there have been times when I have problems with my timeline clips appearing between FCP launches. I will restart and then they’ll appear. This time they did not. So after importing the clips BRAW Toolbox did not display them or make them playable at all which is so strange.

I didn’t upgrade to 1.1.0 because it seems like using BRAW Toolbox is incredibly fragile for me and I don’t see changes when I grant access. I am stuck always having to select / relink braw clips individually. I am terrified of things breaking since I have so much time already invested in this current project.

Wish I could offer more distinct details, but this was with a new library and a fresh import that I got the No BRAW File Selected message.

Tangier

On Apr 2, 2023, at 4:40 AM, Chris Hocking @.***> wrote:

Again, apologies for the delayed reply!

No BRAW File Selected should only really ever appear if you manually apply a BRAW Toolbox effect (this will be the default image). The only other way it could appear is if you click the Select BRAW File button on an already imported clip, and then something goes wrong.

Are you sure you haven't accidentally added the BRAW Toolbox effect manually to the clips?

The screenshots in your first post show an error message from Final Cut Pro essentially saying it can't load the BRAW Toolbox effect. This could either be because the FxPlug4 effect hasn't loaded properly, or it's failing to open the Apple Motion template for whatever reason.

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1493307999, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTQSAX3O4LS4HSHOSB3W7FJRLANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[latenitefilms]

Very strange. ExFat could definitely be related - I generally only ever recommend macOS Extended for external drives.

Can you try copying a couple of clips to your Desktop instead to test performance between Resolve & BRAW Toolbox?

[tangierc]

Hello Chris.

1. We purchased the RAID to move the project to for performance and redundancy reasons.
2. I made sparse disk images of the two drives I had been working from onto the RAID so that FCP would treat them as if the drives were still there (I tested this successfully a while back)
3. I made a copy of my FCP library (for safety) but didn't change it's location - on my computer's internal drive, mounted the drive images mentioned above which are running from the RAID
4. Launched the copied FCP library hoping all would just connect
5. All BRAW clips in the browser and timeline get the "Missing BRAW File - The Security-Scoped Bookmark could not be resolved".
6. I took another read of this thread in detail to check that I tried everything ultimately seeing that granting access won't solve the problem.
7. Am I stuck in the water after getting this RAID without a real way to relink except for manually doing this clip by clip?
8. I am currently back on the slower real drives since that's the only way everything works with potentially a RAID I can't yet take advantage of.

Any further guidance would help.

[tangierc]

I had an epiphany, but I need you to weigh in: could it be that the way I made the disk images broke your security-scoped bookmarks?

1. When I tested this successfully a while ago, I used Disk Utility to make a new image from the drive.
2. This time and because macOS / Disk Utility was so slow at copying data, I created empty read/write sparse images manually using Disk Utility and then used Carbon Copy Cloner to copy all of the contents of the two physical drives into their disk image counterparts; the reason being Carbon Copy Cloner would be faster at copying than macOS.
3. Oddly and believe it or not, it took my machine about an entire week running 24/7 to copy 19TB of data to the images on the new RAID.
4. I reached out to Bombich support (Carbon Copy Cloner folks) because this was way too slow and one day's shoot of 1.5 TB of Red footage took about 1.5 hours, but everything else took forever. They weren't surprised because the original drives were formatted in ExFat which they said is known to be very very slow at copying. These were the Glyph Blackbox Pro USB-C gen 3.2 drives I was given with all of the project media.
5. So the only difference I can see is that the successful test used Disk Utility fully to image a drive.

If this sounds like this could be a culprit to you and how you've implemented the security bookmarks please let me know.

This also means that I'd have to start over to do this process all over again and take another week at least to copy this data using Disk Utility exclusively. I know it seems insanely slow as if something is wrong, but the drives are healthy, the computer is healthy and the cables are relatively new. Everything checks out.

Again, this is all a work around for not being able to relink all of my braw media after changing drives without issue. Imaging the drives is the only way I can think of doing this successfully....which didn't work this time around.

[latenitefilms]

Did you allow sandbox access to the new drive?

https://brawtoolbox.io/collaboration/

[tangierc]

Yes I did. I'll double check shortly that both virtual drives are allowed access.

[latenitefilms]

If you enable sandbox access for a drive, then, in theory at least, BRAW Toolbox completely ignores the security-scoped bookmarks, and will only use the file path - so if the file path is the same, it should, in theory, work.

One thing that could be an issue - do you happen to have both your Disk Images AND your old external drives connected? If you have two drives connected with the same name, internally, Apple will increment the mount name - i.e /Volumes/External Drive and /Volumes/External Drive 1.

You can check this by right clicking on a file in Finder then hold down OPTION and click Copy as Pathname, then paste into TextEdit to check.

If you're still having issues can you share your log files again?

https://brawtoolbox.io/troubleshooting/#ive-run-into-a-bug-where-can-i-find-the-log-files

I'll also prioritise trying to fix the Relink BRAW Clips within an EVENT Toolbox this week.

[tangierc]

Thanks Chris. I make sure to eject the physical drives before attempting to mount the RAID and the disk images from the RAID. The physical drives are still physically connected to the computer, but they’re not mounted.

What are your thoughts about the way I created the images this time that I mentioned. Would that have any affect on the security bookmarks?

Thanks,

Tangier

On Jun 4, 2023, at 4:35 PM, Chris Hocking @.***> wrote:

If you enable sandbox access for a drive, then, in theory at least, BRAW Toolbox completely ignores the security-scoped bookmarks, and will only use the file path - so if the file path is the same, it should, in theory, work.

One thing that could be an issue - do you happen to have both your Disk Images AND your old external drives connected? If you have two drives connected with the same name, internally, Apple will increment the mount name - i.e /Volumes/External Drive and /Volumes/External Drive 1.

You can check this by right clicking on a file in Finder then hold down OPTION and click Copy as Pathname, then paste into TextEdit to check.

If you're still having issues can you share your log files again?

https://brawtoolbox.io/troubleshooting/#ive-run-into-a-bug-where-can-i-find-the-log-files

I'll also prioritise trying to fix the Relink BRAW Clips within an EVENT Toolbox this week.

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1575792641, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTQE4MJZ5I7EIX2BKOLXJULU7ANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[latenitefilms]

No, if you have sandbox access to the drive, security-scope bookmarks should be irrelevant. If you're seeing this error though, it means BRAW Toolbox can't find the files by their "path" - so something must be wrong with the file paths.

[tangierc]

I tried leaving one physical drive mounted and one virtual drive mounted.. They are Anxious 3 and Anxious 4. The second one is the disk image of the physical Anxious 4 and is only 3TB of used space.

When launching the FCP library I tried granting access again and it seemed to work on Anxious 4 - the virtual drive. Though the playback flickered between the footage and the missing b-raw security scope message for a bit. Zooming in and out on the timeline seemed to help fix the issue. I did the same in the browser. Must be that FCP bug.

Restarting FCP again, also helped. The playhead doesn’t move as smoothly playing from the disk image for some reason even though this RAID is significantly faster.

Being able to relink without creating new events will be a significant help to general project workflow for large projects. I suppose I could also restructure my entire library so that it has only one event, but even the toolbox relinking feature would still not link current clips to the new event.

I’ll keep trying things.

Thanks.

On Jun 4, 2023, at 7:55 PM, Chris Hocking @.***> wrote:

No, if you have sandbox access to the drive, security-scope bookmarks should be irrelevant. If you're seeing this error though, it means BRAW Toolbox can't find the files by their "path" - so something must be wrong with the file paths.

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1575961654, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTTUM3CQGSSTVFKM5JTXJVDB3ANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[latenitefilms]

I've improved the Relink BRAW Clips within an EVENT Toolbox. I'm just doing some more testing, but I'll hopefully submit to the App Store & TestFlight very soon. You'll be able to relink libraries, events and projects. Apologies it's taken so long - but HOPEFULLY this will fix your issue.

[latenitefilms]

This will be added in v1.1.3.

[latenitefilms]

v1.1.3 is out now!

[tangierc]

Wow!, Thanks Chris. It’s safety upgrade without having any impact on my current project? I’ll make a duplicate first of course, but just want to be sure. Has the documentation been updated already so I can read how to use it properly? I haven’t checked yet and see the information in the image you sent.

Looking forward to trying this out. Hopefully I can take the clips out of the disk images.

Tangier

On Jun 4, 2023, at 11:23 PM, Chris Hocking @.***> wrote:

I've improved the Relink BRAW Clips within an EVENT Toolbox. I'm just doing some more testing, but I'll hopefully submit to the App Store & TestFlight very soon. You'll be able to relink libraries, events and projects. Apologies it's taken so long - but HOPEFULLY this will fix your issue.

https://user-images.githubusercontent.com/22286696/243268148-33b51937-26ef-4740-b071-864d0b5cdf20.png — Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1576117511, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTVJ7MCNBPMDRLKOQ43XJV3OPANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[latenitefilms]

You can ZIP up your current copy of BRAW Toolbox as a backup. I would recommend always ZIP'ing up any Mac App Store app before updating anyway, so you can always roll back to a previous version.

Yes, documentation has been updated here:

https://brawtoolbox.io/toolbox/#relink-braw-clips-within-an-library--event--project

[tangierc]

Great, thanks. I am reading through it now to prepare ahead of time. The only part not clear is the last line of the segment “Replace if you only dragged in BRAW Toolbox Clips - not projects/timelines.” It may seem trivial, but I assume this means when a user drags in BRAW Toolbox clips using the event XML in the typical preparation of BRAW clips workflow?

Thanks

Tangier

On Jun 5, 2023, at 10:43 AM, Chris Hocking @.***> wrote:

You can ZIP up your current copy of BRAW Toolbox as a backup. I would recommend always ZIP'ing up any Mac App Store app before updating anyway, so you can always roll back to a previous version.

Yes, documentation has been updated here:

https://brawtoolbox.io/toolbox/#relink-braw-clips-within-an-library--event--project

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1577211704, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTVNDQW5RWNMUWTCI2TXJYLDTANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.

[latenitefilms]

No dragging involved. When you press the Send FCPXML to Final Cut Pro it will send the FCPXML to Final Cut Pro - so it works differently than the normal drag-and-drop way it worked in the last version.

I'll update the documentation to make it more clear.

[latenitefilms]

I've added this to the documentation:

This new Send FCPXML to Final Cut Pro button works differently than the way the previous Relink BRAW Clips within an EVENT toolbox - as there's no dragging and dropping involved.

Pressing this button will trigger the import process within Final Cut Pro - no drag and drop required.

[tangierc]

Excellent!. Thanks Chris. Thanks for the shout out on the App store. Just saw that today.

Sincerely,

Tangier

On Jun 5, 2023, at 11:50 AM, Chris Hocking @.***> wrote:

I've added this to the documentation:

This new Send FCPXML to Final Cut Pro button works differently than the way the previous Relink BRAW Clips within an EVENT toolbox - as there's no dragging and dropping involved.

Pressing this button will trigger the import process within Final Cut Pro - no drag and drop required.

— Reply to this email directly, view it on GitHub https://github.com/latenitefilms/BRAWToolbox/issues/101#issuecomment-1577295838, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJCKTVIFQWGBDSA46MDIZTXJYTBDANCNFSM6AAAAAAWIJMABA. You are receiving this because you authored the thread.