I know its an old issue, but i'm not sure why i get this error in auval (El Captian) ?
With the latest plugin-copy script, the removing of the AudioComponents-Tag will not happen, and than auval (OS-X El Captian) shows the warning:
"trouble parsing Info.plist's AudioComponents"
I uses lastest Base-SDK and OS-X comptibilty version 10.6.
Is this something we have to be worried about?
This was the commit which removes the the AudioComponent removal, what was the reason for this?
https://github.com/julianstorer/JUCE/commit/3a7c138f02468c114ee5b35347c59b11ef5ea3fa
The old "removing AudioComponents" behavior was the right, or not?
The commit message was:
"Fixed broken AudioUnit post build script (was removing Info.plist entries if custom SDK paths are used)."
wich doesn't make sense, because AFAIK at this moment the the AU-SDK Files were shipped by JUCE and the removal took happen when the SDK Files were NOT at the ancient File-location, so the removal always happend.
Now the AudioComponent will never removed, which creates the auval-issue.
OK, what you are saying seems to make sense but I am having trouble really understanding what we should do instead...
what is the exact change/fix that you suggest here?
I don't now. If the AudioComponents-Tag belong to the plist- why auval creates the error?
I couldn't detect any malfunction without the AudioComponents-Tag
Hm. I don't know either. I vaguely remember it has something to do with two different ways of doing an AudioUnit, one older and one newer (something related to Factories and entry points...)
We'll dig and try to sort this out.
Hmmmm … this issue just started showing up for me too.
Oddly, I can alter the plist to be appropriate … but then I get “cannot find component -1”, presumably because the entry point is not set properly.
Perhaps the new system does something differently around the factory function location?
Ok - doing this fun trick:
nm ~/Library/Audio/Plug-Ins/Components/myComponent.component/Contents/MacOS/MyComponent | grep Factory
I was able to see that the factory method was named incorrectly.
I would think it regenerates that each time? But it’s somehow keeping some sort of persistence here (maybe an xcode thing).
Really strange.
Playing around more, I notice that changing the factory method in the plist doesn’t seem to automatically change what factory method is being generated … even with a clean/rebuild.
So … no idea why this is so hard all of a sudden, maybe just my computer is mad at me.
Is that a wrong name that was generated by the Projucer? If so, could you please provide some details as to what exactly is wrong where and how it should be instead so we can fix it? Many thanks!
Well yeah, the plist is just another one of those files that get generated. The hosts may use it to look up the factory method name but it doesn’t influence the rest of the project generation.
Yeah, this was just xcode weirdness. I’m using an older project (no ProJucer), I’m sure the ProJucer sticks to the proper naming conventions.
So are you saying that with a clean version of the newest JUCE everything works?
More or less, with a few exceptions:
The VST version AUv3 synth wont show up in ableton for some reason (it does show up in the juce plugin host)
The AAX version still has the problem mentioned in the other thread (there is a definition that apparently needs to be added to the plugin_client code), otherwise the AAX versions don’t work
I’m generally still using the wrappers directly too, so that I can compile a polymorphic plugin and then post-script it as needed … seems like the easiest way to get multiple plugins in one project (I have a half dozen coming from one project).
I like your plugin example project, but I don’t see how I could add multiple plugs to it unfortunately (since the base shared code needs createPluginFilter() code in it). Please let me know if you have any better suggestion.
What version of Ableton are you using? If it’s an older one, it may be related to this problem which I am still in the process of fixing.
I committed a fix for this about 2 hours ago (SHA 92a1747f), did you check if that fixes the problem?
Would be great to know what prevents you from using the new target system to get everything in one project? In the new system you also don’t need a post build script anymore.
What do you mean by “multiple plugs”?
Ah great, didn’t see that fix, thanks.\
By multiple plugs, I mean for example, a Delay plugin and a Filter plugin from the same project (each in multiple formats - VST, VST3, AU - of course).
I currently use multiple targets in the same project to do this.
Since the new example code already uses targets for plugin type separation, this become difficult.
Would it be easy to move the pluginprocessor code to the individual targets instead of having it in the shared code target? Then it would be easy to have multiple plugins in one project, since the “shared code” portion would include all the juce and user code, but not the plugin specific code.
Not sure if that’s possible though, since the framework would have to be happy without any entrance function. Juce_core also needs an entrance point I think?
Anyway, no biggie, I may eventually build out individual projects for each plugin … though it would mean that any time I change a setting or add a file, I need to do it many times instead of once. hmmm …
Also - regarding AUv3 synth … the post you reference is talking about an AU version that doesn’t load. I’m saying the VST version isn’t loading.
Thats on mac, ableton version 9.2.3
In the new world, I would advise against manually setting up targets. As you already noticed, this interferes with the Projucer using the targets for the different plug-in formats. Instead, you could set up an Xcode workspace to hold multiple Xcode projects.
hm… so, I don’t get it, which one does not load? The AU, the VST, or both??
In case it’s the AU, please try the fix I just committed (SHA 7d644173), that should restore compatibility with older versions of Live.
Timur, have you tested 4.2 with a popular copy protection system where we already have multiple targets in our Xcode projects?
(I’m personally stuck at 4.0 until the MultiBus/AudioProcessorGraph issue is fixed)
Rail
Okay, I know this is an old thread… but my plugin scanner is using the tip and recently built a “bad” test plugin and when scanning… even after removing the component from the Plug-Ins folder and clearing the AU Cache when scanning in:
AudioUnitPluginFormat::searchPathsForPlugins()
comp = AudioComponentFindNext (comp, &desc);
generates:
2017-04-03 15:03:22.533 PluginScanner[74519:1270178] 15:03:22.533 WARNING: >compload> 472: (null): trouble parsing Info.plist's AudioComponents, key (null); entry: {
description = VeryBadPlugin;
factoryFunction = VeryBadPluginAUFactoryAUv3;
manufacturer = Manu;
name = "Platinum Samples: VeryBadPlugin";
sandboxSafe = 1;
subtype = Qs5j;
tags = (
Synth
);
type = "kAudioUnitType_MusicDevice";
version = 65536;
}
I also have another plugin which is my main plugin and it gets a similar warning. My non-Synth plugins don’t seem to generate the warning.
All plugins scan fine though (except obviously the “bad” plugin which is designed to crash 
) so I’m ignoring the warning… but I was wondering how to clear the MacOS cache… this warning persists even after a restart.
Cheers,
Rail
