Re: is Audio Unit and its View in separate host machines possible?
Re: is Audio Unit and its View in separate host machines possible?
- Subject: Re: is Audio Unit and its View in separate host machines possible?
- From: Brian Willoughby <email@hidden>
- Date: Wed, 15 Jul 2009 16:25:07 -0700
On Jul 15, 2009, at 15:56, Alejandro wrote:
Our app is doing exactly what you say, but with a generic view of
course. I see that what we must do is open the custom view in the
client side and establish communication through events.
I don't think that you absolutely must open the custom view. All you
really need is a way for the user to see the parameters and change
them. A generic view accomplishes this. Once the parameter change
messages are sent, the receiver has no knowledge of whether they came
from the custom view or a generic view.
There are a few AudioUnits where the custom view is required, simply
because the developers could not find a way to accomplish everything
they need through parameters alone. I am not sure how you would
detect this situation, but you'll certainly need to open the custom
view on the client side in these rare cases.
I'm also not sure how you would determine which property changes
might be needed, but there are certainly cases where parameters are
not sufficient, and property changes are used.
The Audio Unit Programming Guide says that the audio unit must be
instantiated (not necessarily initialized) before the view is open.
Does this mean that we must instantiate the component in the client
side? Then additional licenses must be purchased...
The answer depends upon whether you want a generic view, and also
whether a generic view will offer the complete interface. If you
want to avoid multiple licenses, then you will have to go with a
generic view. It seems entirely possible for your 'server' side to
query the entire list of parameters and associate date, transfer this
across to the client side using a proprietary method of your own
design, and then build a generic view.
If you need or want the custom view, then the only way to get to it
is via instantiating the component. What I would be curious about is
whether you can query the component on your 'server' side, then
convey the results to your client side so that you can instantiate
only the custom view and not the component. If I recall correctly,
the process is to instantiate the component and then ask it for the
bundle which provides the custom view. If the bundle for the
component and the custom view are the same, then you'll certainly
need to instantiate the component on the client side. However, I
believe it is possible for the AU developer to provide a different
bundle for the component and the custom view, in which case you might
be able to instantiate only the custom view bundle on the client
side, after discovering the bundle identification on the 'server' side.
The caveat to the above is that I certainly have not tried everything
I suggest is possible. I also may be mistaken about the complete
details of instantiating the custom view.
In any event, it certainly seems possible for you to use a generic
view for the vast majority of AudioUnits. For example, my free AU
release have no custom view, and thus it would certainly work if you
remote control them from a generic view on another host. In this
case, you could discover this on the 'server' side by querying my AU
component for the custom view, and your code should notice that there
is no custom view to be found. If you communicate that information
to your client side, then you would know for certain that you don't
have to instantiate the component when you already know that there is
no custom view. This is probably a rare case, but certainly valid.
Brian Willoughby
Sound Consulting
_______________________________________________
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