I found an issue with macOS Reference Modes where a recreated custom preset does not match the grayscale response of the original Apple-provided preset, even when all visible settings appear to be identical. For example, when duplicating the built-in Apple Display P3-600 nits Reference Mode preset, the duplicated preset does not produce the same grayscale luminance response as the original system preset. The comparison is performed under the same physical display brightness setting. The difference is not caused by different brightness levels. The native Reference Mode preset and the recreated preset are tested at the same display brightness, but the grayscale response is still different. The same behavior also occurs when manually creating a new Reference Mode preset with equivalent parameters, including using Pure Gamma settings. Even when the gamma value and other visible parameters are matched, the grayscale transfer function in the shadow region does not match the original Apple preset. The difference can be observed using grayscale test patterns, including: BarsAndBlack_16bit.TIFF CT ColorBar test pattern With these test images, the recreated preset shows lifted dark tones compared with the original Apple Display P3-600 nits preset. The darker grayscale steps become brighter, indicating that the EOTF/grayscale response is not identical between the built-in preset and the recreated preset. This behavior can be reproduced using the built-in macOS Preview application. Opening the same test image and switching between the native Reference Mode preset and the recreated preset shows differences in the black level and shadow grayscale response. The issue can be reproduced on both macOS 26.4 and macOS 15. Environment: macOS: 26.4 (also reproducible on macOS 15) Mac: 14-inch MacBook Pro Display: Built-in XDR Display Reference Mode tested: Apple Display P3-600 nits The main question is: When there is a difference between the built-in Apple Reference Mode preset and a recreated preset with the same visible parameters, which one represents the intended and accurate gamma/EOTF response? Specifically: Is the built-in Apple Display P3-600 nits Reference Mode using additional internal calibration data or hidden parameters that are not exposed in the Reference Mode configuration UI? Is the recreated preset actually applying the requested gamma curve correctly, while the Apple preset includes additional processing? Or is the Apple built-in preset the accurate reference implementation, and the recreated preset cannot reproduce it because some internal display calibration information is unavailable? Is there a documented way to create a custom Reference Mode preset that exactly matches the grayscale response of an Apple system preset? Thank you.

Hi Apple Developer Forums and Final Cut Pro team, I am developing a Final Cut Pro Workflow Extension focused on speech-to-text / subtitle recognition and generation. The extension runs inside Final Cut Pro, analyzes clips, generates accurate subtitles (often hundreds of individual elements), and allows users to drag the generated subtitles directly back into the FCP timeline as a clean, editable Compound Clip or Storyline. We are implementing this drag-and-drop functionality using the official pasteboard mechanism (com.apple.finalcutpro.xml and versioned types such as com.apple.finalcutpro.xml.v1-10). While the high-level documentation is helpful: Supporting Drag and Drop for Data Sent to Final Cut Pro FCPXML Reference Designing Workflow Extensions There is still no detailed public specification for the exact internal XML structure that Final Cut Pro expects for a drag operation to reliably result in a usable Compound Clip (or direct Storyline insertion), especially when dealing with large numbers of subtitle titles. After extensive systematic testing (multiple rounds over several weeks, with full experiment logs), we have observed the following: Short subtitle sequences work with many different structures (various combinations of , , , inline titles, etc.). Long subtitle lists (800+ individual elements) only succeed reliably when the outer structure uses a specific shell: root= containing + (often combined with a mainflow sequence and inner / layers). In all working cases, the dropped result appears as a “fake” / nested Compound Clip that requires 2–3 Break Apart (unpack) operations before the real editable Storyline with individual titles is revealed. Almost all other structures — pure as root, as root, wrapper layers, direct inline titles without the clip + gap + storyline shell, etc. — are immediately rejected by Final Cut Pro when the subtitle count is high. This undocumented behavior forces third-party Workflow Extension developers to engage in time-consuming blind guesswork and reverse-engineering just to achieve basic, reliable drag-and-drop integration. Our request: We kindly ask Apple to publish a detailed, official specification for the Draggable FCPXML Text Protocol (or expand the existing FCPXML Reference) that clearly defines: The minimal and recommended XML structure for dragging content into the timeline as a Compound Clip or Storyline. Exact roles and requirements for , , , , , and any implicit “mainflow” patterns. Best practices for handling large numbers of nested titles/subtitles. Reasons why certain nesting patterns are rejected or produce multi-level fake compounds. Any version-specific differences across FCPXML DTD versions. This specification is critically necessary for the FCPX Workflow Extension ecosystem. Reliable drag-and-drop from extensions back to the timeline is one of the most valuable integration points for subtitle/caption tools, transcription services, title generators, and other workflow utilities. Without clear guidelines, developers waste significant time on trial-and-error, leading to inconsistent user experiences and slower innovation in the Final Cut Pro community. We are more than happy to share our complete experiment logs, working and failing XML samples, and GitHub repository with the documentation or engineering team if it helps accelerate this. Thank you in advance for any official clarification or guidance. Clear documentation in this area would greatly benefit both developers and Final Cut Pro users.

