Copy AU/VST/RTAS script


#1

On the Mac, there’s this script that copies AU/VST/RTAS in their specific dirs. For me the copyVST flag is never set, because no symbol found that contains ‘VSTPlugin’, this is in the line:

For AU it works. And if I copy the .component into the VST dir and rename it, it also works. I assume that this test is wrong or not foolproof.


#2

Can’t see anything wrong with that, and I’ve been using the same script for years… Have you tried running a

to see what happens?


#3

Yes, nothing happens. But with ‘AudioUnit’ there are 3 entries.


#4

Hmm, weird. In the JUCE demo plugin “VSTPluginMain” actually shows up. In mine, it does not. But the plugin still works! That’s mysterious.


#5

Another thing is that I can find it in my plugin using a Hex Editor, but only 2 times, although it should be 3 times (ppc, intel32, intel64).


#6

Silly question, but are you sure you enabled the JucePlugin_Build_VST flag?


#7

ah… maybe the ‘nm’ command is looking at the wrong section of your binary, e.g. if you’ve built the 64-bit as only an AU, but the 32-bit as VST/AU, then if ‘nm’ only looks at the 64-bit symbols, it’d fail…


#8

Yes, the JucePlugin_Build_VST flag is set.
But what’s weird is, I just did an extra check. I compiled again as 32/64Bit Universal binary (AU+VST in one).
AU works for all platforms (PPC/Intel32+64), but VST only works for Intel. Could there be something wrong with a condition in the VST wrapper? I’ll check now…


#9

Hmm, try building as 64 Bit Intel only. After that, nm -g JuceDemoPlugin.component/Contents/MacOS/JuceDemoPlugin | grep -i ‘VSTPlugin’ doesn’t produce anything. But when using 32 Bit Universal as architecture setting, then you’ll get 2 values!


#10

hmm… Anyone know if there’s a command-line option for ‘nm’ that tells it to open a 64-bit binary?


#11

Yes, it seems there is:

nm -arch yourarchname
or
nm -arch all

I had the same problem, I thought the symbols were stripped during the link step, but it seems they were just hidden in an other section of the binary.

I’m building a universal 32/64 bits (i386 and x86_64 archs) plugin in VST/AU/RTAS, here is what I have:
[list]
[]AudioUnit: symbols are present in both archs.[/]
[]VST: _VSTPluginMain symbol is only present in i386 section.[/]
[]RTAS: _CProcess symbols are only present in i386 section.[/*][/list]

Maybe some of the symbols are shared between 32 and 64bit?


#12

Hello Jules,

Here the RTAS doesn’t get copied when in universal 32-64 bits.
Is there any solution that could be implemented inside the introjucer’s script ?

Thanks !

Salvator


#13

[quote=“Salvator”]Hello Jules,

Here the RTAS doesn’t get copied when in universal 32-64 bits.
Is there any solution that could be implemented inside the introjucer’s script ?

Thanks !

Salvator[/quote]

I don’t understand… why would the binary format make a difference to the process of copying the file?


#14

I don’t understand either. it seems to be picky and not consistent on my machine…

But at least, more recently, it’s definitively broken since the tip of 19 May GIT :

From then, even the juce plugin demo don’t get copied as RTAS. And I’m not on Linux either :roll:
With the tip before that, it works.

Salvator


#15

Ok, try it now…


#16

It almost works now. (Still testing with the Juce Demo plugin)

In debug no prob, but in release,it fail to copy the RTAS plugin when some architectures are specified in Xcode project’s settings :

  • “32-bit Intel” OK
  • “64-bit Intel” FAIL
  • “Standard 32/64-bit Intel” FAIL
  • other->“ppc” OK

Considering the RTAS don’t have 64 bits, I was guessing that it was just looking for ‘CProcess’ in the wrong binary ?

Salvator