Re: Two Audio Units with the same View class. Only one shows in DAW.
Re: Two Audio Units with the same View class. Only one shows in DAW.
- Subject: Re: Two Audio Units with the same View class. Only one shows in DAW.
- From: Brian Willoughby <email@hidden>
- Date: Tue, 28 Nov 2017 15:47:49 -0800
Ha!
The real question is why Apple imposed a totally incorrect design pattern for
loading the Cocoa UI - it's unlike the normal nib/xib UI loading pattern, and
far from optimal.
AudioUnits support Carbon UI, Cocoa UI, and a generic UI. Carbon is dead;
because it's not a very efficient framework for development. Cocoa is one of
the most powerful UI frameworks, but it happens to have a few minor limitations
for a plugin environment. There really isn't any other good option for the UI
of an AU, given that all macOS development is done in Cocoa, although the
generic UI available in the CoreAudioKit.framework is quite good for most
plugins.
Maybe someone wants to write a JUCE based UI for AudioUnits. We'd need a
separate Property so that hosts can find this third UI bundle, and then we'd
need hosts that will utilize it. Then again, I don't know whether JUCE works
well in a plugin environment. I seem to recall that it has some difficult
issues here, as well.
Brian Willoughby
On Nov 28, 2017, at 3:35 PM, Admiral Quality <email@hidden> wrote:
> So why did Apple impose an inappropriate language on...
>
> Oh never mind, answered that question as soon as I said "Apple". :/
>
> - M
>
> On Tue, Nov 28, 2017 at 6:32 PM, Brian Willoughby
>> Hi Mike,
>>
>> This AudioUnit issue is basically entirely due to a limitation of Objective
>> C. There are no namespaces in Objective C. I am a little surprised that
>> ObjC2 did not add a namespace feature. (*)
>>
>> Usually, the namespace collisions do not occur because most Cocoa developers
>> build all of their code into an application without plugins. The AudioUnit
>> case is somewhat unique, because ObjC code from many different developers
>> ends up being loaded into the same application (Logic, Live, etc.) where the
>> class name conflicts can occur. It's very hard to coordinate names among
>> different developers, so one solution is to register with Apple for a free
>> Creator Code and use that four-character string as a prefix to all custom
>> classes. Since Apple guarantees that Creator Codes will not conflict, that
>> guarantees the class names won't conflict between developers (if they use
>> this technique).
>>
>> Jeff has a particularly difficult challenge, because his wrapper is intended
>> to be used by many different developers. Unless the wrapper build
>> environment requires some sort of developer code, then there's no easy way
>> to segregate developers.
>>
>> By the way, Jeff, you could look into Xcode templates, where you could query
>> your wrapper users for a unique Manufacturer code that would then be used as
>> part of the CocoaUI class name. Not sure how much that would help.
>>
>> Brian Willoughby
>>
>> * In my opinion, the dynamic polymorphism features of ObjC are worth it,
>> even if they come with this namespace problem.
>>
>>
>> On Nov 28, 2017, at 3:22 PM, Admiral Quality <email@hidden> wrote:
>>> Have Apple ever explained why there's no namespace feature to avoid
>>> this nonsense?
>>>
>>> And yes, any UUID should do. A suitably long hash of the current time
>>> is probably a fairly safe bet.
>>>
>>> - Mike/AQ
_______________________________________________
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