I have exhausted standard debugging approaches and need guidance on Final Cut Pro's AU plugin loading behavior. PLUGIN OVERVIEW My plugin is an AUv2 audio plugin built with JUCE 8. The plugin loads and functions correctly in: Pro Tools (AAX) Media Composer (AAX) Reaper (AU + VST3) Logic Pro (AU) GarageBand (AU) Audacity (AU) DaVinci Resolve / Fairlight (AU) Harrison Mixbus (AU) Ableton Live (AU) Cubase (VST3) Nuendo (VST3) It does NOT load in Final Cut Pro (tested on 10.8.x, macOS 14.6 and 15.2). DIAGNOSTICS COMPLETED auval passes cleanly: auval -v aufx Hwhy Manu → AU VALIDATION SUCCEEDED Plugin is notarized and stapled: xcrun stapler validate → The validate action worked spctl --assess --type exec → Note: returns 'not an app' which we understand is expected for .component bundles. Hardened Runtime is enabled on the bundle. We identified that our Info.plist contained a 'resourceUsage' dictionary in the AudioComponents entry. We found via system logs that this was setting au_componentFlags = 2 (kAudioComponentFlag_SandboxSafe), causing FCP to attempt loading the plugin in-process inside its sandbox, where our UDP networking is denied. We removed the resourceUsage dict, confirmed au_componentFlags = 0 in the CAReportingClient log, and FCP now loads the plugin out-of-process via AUHostingServiceXPC_arrow. Despite au_componentFlags = 0 and out-of-process loading confirmed, the plugin still does not appear in FCP's effects browser. We also identified and fixed a channel layout issue — our isBusesLayoutSupported was not returning true for 5-channel layouts (which FCP uses internally). This is now fixed. AU cache has been fully cleared: ~/Library/Caches/com.apple.audio.AudioComponentRegistrar /Library/Caches/com.apple.audio.AudioComponentRegistrar coreaudiod and AudioComponentRegistrar killed to force rescan auval -a run to force re-registration

Hi, We have created an app which allows recording 4K 60 fps videos in the app. We have noted that some time the recording switched to 20 fps (the value 20 is constant) even though the resolution settings is at 4K 60fps. We are using AVCaptureDevice to invoke the camera. has anyone experienced this problem before ? What is unique to 20 fps? Why does it resort to 20 fps from 60 fps and why not to other numbers ?

Our Final Cut Pro workflow extension built with ProExtensionHost framework uses an advanced NSPasteboardItemDataProvider system with multi-version FCPXML support (1.9, 1.10, 1.13) and proper relative path UIDs for Motion templates. We've implemented clip wrapper approach with placeholder assets and elements containing effects to enable direct timeline drag functionality. However, drag and drop from our Final Cut Pro workflow extension directly to timeline is still not working despite proper element structure in our FCPXML. Our implementation creates valid clip elements with effects applied, but Final Cut Pro timeline doesn't accept them during drag operations from our ProExtensionHost-based workflow extension. Steps to Reproduce: Create Final Cut Pro workflow extension using ProExtensionHost framework with NSPasteboardItemDataProvider implementation Generate FCPXML with proper element structure: Expected Result: Clip should be accepted by timeline and effect applied from workflow extension Actual Result: Timeline rejects drag operation from ProExtensionHost-based workflow extension Question: Are there additional requirements or ProExtensionHost API calls needed beyond standard NSPasteboardItemDataProvider for Final Cut Pro workflow extension timeline drag functionality?

I'm developing a Final Cut Pro X workflow extension that transcribes audio and creates a text output. I need to allow users to drag this text directly from my extension into FCPX's timeline as titles. Current Implementation: Using NSFilePromiseProvider as per Apple's guidelines for drag and drop Generating valid FCPXML (v1.10) with proper structure: Complete resources section with format and asset references Event and project hierarchy Asset clip with connected title elements Proper timing and duration calculations Supporting multiple pasteboard types: com.apple.finalcutpro.xml.v1-10 com.apple.finalcutpro.xml.v1-9 com.apple.finalcutpro.xml What's Working: Drag operation initiates correctly File promise provider is set up properly FCPXML generation is successful (verified content) All required pasteboard types are registered Proper logging confirms data is being requested and provided Current Pasteboard Types Offered: com.apple.NSFilePromiseItemMetaData com.apple.pasteboard.promised-file-name com.apple.pasteboard.promised-suggested-file-name com.apple.pasteboard.promised-file-content-type Apple files promise pasteboard type com.apple.pasteboard.NSFilePromiseID com.apple.pasteboard.promised-file-url com.apple.finalcutpro.xml.v1-10 com.apple.finalcutpro.xml.v1-9 com.apple.finalcutpro.xml What additional requirements or considerations are needed to make FCPX accept the dragged FCPXML content? Are there specific requirements for workflow extensions regarding drag and drop operations with titles that aren't documented? Any insights, especially from those who have implemented similar functionality in FCPX workflow extensions, would be greatly appreciated. Technical Details: macOS Version: 15.5 (24F74) FCPX Version: 11.1.1 Extension built with SwiftUI and AppKit integration Using NSFilePromiseProvider and NSPasteboardItemDataProvider Full pasteboard type support for FCPXML versions