Importer + source settings effects not working on macOS but works on Windows

[Smleh]

Hi, we're having trouble getting the "Importer + source settings effect" working on macOS.
We have a macOS and Windows version which are built from the same code but the macOS version doesn't connect the Importer to the source settings effect - On Windows, it works correctly.

On Windows:
Importing the file triggers PF_Cmd_SEQUENCE_SETUP in the Source Effect where the PerformSourceSettingsCommand function is called and the source settings pane correctly fills intself in the UI.
The source settings effect is hidden from the 'Effects' pane in Premiere by setting:
'out_data->out_flags = PF_OutFlag_SEND_UPDATE_PARAMS_UI | PF_OutFlag_I_AM_OBSOLETE;' in the PF_Cmd_GLOBAL_SETUP command in the effect.

On Mac:
Importing the file does not trigger any commands in the Source Effect. There is no UI populated in the 'Source' pane and the Importer never receives 'SDKPerformSourceSettingsCommand'
The source settings effect is not hidden and shows up in the 'Effects' pane even though the the same code:
'out_data->out_flags = PF_OutFlag_SEND_UPDATE_PARAMS_UI | PF_OutFlag_I_AM_OBSOLETE;' in PF_Cmd_GLOBAL_SETUP is run.

Changing the match name has no effect on Mac, but on Windows it only works when the match names are the same (As expected).
In SDKGetInfo8 of the importer, the sourceSettingsMatchName of SDKFileInfo8 is set as follows:

const auto& RawSourceSettingsMatchName = std::wstring(L"AE.") + Constants::RawSourceSettingsMatchNameW;
#ifdef PRWIN_ENV
wcscpy_s(SDKFileInfo8->sourceSettingsMatchName, RawSourceSettingsMatchName.size()+1, RawSourceSettingsMatchName.data());
#endif
#ifdef PRMAC_ENV
wcscpy((wchar_t*)SDKFileInfo8->sourceSettingsMatchName, RawSourceSettingsMatchName.data());
#endif

Thanks,

Russell

[Wil Renczes · Accepted solution]

Hey Russell,

if your importer never receives the source settings selector, that's an indicator (as you surmised) that there's a mismatch in the importer vs source settings plugin match names.

I'd stuff a breakpoint on mac to inspect what's being copied into the ->sourceSettingsMatchName, and if that looks correct, then I'd double-check the source settings plugin side, ie PluginDataEntryFunctionPtr's match name.

(Note that, (and it looks like you're already doing this) when we set the match name on the source effect plugin, it doesn't have "AE." prepended, but we do prepend it in the importer plugin.)

Cheers,

Wil

[Smleh]

Hi Wil,

Thanks for getting back to me. Unfortunately still no luck - we’ve double checked and debugged the match names and they are appear set to the correct matching values - the code also works fine on Windows.

One thing we’re not sure about is the Source Effect PiPl file. Does a Source Effect require a PiPl? We have one but there is no reference example for a Source Effect plugin so we don’t know if it is correct.

Is it possible to share a sample Source Effect project for Xcode to check we have all the projects settings correct?

Thanks

Russell

[Wil Renczes]

So I thought that PiPl resources were deprecated, but it looks like this is still in play, so that could very well be the missing piece on mac.

See here, from our DPXSourceSettings.r file:

#include "AE_EffectVers.h"
#ifndef MSWindows // i.e. Mac only
#include <AE_General.r>
#include "AEConfig.h"
/* if we didnt explicitly define anything on the way in, autodetect based on the compiler settings in AEConfig.h */
#if defined(AE_PROC_INTEL)
#define X32
#elif defined(AE_PROC_INTELx64)
#define X64
#endif
#endif

resource 'PiPL' (16000) {
{ /* array properties: 11 elements */
/* [1] */
Kind {
AEEffect
},
/* [2] */
Name {
"$$$/MediaCore/AEFilters/DPXSourceSettingsEffect/Name=Cineon Source Settings"
},
/* [3] */
Category {
"Obsolete"
},

/* [4] */
#ifdef MSWindows
#ifdef X64
CodeWin64X86 {"EffectMain"},
#else
CodeWin32X86 {"EffectMain"},
#endif
#else
#ifdef X64
CodeMacIntel64 {"EffectMain"},
#else
CodeMacIntel32 {"EffectMain"},
#endif
#endif

/* [5] */
AE_PiPL_Version {
2,
0
},
/* [6] */
AE_Effect_Spec_Version {
PF_PLUG_IN_VERSION, // for CS5, 13
PF_PLUG_IN_SUBVERS // 0
},
/* [7] */
AE_Effect_Version {
0x80002
},
/* [8] */
AE_Effect_Info_Flags {
0
},
/* [9] */
AE_Effect_Global_OutFlags {
32832
},
/* [10] */
AE_Effect_Match_Name {
"ADBE DPX.SourceSettings"
},
/* [11] */
AE_Reserved_Info {
8
}
}
};

When I look at the .xcodeproj settings, there's definitely a 'build carbon resources' step referencing this .r file.  It looks like this is being compiled into a .rsrc file within the plugin's bundle (under Content/Resources/).

Hope this helps!

Wil

[Smleh]

HI Will,

Thanks for getting back to me. We managed to get it working. It turns out it wasn't anything to do with the PiPl.

It was infact:

SDKFileInfo8->sourceSettingsMatchName

needs setting differently for macOS and for windows. On Windows a simple wide string copy from a wide string literal works, but on macOS the string needs to be encoded into UTF16 using macOS string conversion functions as follows:

static inline void ToPrUTF16(prUTF16Char* pOut, const std::wstring& In, size_t MaxLengthOut = kPrMaxPath)
	{
		const auto length = MaxLengthOut > 0 ? std::min(MaxLengthOut-1,In.size()) : In.size();
		CFRange	range = { 0, MaxLengthOut };
		range.length = length;
		CFStringRef inputStringCFSR = CFStringCreateWithBytes(kCFAllocatorDefault, reinterpret_cast<const UInt8*>(inputString), length * sizeof(wchar_t), 
			kCFStringEncodingUTF32LE, kPrFalse);
		CFStringGetBytes(inputStringCFSR, range, kCFStringEncodingUTF16, 0, kPrFalse, reinterpret_cast<UInt8*>(pOut), length * (sizeof(prUTF16Char)), NULL);
		pOut[length] = 0; // Set NULL-terminator, since CFString calls don't set it, and MediaCore hosts expect it
		CFRelease(inputStringCFSR);
	}

Hope this helps anyone else having trouble.

[Wil Renczes]

Cool, glad to hear it.  (Thx for relaying the solution, for that matter.  I'm sure someone else will appreciate 🙂 )

Wil