Re: Collision between Cocoa classes for AU and VST plugins
Re: Collision between Cocoa classes for AU and VST plugins
- Subject: Re: Collision between Cocoa classes for AU and VST plugins
- From: Uli Kusterer <email@hidden>
- Date: Fri, 07 Sep 2012 10:49:12 +0200
On 06.09.2012, at 23:16, MeldaProduction <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden