User-agent: Internet Messaging Program (IMP) H3 (4.3.11)
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.
Blue Cat Audio
Quoting Vojt?ch Meluzín <email@hidden>:
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.
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