Hi Frank,Unfortunately it does not work. It seems that the NSNull value in the dictionary is simply ignored. The resulting sampler still thinks it should color match (my input image is one of the desktop pictures that ships with Catalina, hence the Display P3 profile):<CISampler: 0x60000000c980> samplemode linear extent=[0 0 6016 6016][-1 -1 6018 6018] affine [1 0 0 -1 0 6016] extent=[0 0 6016 6016] opaque colormatch DisplayP3_to_workingspace extent=[0 0 6016 6016] opaque CGImageRef 0x104e14460(717) RGBX8 6016x6016 alpha_one extent=[0 0 6016 6016] opaqueAny other ideas?

Hi Frank,Thanks for all the help. Unfortunately disabling color correction at the CIContext level doesn't quite solve the problem I was set to solve. Our overall image computation does need color management. It is only lookup tables to store intermediate results that shouldn't go through the color conversion process. Someone did point out to me that it has been a very long time that the __table qualifier hasn't had any meaning to Core Image. It is parsed without errors, but it is ignored since the Core Image implementation that shipped with OS X 10.11. This is noted in the Core Image kernel language docs.It is also possible to sort-of disable color correction for a specific input to a kernel if you happen to know what color space its values were encoded in. You simply pass that same color space to kCISamplerColorSpace, turning the color management pass to a no-op.And though this does not match my usage scenario, you can also evaluate (render) a CIImage to a surface (IOSurface, Metal texture, etc.), which gives you a chance to re-create another CIImage from that data and omit the colorspace. We’ve used render destinations and the latter technique before, but the AFAIK the API really does seem to lack a clean way to accomplish what many of Apple’s own built-in kernels are doing, that is: use kernels to create intermediate results that do not encode RGB values, to be consumed by later kernels.

Hi hateom,In most cases, you should never have to explicitly add that entitlement to your targets. AFAIK Xcode automatically injects that entitlement when you begin a Debug session for that target. And since you don't need software that you are debugging to be notarized, this is perfectly fine. (I assume you are already codesigning to run locally)From my experience, as long as:- you are using the most recent version of FxPlug and PlugInManager, embedded as appropriate inside your PlugInKit container- you are codesigning with the hardened runtime flag- your loadable code is linked against a recent version of the macOS SDKYou should be able to build plugins that are loaded by Final Cut Pro / Motion and that can be notarized.

Try re-signing the FxPlug framework with your own identity (the same one you are using to sign the target, which may be different in Debug/Release configuration).So... disable automatic code signing in the Copy Files phase, where you are probably copying the FxPlug framework to its final location inside your bundle. Next, add a build script which resigns that framework with your own identity:codesign --force --timestamp --options runtime --sign "${CODE_SIGN_IDENTITY}" "${BUILT_PRODUCTS_DIR}/${FRAMEWORKS_FOLDER_PATH}/FxPlug.framework"As a side note, I have "Code Signing Inject Base Entitlements" ON in my Debug configuration, and OFF for Release. I'm not sure what’s going on on your system, but I don't think that option is *directly* affecting your ability to load the filters. It is more a case that when you have that option on, a bunch of stuff that doesn't pass GateKeeper validation gets a free pass.

You are not alone in being unable to update to Beta 4. On my DTK, when clicking Update Now, the progress bar goes quickly up to a fifth, then abruptly fails with an error claiming that the download failed. Had a problem more similar to yours on an Intel Mac too (it would advertise two updates, one for Beta 4 and one for the full version). If yours is an Intel Mac I would recommend unenrolling from beta updates, then enrolling again. Try installing the full Big Sur beta if that is an option. The incremental update to Beta 4 bricked my Mac and had to go into Recovery Mode.

macOS Big Sur Beta 9 mostly fixes this problem, with a strange exception. The reason you may not be able to reproduce the problem is that maybe your customer hasn't had a chance to update to Beta 9 yet. In Beta 9 when our non-sandboxed app is launched as a result of a custom URL invocation from Safari, it gets the correct UNIX/POSIX environment (home folder, system folders, etc). BUT, for unclear reasons, the sandbox container ID as reported by the process’s environment variable APPSANDBOXCONTAINER_ID is still Safari’s. This seems extremely unusual, as if the fix is only partially there. Unclear what else may be different about an app that runs under a different app’s Sandbox Container ID. 🤔

