Re: One Cocoa view for multiple AUs?
Re: One Cocoa view for multiple AUs?
- Subject: Re: One Cocoa view for multiple AUs?
- From: Brian Willoughby <email@hidden>
- Date: Sat, 7 Nov 2009 15:29:27 -0800
I believe that what you will have to do is make a map at run time
from the parameters of each of the embedded AUs, and then fold them
into your wrapper AU.
You'll have to query each of the embedded AUs for their entire
parameter list, and then build a map to avoid parameter ID collision
- you cannot simply add an offset to the parameter IDs because an AU
can use the full range. You might find that certain AUs have
parameters that range from 0 to N, but other AUs could easily have
sparse parameter ID numbers. I suppose if you're hard-coding the
embedded AUs, then you could make assumptions that the parameter IDs
will never change. In other words, you'll probably have to hash
translation from wrapper to embedded, unless you don't need a
universal solution and can live with a hard-coded translation.
Once you have the map, your wrapper AU would report the combined list
of parameters as its own. Then you need to rewrite the parameter
functions to detect whether a given parameter change is local or
intended for an embedded AU, passing the parameter change on when
necessary.
In addition, your wrapper AU will have to register for changes to
parameters in the embedded AUs, and handle changes which come from
the AUs by passing them on to the UI.
You could just build a custom UI for your wrapper AU which embeds two
views for the embedded AUs, but this would not work for the generic
view, so it would only be a partial solution. The only way to get
the generic view to work is to advertise the entire collection of
parameters as the wrapper AU's parameters.
Brian Willoughby
Sound Consulting
On Nov 7, 2009, at 14:44, ipmlists wrote:
Ian Kemmish gave me some good advice, but I think my problem is rather
more fundamental (and probably simpler) than stated above: how should
communication be set up between the view and those AUs which are
embedded in the wrapper AU (since the default setAU method only deals
with the wrapper AU)?
I've made some (unsuccessful) attempts at passing pointers to the
AUGraph and nodes as custom properties, but this feels like the wrong
thing to be doing, and certainly violates the principle of separation
between view and AU(s).
Is there a 'correct' way to do this?
_______________________________________________
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