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: MeldaProduction <email@hidden>
- Date: Thu, 06 Sep 2012 22:58:19 +0200
>
> 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 (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