Having the same problem. Was already setting setDraggingSourceOperationMask:forLocal: but still doesn't work: the -[filePromiseProvider:writePromiseToURL:...] method isn't being called. This started happening with the most recent macOS Big Sur Beta, must be a regression?

I haven't had the time to file a bug yet, but this might help anyone else who bumps into this... The problem seems to be triggered by the target being set to be deployed. I'm referring to the Build Settings whose xcconfig equivalents are DEPLOYMENT_LOCATION and INSTALL_PATH, e.g.: DEPLOYMENT_LOCATION = YES INSTALL_PATH = $(LOCAL_APPS_DIR) The deployment location might also play a role, though this is speculation "inspired" by macOS security policies. In our case, the framework whose default Metal library was not being created, was set up to be deployed to the Frameworks directory for the current user, i.e. INSTALL_PATH = $(LOCAL_LIBRARY_DIR)/Frameworks ...and this is enough to trigger the failure. This problem seems to affect more than just the Metal compiler. I noticed it too with the Storyboard compiler for a silly Swift app. Since the app was set to be deployed to $(LOCAL_APPS_DIR) the storyboardc invocation was failing to copy the compiled storyboard to the app bundle. Whether this is a bug in recent versions of Xcode, or a side effect of these various tools being unable to touch files at those locations, the solution is to add built phases to "do what the underlying compiler is no longer doing" ;-)

@fuseaudiolabs the error message "The binary uses an SDK older than the 10.9 SDK." suggests to me that you might be using an older version of the SDK, or at least that the PluginManager.framework that you are copying to your built products is from an older SDK. With any recent version of the FxPlug SDK and Xcode, it is no longer necessary to add custom build phases to get plugins recognized and loaded by the host app. You can simply link with the frameworks, and under the General → Frameworks and Libraries section of your project configuration, select the "Embed & Sign" option. Under Build Phases, the part where the SDK frameworks are copied to the Frameworks directory inside your bundle should have the Code Sign on Copy option enabled. First, I would make sure you have the very latest version of the FxPlug SDK. This message thread pre-dates the reorganization of the SDK, following Apple’s newest conventions. Besides letting the FxPlug SDK install the "FxPlug.sdk" folder where it wants, you could make your own local copy (so it's part of your repository) and add a build configuration setting so that Xcode can locate it when building your target, for example: ADDITIONAL_SDKS = "$(PROJECT_DIR)/SDK/FxPlug/FxPlug.sdk"

For posterity, if you follow some of the previous advice in this thread and use the ADDITIONAL_SDKS build setting to tell Xcode about your local copy of the "FxPlug.sdk" folder, you'll have to include this additional line in your xcconfig file*: FRAMEWORK_SEARCH_PATHS = $(inherited) "/Library/Frameworks" This is because the FxPlug.sdk folder does not contain the frameworks at its root. The FxPlug.framework and PlugInManager.framework are nested in /Library/Frameworks You don't have to use xcconfig files, strictly speaking... both the ADDITIONAL_SDKS and FRAMEWORK_SEARCH_PATHS build settings are available through Xcode’s Build Settings UI.

I would be far from trivial to simply keep Quartz Composer running on modern macOS, mostly for its foundations in the now-ancient OpenGL 1.x APIs, its support for OpenCL, its ghastly inclusion of JavaScript and a scene graph centered around the fixed functionality pipeline. With that in mind, a rewrite in Metal was always the only sensible option, even if it meant abandoning any hope of backward compatibility with existing QTZ files. Which is exactly what some companies ended up doing to preserve everything that was truly great about QC, while maybe tailoring it to slightly different goals. Once you experience how wonderful it is to prototype effects through node-based compositing (no code environments in modern lingo) it’s hard to go back. Take a look here: https://fxfactory.com/fxcore/

Seems slower than Beta 1, but possibly due to some specific regressions. For example: up to 20 seconds between selecting Edit All in Scope and actually being able to edit the symbol. This is an apparent data point since this is an operation I was doing many times a day, i.e. until Beta 2. 🤷‍♂️

Same problem here, filed as FB13323831.

Are you on the latest macOS Sonoma 14.2 Beta, by any chance? I'm currently investigating some unexpected/odd problems and they seem related to the -[CIImage imageByClampingToExtent:] / clampedToExtent() method too.

Thanks Quinn! Will take your advice to heart. Would you say that only atomic operations are reasonably immune from being flagged as TSAN evolves?