• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Collision between Cocoa classes for AU and VST plugins
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 17:02:01 +0200

On Sep 7, 2012, at 4:19 PM, MeldaProduction <email@hidden> 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 (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

References: 
 >Re: Collision between Cocoa classes for AU and VST plugins (From: MeldaProduction <email@hidden>)
 >Re: Collision between Cocoa classes for AU and VST plugins (From: MeldaProduction <email@hidden>)
 >Re: Collision between Cocoa classes for AU and VST plugins (From: MeldaProduction <email@hidden>)
 >Re: Collision between Cocoa classes for AU and VST plugins (From: Uli Kusterer <email@hidden>)
 >Re: Collision between Cocoa classes for AU and VST plugins (From: MeldaProduction <email@hidden>)

  • Prev by Date: Re: autosavesInPlace and sandbox
  • Next by Date: Re: iOS popovers - View lifecycle.
  • Previous by thread: Re: Collision between Cocoa classes for AU and VST plugins
  • Next by thread: Re: Collision between Cocoa classes for AU and VST plugins
  • Index(es):
    • Date
    • Thread