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.
Vojtech 2012/9/7 Uli Kusterer <witness.of.teacht...@gmx.net> > > On 06.09.2012, at 23:16, MeldaProduction <i...@meldaproduction.com> wrote: > > Aaaah, ok ;) thanks. But now - will this actually help? I mean this > > basically takes one class and creates another class from it realtime. But > > if plugin A is created, then plugin B is created (which takes classes > from > > A unfortunatelly), wouldn't it also create the new classes from the A > > superclasses? Because I see no reason why it should do it a different > way. > > I can think of two options: > > 1) Name the classes differently. You can e.g. do so by adding a > -DBUILDING_AU resp. -DBUILDING_VST flag to the compiler options, and then > doing > > #if BUILDING_AU > #define TheClassName TheClassNameAU > #else > #define TheClassName TheClassNameVST > #endif > > Of course that is problematic if the duplicate classes are referenced in > XIB files, because there you have to use the actual name (i.e. with the AU > or VST suffix). > > 2) Share the classes using a framework used by both plug-ins. The OS will > notice that the framework is already loaded, and will simply reference the > classes in it. Of course, this means you will have to find another way to > switch between AU and VST interfaces, like using the Builder pattern to > have the base class return the proper AU or VST subclass depending on a > parameter passed in, while leaving the rest of the code identical. > > 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
