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: Pavol Markovic <email@hidden>
- Date: Sun, 10 Dec 2017 08:47:07 +1300
Originally the AudioUnits framework was released only with Carbon support which
does not have the limitation of flat symbol namespace.
Cocoa support was added later (also because Carbon GUI does not exist in 64bit
OS). This does not affect just AudioUnits other plugin formats are affected as
well.
If you search back mailing archives you'll find Arne Scheffler from Steinberg
asking for the same thing as VSTGUI SDK needed to add support for Cocoa.
Both VSTGUI and JUCE workaround the problem in similar ways, they are both
open-source so anyone can look into how it's implemented.
> 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.
Btw. JUCE supports many plugin formats including AudioUnits.
Partial solution for AUv3 plugins is that they usually run in separate address
space (on iOS) so they are not affected by symbol name clashes.
Still on desktop the AUv3 can run within the plugin host address space... same
problem.
There is an official documentation for this, but that does not cover sharing
code base with several products (for wrapper-based plugins):
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/LoadingCode/Tasks/NameConflicts.html
I guess it's too late for debate whether Obj-C will have better support this
when it's obviously deprecated.
The right question is whether Swift already solves this problem.
PM
> On 29 Nov 2017, at 12:47, Brian Willoughby <email@hidden> wrote:
>
> 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
_______________________________________________
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