On Jan 30, 2006, at 6:07 PM, William Stewart wrote: Firstly, there is no such thing as a "this app, or that app" specific AudioUnit. AudioUnits are a platform standard and any host of a particular AU type (be it an effect, instrument, converter, etc) will see and can use your AU.
Thanks, I appreciate that from a technical perspective. From a marketing perspective, however, there is such a beast. Given that a great deal of host functionality seems to be selectively implemented by major host applications, it's something that a developer has to consider. In my case the company I'm working with is marketing the product specifically as a GarageBand add-on, and is disinterested in supporting other hosts. Particularly since explicitly supporting other hosts would in my opinion require at least minimal testing on those hosts, I see such a "marketing limitation" as having some degree of integrity, compared to promising compatibility that hasn't been tested.
That said, I'm familiar with the auval tool and have been running it regularly on my unit to ensure it meets a minimum of standard functionality. I'm not entirely sure what your concern is. The choices you make about implementation are your own.
Right - and I can make good or poor choices, like anybody else. Isn't every question on this list about implementation choices? My concern is "Hey I'm implementing an Audio Unit largely in Objective-C, and I have found little about this (and zero about bindings and AudioUnits) in the archives. Anybody want to share wisdom?" I have no further expectations than that. I apologize if you judge this an abuse of the list. We've been strongly advising developers for many years now not to assume that the view and the AU are executing within the same address space. We continue to maintain that position. The AUFilter demo we provide in the SDK provides an example of how private data can be shared between an AU and its view.
Thanks - that is something I missed. Part of this is definitely a deficiency of "accumulated wisdom" on my part. I know the newbie factor can be frustrating so I'm sorry for the degree of that I've brought in with this thread. Part of the problem is that CoreAudio has an impressive amount of documentation and example code, but it's distributed among several sources (ADC Library, Online Sample Code, CoreAudio SDK, and mailing lists at a minimum). So even though I've been dabbling in CoreAudio for a few years now, I still stumble on treasure troves of new information from time to time. I suppose one day I will no longer be a newbie and can ask smarter questions.
I appreciate your response. It helps, as usual :) And I'm sorry again for the frustration I sense I've caused,
Daniel
|