Re: Cocoa IN Audiounit
Re: Cocoa IN Audiounit
- Subject: Re: Cocoa IN Audiounit
- From: Marc Poirier <email@hidden>
- Date: Sat, 14 May 2005 09:22:41 -0400
Properties can pass not just individual "values" but arbitrarily sized
data arrays. That's why there's the size argument.
Marc
On May 14, 2005, at 2:28 AM, Chris Weare wrote:
Hi Bill,
Do you have advice for marshaling complex data sets accross the UI/AU
boundary?
For instance, if I have a spectrum viewer it seems rather tedeous to
repeatedly call the AU to get each bin. Currently, I'm passing the
address to a vector, which works fine so far, but would be a problem
if we are only supposed to pass by value, not reference, as you are
suggesting.
-chris
From: William Stewart <email@hidden>
To: Jeremy Jurksztowicz <email@hidden>
CC: email@hidden
Subject: Re: Cocoa IN Audiounit
Date: Fri, 13 May 2005 10:39:06 -0700
This kind of sounds to me like you are breaking a cardinal rule that
we strongly advise developers about... and that is to have a good
separation between the AU's implementation and the view. As much as
possible the only information that you should be sharing between the
two is data - definitely not objects, "this" pointers, etc - as all
of this assumes that your AU and its view is always going to run in
the same address space. That is not a good assumption.
There's an AU we shipped in Tiger as an "Extra AU" - its not in the
standard Tiger install. It can be found in /Developer/Extras/
CoreAudio - AU Looper. This AU, has a cocoa view and the interaction
between that and the AU is totally defined in terms of data transfer.
Whist on that topic - its good to have a look at how this works in AU
Lab - it also supports a property we defined in Tiger for mapping
MIDI messages "automagically" to Parameter value changes - this
implementation is provided in the Tiger SDK in AUMIDIBase and can be
enabled with a compile switch. There's a view for this MIDI Mapping
as well - if an AU Supports this property, AU Lab will put up a view
to allow a user to make mappings between a parameter and MIDI
messages. There are some preliminary comments about this property in
AudioUnitProperties.h as well
Bill
On 13/05/2005, at 10:01 AM, Jeremy Jurksztowicz wrote:
Hello,
So basically I have come to the following conclusion, please point
out any holes :)
My audio unit is being loaded, it then loads some cocoa classes.
Then when my cocoa bundle is loaded it also loads some cocoa
classes. Some of these classes are by necessity the same as classes
in my audiounit, so the audiounit and view can share data by these
classes. So, my solution is to put the classes shared between the
audiounit and the cocoa view bundle into a dylib. Now the audiounit
loads the dylib at OpenAComponent(...), and when the cocoa view
bundle is loaded, it locates the already loaded dylib and does not
reload the cocoa classes... right? So a couple of questions, is a
dylib good, or a framework perhaps is better? More importantly,
where do I store the dylib so that the audiounit, and the cocoa
view can link to it, while keeping them all together? I guess
somwhere in the audiounit.component but where, and do I need
special linker flags (probably) to help my products link right?
Thanks for all the feedback,
Jeremy Jurksztowicz
_______________________________________________
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