Re: Collision between Cocoa classes for AU and VST plugins
Hi Guillaume, thank you for the info! One more thing I was posting above - since all the binaries are the same, is it really enough to create a duplicate class on runtime from it? It's just that if you load say AU first, then load VST, the system creates classes from AU, so why should it be duplicating the classes from VST? I'd normally assume Mac OS X would be as dumb as in the first case. Cheers! Vojtech http://www.meldaproduction.com/ 2012/9/17 Blue Cat Audio Dev d...@bluecataudio.com Hi Vojt?ch, The only way to handle this issue in your case seems to be using the objective c runtime APIs to dynamically create your objective C classes at runtime. This way you can give a unique name to the classes (either based on the address space or anything else), and it avoids clashes. It is also a good way to avoid clashes between different versions of the same plug-in (it may happen too). That's what we do for all our plug-ins and never had any problem. Regards, Guillaume Blue Cat Audio www.bluecataudio.com Quoting Vojt?ch Meluzín meldaproduct...@gmail.com: Hi, there are hosts that can use both AU and VST (and potentially VST3) interfaces for plugins. But there's a big catch - crappy Cocoa design. My plugins are obviously the same for all the interfaces and simply provide all interface implementations, so the they can be both AU and VST, just depending on where you put it and what extension you give to the bundle. BUT when you then use e.g. Ableton Live and open the same plugin first using VST and then using AU, boom you have a crash, because when VST has been open, system checked for Cocoa GUI classes in the VST version and then when you open the AU plugin it uses the GUI class from the VST version, because they have the same name! So it starts using resources from the VST version etc... lots of bad stuff can happen. How to solve it? For different plugins it is solved by adding some postfix to the class names, which is just sad, but at least it solved the issue. But here I don't see a way without providing different executables for VST and AU, which is a no go. Any ideas? Thanks! Vojtech __**_ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list (coreaudio-...@lists.apple.com**) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/**mailman/options/coreaudio-api/** meldaproduction%40gmail.comhttps://lists.apple.com/mailman/options/coreaudio-api/meldaproduction%40gmail.com This email sent to meldaproduct...@gmail.com -- ___ 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
Re: Collision between Cocoa classes for AU and VST plugins
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
Re: Collision between Cocoa classes for AU and VST plugins
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
Re: Collision between Cocoa classes for AU and VST plugins
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
Re: Collision between Cocoa classes for AU and VST plugins
there are hosts that can use both AU and VST (and potentially VST3) interfaces for plugins. But there's a big catch - crappy Cocoa design. My plugins are obviously the same for all the interfaces and simply provide all interface implementations, so the they can be both AU and VST, just depending on where you put it and what extension you give to the bundle. BUT when you then use e.g. Ableton Live and open the same plugin first using VST and then using AU, boom you have a crash, because when VST has been open, system checked for Cocoa GUI classes in the VST version and then when you open the AU plugin it uses the GUI class from the VST version, because they have the same name! So it starts using resources from the VST version etc... lots of bad stuff can happen. How to solve it? For different plugins it is solved by adding some postfix to the class names, which is just sad, but at least it solved the issue. But here I don't see a way without providing different executables for VST and AU, which is a no go. Any ideas? Create cocoa class at runtime You can check how this is done in Juce, especially in the AU wrapper. http://www.rawmaterialsoftware.com/juce/ HTH Thanks. One trouble - I checked and I didn't find any runtime cocoa class creation - they seem to have special Cocoa views for AU. But I'm worried about this, because even if I'd create special classes for all interfaces (which is sick, but ok...) by subclassing my default view class, what is the odds that the god damn system will use the class from the first loaded module anyway, they will be there too obviously. Any ideas? Or can you point me out into Juce, where the thing is supposed to be? Vojtech ___ 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
Re: Collision between Cocoa classes for AU and VST plugins
Create cocoa class at runtime You can check how this is done in Juce, especially in the AU wrapper. http://www.rawmaterialsoftware.com/juce/ HTH Thanks. One trouble - I checked and I didn't find any runtime cocoa class creation - they seem to have special Cocoa views for AU. But I'm worried about this, because even if I'd create special classes for all interfaces (which is sick, but ok...) by subclassing my default view class, what is the odds that the god damn system will use the class from the first loaded module anyway, they will be there too obviously. Any ideas? Or can you point me out into Juce, where the thing is supposed to be? Vojtech check juce_osx_ObjCHelpers.h, ObjCClass class and its use Thanks, but I must be missing something. I'm looking at Juce 2.0 and I found nothing that would even closely remind runtime cocoa class creation. juce_osx_ObjCHelpers.h only contains some postfix creation, similar to what I use in my plugins to ensure plugin A won't take classes from B. But I meant a different problem - in my case plugin A is actually the same as B, same binary, same resource, everything... But one is used as VST plugin, the other as AU plugin. Then the names of the classes are obviously the same, so I just need to ensure binary A will take classes from A despite they are also in B. Vojtech ___ 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
Re: Collision between Cocoa classes for AU and VST plugins
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. Vojtech 2012/9/6 Olivier Tristan o.tris...@uvi.net check the git version. This has changed recently. http://juce.git.sourceforge.net/git/gitweb.cgi?p=juce/juce;a=blob_plain;f=modules/juce_core/native/juce_osx_ObjCHelpers.h;h=6f643705923e6a0319ddcb7b4dd616a303500df7;hb=refs/heads/master On Thu, Sep 6, 2012 at 10:58 PM, MeldaProduction i...@meldaproduction.com wrote: Create cocoa class at runtime You can check how this is done in Juce, especially in the AU wrapper. http://www.rawmaterialsoftware.com/juce/ HTH Thanks. One trouble - I checked and I didn't find any runtime cocoa class creation - they seem to have special Cocoa views for AU. But I'm worried about this, because even if I'd create special classes for all interfaces (which is sick, but ok...) by subclassing my default view class, what is the odds that the god damn system will use the class from the first loaded module anyway, they will be there too obviously. Any ideas? Or can you point me out into Juce, where the thing is supposed to be? Vojtech check juce_osx_ObjCHelpers.h, ObjCClass class and its use Thanks, but I must be missing something. I'm looking at Juce 2.0 and I found nothing that would even closely remind runtime cocoa class creation. juce_osx_ObjCHelpers.h only contains some postfix creation, similar to what I use in my plugins to ensure plugin A won't take classes from B. But I meant a different problem - in my case plugin A is actually the same as B, same binary, same resource, everything... But one is used as VST plugin, the other as AU plugin. Then the names of the classes are obviously the same, so I just need to ensure binary A will take classes from A despite they are also in B. Vojtech -- [image: UVI] http://www.uvi.net/ Olivier Tristan | Research Development o.tris...@uvi.net o.tris...@ultimatesoundbank.com [image: Facebook] http://www.facebook.com/UVI.Official [image: Twitter]http://twitter.com/UVIofficial [image: Youtube] http://www.youtube.com/user/UVIofficial [image: SoundCloud] http://soundcloud.com/uvi-official [image: Blog UVI]http://blog.uvi.net/ ___ 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
