Hi Rory,
I am exporting VST3 from Cabbage 2.9.218 and Reaper doesn’t recognize it. I have ad-hoc signing checked as before, when the plugins were recognized by Reaper on OSX 12.6.1.
There is another minor issue. Now pressing cmd+1 when mouse cursor is on an opcode name does no longer trigger connection to the Csound help.
Can you try adhoc signing manually?
I could try this later if needed. For now I can tell you that I reverted back to version 2.9.193, which does sign the plugin. So it seems later versions don’t sign.
That’s odd considering I haven’t touched that code in about 2 years. I wonder if Azure DevOps has updated its MacOS host / dev tools. That’s the only thing I can think of that would have changed.
The help link works in the older version too. Could the issue with opening the help link be related to this (permissions)? Maybe Cabbage needs to be signed?
I’m not sure, al I know Apple gets more and more restrictive with every new release.
In v2.9.222 the help link works again, but the VST is still not recognized by Reaper Apple silicon version. However, it is recognized by Reaper Intel version! So the plugin appears to be Intel ONLY?
I tried manually signing it with:
codesign -s - path_to_my_vst3 --timestamp --deep --force
which did not resolve the issue, but I don’t know if I am doing this correctly?
It’s extremely unlikely. Run lipo on any exported plugin and I’m sure you’ll see an arm64 slice alongside a x64 one.
(base) rwalsh@Rorys-Mac-mini cabbage % lipo -info ~/Library/Audio/Plug-Ins/VST/TestExport.vst/Contents/MacOS/TestExport
Architectures in the fat file: /Users/rwalsh/Library/Audio/Plug-Ins/VST/TestExport.vst/Contents/MacOS/TestExport are: x86_64 arm64
There must be something else at fault here. I can run any exported plugin out of the box. I wonder if Apple have changed something regarding adhoc signing? I really hope not.
p.s. I see nothing wrong with that signing command…
I just realised that I’m on 13.5.1, so I’m ahead of your version. Sorry, I had thought for some reason that I was behind you. Hmm, now I’m even more stumped. Can you also try running codesign on your exported plugin just to make sure it’s actually signed. Can you also let me know if it’s just VST3s that are the problem. And finally, are you sure you have them in the right location? I’m not sure about Mac, but on Windows hosts won’t load them unless they are in the right location.
Indeed I see the arm64:
Architectures in the fat file: /Library/Audio/Plug-Ins/VST/Cabbage/tokolo_vX.vst/Contents/MacOS/tokolo_vX are: x86_64 arm64
Architectures in the fat file: /Library/Audio/Plug-Ins/VST3/Cabbage/tokolo_vX.vst3/Contents/MacOS/tokolo_vX are: x86_64 arm64
Still, both VST and VST3 are not recognized by Arm Reaper, but they are with the Intel version:
I haven’t updated the OS in a long time. So, I am not sure how would any potential Apple’s changes factor in here?
Regarding the location, I have always had them there (with several other working plugins), no changes to my work-flow, and as I mentioned, the exports are recognized if from an older Cabbage (which I reinstalled to test this). So I can go back to an older Cabbage and it will be fine, but I want to keep up with the Cabbage updates, and recent versions just seem to be in conflict with my system 
I tried to codesign manually pointing to:
/Library/Audio/Plug-Ins/VST3/Cabbage/tokolo_vX.vst3/Contents/MacOS/tokolo_vX
and to
/Library/Audio/Plug-Ins/VST3/Cabbage/tokolo_vX.vst3
without success.
Do all of those plugins use the same pluginId?
No. I’ve been very careful with those since the times I was using AUs (where it seems it matters more).
I have also rescanned all plugins and tried with new names and IDs.
