Loading .jucer created in Introjucer into Projucer 4.2


#1

Hello everyone,

i just updated to Juce 4.2. I built the Projucer to be able to open my .jucer files and resave them and the XCode project.

I get a ton of errors now in XCode which seem to have to do something with the changes in Juce 4.2 regarding the drop of polymorphic plugins. The VST plugin for example is not copied to the VST folder and in the Build folder there is a framework with full size and a .vst with a few bytes in size.

Somehow it seems that the Projucer does not adjust older .jucer files correctly for this change. Is it recommended to create a new .jucer file in the Projucer and then transfer all the files and settings there?

Best regards,

Thomas


#2

Hi Thomas,

I did not have that problem, but it sounds like you probably need to delete the post-build shell script that used to copy the files.


#3

Hell yes! That was it, thanks a lot!


#4

Yeah exactly. The Projucer now adds some build settings to the generated Xcode project that move the plug-ins to the right folder automatically (and also delete it from there if you clean!) so this old method with the post-build shell script is obsolete now.


#5

I had the same problem. Removing the shell script makes the project compile again, but the built AAX cannot be loaded, PT development version 12.4 says it’s no valid aax plugin.

I tried both, copying the PluginName.aaxplugin to the PlugIns folder next to the development executable and disabling the local PlugIns folder by renaming and using the global folder, where Xcode placed the plugin. Same result.

It is now placed into the global folder (which makes not much sense, as it needs to be wrapped before it can be used by production versions of ProTools anyway). If I can configure that one to point to the location as it was before would be nice…

Checked the VST3 build with the juce plugin host to be sure, that one works…
Any ideas?


[fixed] AAX plugins created with 4.2 no longer loadable in ProTools development build
#6

For aax plugins to be loaded they need to be signed by the wraptool of Pace Anti Piracy. You need to contact them to get access to the Eden SDK. Tell them that you develop aax plugins, then you should get a free license.


#7

Thanks Thomas, I have everything here, and wrapped already AAX plugins. But I also have the development ProTools build, which loads AAX plugins without wrapping, that was how my workflow used to be.
But the development build does not load the new olugins any longer. Nothing changed, except

  • pulled new 4.2
  • loaded existing jucer file
  • set module paths
  • removed post build script
  • copy new bundle into private plugin folder
  • start pro tools development build

-> and proTools fails to open a session, where the plugin is already present, saying it is no valid 64 bit plugin
Next try:

  • build again
  • rename private plugin folder
  • start development build again
  • it loads all other plugins in the standard folder
  • it rejects ONLY the plugin built with 4.2
  • another juce plugin created before with 4.0.1 not signed is loaded

I will try with the juce demo plugin again…
EDIT: new created plugin with 4.2 also doesn’t load in development build, see screenshot (removed)


#8

Follow up: I tried to wrap the AAX plugin, but with no success: wraptool calls codesign, which exits with error code 1:

Apple's codesign tool failed with result code 1: "/tmp/3e211198-6a58-4f2c-ae30-cd93b34c1dec/AK-Animator_signed.aaxplugin: code object is not signed at all
In subcomponent: /private/tmp/3e211198-6a58-4f2c-ae30-cd93b34c1dec/AK-Animator_signed.aaxplugin/Contents/Frameworks/AK-Animator.framework"

I double checked, with the previous 4.1 juce I can build, run with development build, wrap and run with productive Pro Tools.

Possible reason (when reading diagonally through the net): codesign needs to be called for sub components as well?

N.B. I am aware of the momentary problems of pace eden tools with the latest apple updates, but I am running 10.10.5 which is not affected - and the problem is already present before wrapping…


#9

In xcode Build settings, make sure your code sign identity is set


#10

Thanks cocell, I tried either way, with and without signing, no luck.
I tried setting the sign id in projucer, and I tried to set it directly in xcode…

Side note: previously (i.e. with 4.1) I didn’t need to sign for loading plugins into the development build, not with apples code sign nor with pace’s wraptool.


#11

In your wrapping command, remove the quotes from
–signid “cert” try
–signid cert


#12

I didn’t quote the signid in the first place.
However: I tried again the long way: signing with XCode (needed to click 8 times “Fix issue”, twice for each target platform). The result is still not loadable. But I can wrap that one, the error of the wraptool is gone in favour of a warning:

Warning! This binary has an invalid existing platform digital signature.
  This situation could happen if you wrapped a binary that was already signed.
  Regardless, a new signature will be created now, using your specified credentials.

The certificate is still valid, it expires in october 2016, is my own and didn’t reject or do anything with it, except sign here on my “private” computer. I had no released software yet.

This wrapped plugin I can load in the productive ProTools, but it crashes (and now I can’t debug).

And the development ProTools still rejects any version, unsigned, apple signed, wrapped.

EDIT: as it turns out, it has nothing to do with loading jucer files, except that my confusion started with the leftover build script, I will open a new thread and link this one, sorry for the mess…

EDIT 2: Continuing here: AAX plugins created with 4.2 no longer loadable in ProTools development build


#13

Daniel - you have to be mindful of your NDA’s you’ve signed with third party companies on what you post on this forum

Rail


#14

Thanks @Rail_Jon_Rogut for the warning, indeed, I need to be carefull. I hope I’m still for good…


#15

If you update to the newest tip, all the AAX problems should be fixed now.