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: Blue Cat Audio Dev <email@hidden>
- Date: Thu, 20 Sep 2012 11:30:03 +0200
Do you mean that the AU and the VST binaries are duplicated in their
own folders, or do you mean that it is the exact same file (single
absolute path) that is loaded? If it is different absolute paths, you
have to have different names, because otherwise the code for the
objective C classes may be unloaded with the bundle (bundle unloading
is not properly supported by objective C, even if you unregister your
classes on unload I think).
Anyway, it is probably safer to have different class names, in case
your customer has different versions for the AU and the VST (trust me,
it may happen :)). The way we do it is to use the base address of the
loaded binary to create the class names, so that you can be sure you
cannot have conflicts, in case different versions of the same binary
are loaded at the same time.
The idea with objective C is that all your binaries share a global
namespace at runtime, which is the reason for clashes. With C and C++
it is safe because each binary (virtually) has its own local
namespace. So what you need to do is to make sure that for a given
binary *file* (uniqueness defined by its absolute path) that is loaded
at runtime, its objective C classe names are unique.
Hope this helps!
Guillaume
Blue Cat Audio
www.bluecataudio.com
Quoting MeldaProduction <email@hidden>:
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 <email@hidden>
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 <email@hidden>:
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 (email@hidden**)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/**mailman/options/coreaudio-api/**
This email sent to email@hidden
--
----- End forwarded message -----
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden