Re: Cocoa IN Audiounit
Re: Cocoa IN Audiounit
- Subject: Re: Cocoa IN Audiounit
- From: "Chris Weare" <email@hidden>
- Date: Fri, 13 May 2005 23:28:30 -0700
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
--
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
_______________________________________________
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