On Sep 7, 2012, at 4:19 PM, MeldaProduction <i...@meldaproduction.com> wrote: > I'm afraid this is not possible. The executables must be the same. You must > understand that building 70 plugins is quite demanding and currently the 3 > interfaces would need 3x more time and space (which means 1.2GB compressed > !! ) just because stupidity of Cocoa design, total no-go. There are 2 more > interfaces to be available... No way. > Also with frameworks it is not possible for technical reasons as well. > I just need a way to create normal objects, never though such primitive > thing would be a problem... welcome to Apple... I'll try the runtime > creating I guess.
The plugins can be identical. You just have to make sure the code that they all share is loaded from the same place on disk. E.g. by making the plugin a thin wrapper that simply links to a framework that contains the actual classes and loads it from ~/Frameworks. If you install three copies of the same plugin, they all talk to the same framework, as it is only loaded once. However, this *only* works if you do not have to provide a main Cocoa class (i.e. the entry point to your plugins *must* be a function). If you must provide a class, just loading your plugin from two copies will load two conflicting classes. In that case, dynamically creating classes at runtime will not help you either. The problem you're running into is that classes in Objective C are more like application-wide services. Every class you instantiate gets entered into a list of all classes (this list is used by NSClassFromString() for instance, which is used by XIB files to instantiate an object of the named class. There can *never* be two classes with the same name in this registry. That is what is happening in your case. You have several options: - Share the code (as mentioned above) - do not install several copies of your plug-ins, e.g. by installing your plugin in a folder of your own (e.g. ~/Library/AUVSTMixedPlugins) and then symlinking them into the other folders. That way, the OS will notice that the plugin has already been loaded, and shouldn't load it twice. Of course this assumes that host applications can cope with symlinks. - Implement your plugins in terms of each other. I.e. create an AU plugin that simply passes all calls on to the VST (or vice versa). This is essentially a variant of the shared code method above. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
