Re: Cocoa-Heavy Audio Unit
Re: Cocoa-Heavy Audio Unit
- Subject: Re: Cocoa-Heavy Audio Unit
- From: William Stewart <email@hidden>
- Date: Mon, 30 Jan 2006 19:12:03 -0800
On 30/01/2006, at 4:21 PM, Daniel Jalkut wrote:
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.
Not at all - as you surmise, this is a primary role of this list. I
guess I'm stating an obvious fact...
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,
No frustration - I'm trying to be clear and to understand the context
of your comments.
I think that this might also be worth a topic of further discussion -
might as well put the cat amongst the pigeons.
We've discussed with a number of people the suitability of using ObjC
for real-time (or better, time-constrained) implementations... It has
made us nervous, given that ObjC message sends are treated as an
opportunity for the ObjC runtime to re-evaluate its world, and thus
can not only involve locks, but also memory allocations. I would be
extremely concerned and extremely cautious about using ObjC in this
manner; for a view it is excellent of course. I'm sure others would
have a point of view about this...
Bill
Daniel
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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