Hi all:
I have downloaded both the “canonical” 1.50 version of Juce, as well as the latest tip (as of last night) from the GIT repository. With both versions of the code, after fixing the references to the VST SDK, compiles, but the .component is not recognized by GarageBand or Live. Instead, it shows up in Finder as a Pro Tools plugin. Plus, the file is HUGE - 8.2 megs for the Release build, 5.3 megs for the Debug build. Any idea what is going on?
Thanks,
Sean Costello
Are you sure you’ve turned on
#define JucePlugin_Build_VST 1
#define JucePlugin_Build_AU 1
Also if you want it to be recognised as a VST you will need to rename the extension to .vst and put it in ~/Library/Audio/Plug-Ins/VST
Have you checked your plist file? I know there was problems with this but it should work fine from the tip now.
Dave.
Yeah, all those things are checked.
I have included some PT SDK files, as it seemed easier than deleting those folders. Still, I was building a .component file, and did not have the RTAS option enabled in the build, so this is frustrating.
It seems like every time I update my Juce files, the Demo Plugin ceases to compile properly. Why is this so unstable? I have to admit that it does not give me much faith in creating cross-platform plugins, if things are breaking all the time.
Sean Costello
Hmm. I just thought: if you’ve not got the RTAS SDK, you’ll be missing the CommonDebugSettings.xcconfig stuff, and there might be a few things in there that are necessary, maybe some flags to control the plist generation. I’ll try removing those files from my machine and check that the build works ok without them…
Ok, I found a couple of plist settings that needed a bit of tweaking - if you want to try the tip now, I’d be interested to hear if it helps your problem…
I still have the same problem. However, I figured out that I can change the “Open With…” property of the file in Finder, and get it to run as a standard Audio Unit.
I left all the RTAS files out of the build, but didn’t delete them. I will try building RTAS soon, but want to debug the AU/VST issues first.
One idea: Could you have separate targets for the different plugin types (VST, AU, RTAS)? I don’t know if this could reduce the problems for the non-RTAS users, but it might be helpful. The renaming of the generated file would also be automatic.
Sean Costello
Hi Sean,
For such copying & renaming of the single polymorphic plugin, I use a script.
Right click on your target, then add ->New build phase-> new run build phase. Then paste :
[code]vst=/Library/Audio/Plug-Ins/VST/"$PRODUCT_NAME".vst
if [ -d “$vst” ]
then rm -r “$vst"
fi
cp -r /Library/Audio/Plug-Ins/Components/”$PRODUCT_NAME".component “$vst”
RTAS=/Library/Application\ Support/Digidesign/Plug-Ins/"$PRODUCT_NAME".dpm
if [ -d “$RTAS” ]
then rm -r “$RTAS"
fi
cp -r /Library/Audio/Plug-Ins/Components/”$PRODUCT_NAME".component “$RTAS”[/code]
hope this helps,
Salvator
Good script!
…I wonder if there’s a way of telling the script which platforms the user has enabled, so it could avoid copying the RTAS if you don’t want it. It could be a bit confusing if the script created non-functional RTAS plugins every time you do a non-RTAS build.
[quote=“Salvator”]For such copying & renaming of the single polymorphic plugin, I use a script.
[/quote]
Nice! Thanks for this - I will try it out this morning.
Sean Costello
I tried the script. It works well, with a few slight modifications. The default Juce Demo Plugin installs the .component in my local user directory, so the copy commands didn’t work. The following script works very well for me:
vst=~/Library/Audio/Plug-Ins/VST/"$PRODUCT_NAME".vst
if [ -d "$vst" ]
then rm -r "$vst"
fi
cp -r ~/Library/Audio/Plug-Ins/Components/"$PRODUCT_NAME".component "$vst"
RTAS=/Library/Application\ Support/Digidesign/Plug-Ins/"$PRODUCT_NAME".dpm
if [ -d "$RTAS" ]
then rm -r "$RTAS"
fi
cp -r ~/Library/Audio/Plug-Ins/Components/"$PRODUCT_NAME".component "$RTAS"The generated plugins still show up as Pro Tools plugins on my system, for some reason - even the .vst file. However, Live and GarageBand both recognize the plugins (VST and AU for Live, AU for GarageBand) and are able to run them without crashing. Still, the fact that a .vst file shows up as a Pro Tools plugin is a bit disturbing.
Oh, and I deleted the plugin a bunch of times in Live 7, and no crash. So the Carbon bug seems like it is in better shape. Thanks, Jules!
Sean Costello (who is getting REALLY SERIOUS about Juce this week)
Don’t worry about them looking like PT plugins - it’s just because there’s a PT signature in there.
I’m currently working on an uber-script to do all this copying, which I’ll post as soon as I’ve figured out how to get sed to work properly…
Ok, here’s my suggestion for the script:
[code]copyVST=1
copyRTAS=1
original=$CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME
if [ $copyVST ]; then
VST=~/Library/Audio/Plug-Ins/VST/“$PRODUCT_NAME”.vst
if [ -d “$VST” ]; then
rm -r “$VST”
fi
cp -r “$original” “$VST”
sed -i -e ‘s/TDMwPTul/BNDLPTul/g’ “$VST/Contents/PkgInfo”
sed -i -e ‘s/TDMw/BNDL/g’ “$VST/Contents/$INFOPLIST_FILE”
fi
if [ $copyRTAS ]; then
RTAS=/Library/Application\ Support/Digidesign/Plug-Ins/“$PRODUCT_NAME”.dpm
if [ -d “$RTAS” ]; then
rm -r “$RTAS”
fi
cp -r “$original” “$RTAS”
fi
[/code]
I’ve been trying to think of a cunning way to detect which formats it needs to copy - perhaps by using nm to scan the symbol table of the binary…?
Aha! Check out the extreme cunning involved here!
[code]original=$CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME
copyVST=nm -g $CONFIGURATION_BUILD_DIR/$EXECUTABLE_PATH | grep -i 'VSTPlugin' | wc -l
copyRTAS=nm -g $CONFIGURATION_BUILD_DIR/$EXECUTABLE_PATH | grep -i 'CProcess' | wc -l
if [ $copyVST -gt 0 ]; then
echo “Copying to VST folder…”
VST=~/Library/Audio/Plug-Ins/VST/“$PRODUCT_NAME”.vst
if [ -d “$VST” ]; then
rm -r “$VST”
fi
cp -r “$original” “$VST”
sed -i -e ‘s/TDMwPTul/BNDLPTul/g’ “$VST/Contents/PkgInfo”
sed -i -e ‘s/TDMw/BNDL/g’ “$VST/Contents/$INFOPLIST_FILE”
fi
if [ $copyRTAS -gt 0 ]; then
echo “Copying to RTAS folder…”
RTAS=/Library/Application\ Support/Digidesign/Plug-Ins/“$PRODUCT_NAME”.dpm
if [ -d “$RTAS” ]; then
rm -r “$RTAS”
fi
cp -r “$original” “$RTAS”
fi
[/code]
Brillant !
It seems to work fine and just follow the checked format in JucePluginCharacteristics.h. Great ! 
Note though that if the plugin name has a space in it, then it doesn’t work.
I also noticed that in the vst bundle, (now recognized by KORE 2) there is 'duplicate - info.plist and info.plist-e / PkgInfo & PkgInfo-e. shouldn’t we delete those file with -e extension in the script ? (seems not to change the good behavior but for cleaning ? ) whatever it works anyway…
Thanks !
Salvator
Ok, we’re getting there. How about this:
# This script takes the build product and copies it to the AU, VST, and RTAS folders, depending on
# which plugin types you've built
original=$CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME
# this looks inside the binary to detect which platforms are needed..
copyAU=`nm -g "$CONFIGURATION_BUILD_DIR/$EXECUTABLE_PATH" | grep -i 'AudioUnit' | wc -l`
copyVST=`nm -g "$CONFIGURATION_BUILD_DIR/$EXECUTABLE_PATH" | grep -i 'VSTPlugin' | wc -l`
copyRTAS=`nm -g "$CONFIGURATION_BUILD_DIR/$EXECUTABLE_PATH" | grep -i 'CProcess' | wc -l`
if [ $copyAU -gt 0 ]; then
echo "Copying to AudioUnit folder..."
AU=~/Library/Audio/Plug-Ins/Components/$PRODUCT_NAME.component
if [ -d "$AU" ]; then
rm -r "$AU"
fi
cp -r "$original" "$AU"
sed -i "" -e 's/TDMwPTul/BNDLPTul/g' "$AU/Contents/PkgInfo"
sed -i "" -e 's/TDMw/BNDL/g' "$AU/Contents/$INFOPLIST_FILE"
fi
if [ $copyVST -gt 0 ]; then
echo "Copying to VST folder..."
VST=~/Library/Audio/Plug-Ins/VST/$PRODUCT_NAME.vst
if [ -d "$VST" ]; then
rm -r "$VST"
fi
cp -r "$original" "$VST"
sed -i "" -e 's/TDMwPTul/BNDLPTul/g' "$VST/Contents/PkgInfo"
sed -i "" -e 's/TDMw/BNDL/g' "$VST/Contents/$INFOPLIST_FILE"
fi
if [ $copyRTAS -gt 0 ]; then
echo "Copying to RTAS folder..."
RTAS=/Library/Application\ Support/Digidesign/Plug-Ins/$PRODUCT_NAME.dpm
if [ -d "$RTAS" ]; then
rm -r "$RTAS"
fi
cp -r "$original" "$RTAS"
fiOK, just downloaded the tip, made the recommended changes from the Readme (i.e. copied the /Developer/Examples/CoreAudio folder to /Developer/Extras/CoreAudio). I get the following new error when compiling the Juce Demo Plugin:
In Juce_AU_Resources.r, on the line
I get the following error:
I noticed that the AUResources.r file is not enabled in my build. Enabling it results in 9 errors, the above error plus 8 complaints along the lines of
Unidentified variable (RES_ID) not allowed in expression.
Expected number, but got ','
I commented out the #include “AUResources.r” and got things to compile, but now the Audio Unit doesn’t show up in my AU hosts. The VST shows up in Live, though.
I’m not sure if this is due to a change introduced by Jules in the past day, or if it is due to some issue with creating a new CoreAudio folder under Extras, such that the Juce project has files to point to.
Any ideas?
Thanks,
Sean Costello
You need to make sure your project has the correct search path for resource include files… I’m sure I mentioned that in the howto file, didn’t I?
Not sure if you did. I just reread the howto doc, and it mentions having the correct header path for the vstsdk2.4 and all the Digi files, but nothing specific about resource include files.
Is there a specific way to have resources included?
Sean
Ok, I’ll elucidate that in the help doc.
It’s the ‘Rez Search Paths’ setting that you need to fiddle with.
