Re: Don't exchange pointers
Re: Don't exchange pointers
- Subject: Re: Don't exchange pointers
- From: William Stewart <email@hidden>
- Date: Tue, 20 Jun 2006 15:59:24 -0700
On 20/06/2006, at 11:40 AM, Ian Kemmish wrote:
On 20 Jun 2006, at 6:51 pm, Stefan Gretscher <email@hidden>
wrote:
Consider an environment like Logic Nodes where the audio processing
can be distributed to remote machines for utilizing additional CPU
resources, while the UI is working on the main machine - there's no
way to exchange pointers there.
(Logic Nodes are currently limited to Logics built-in plug-ins, but
there's a strong user demand to open up this technology for AUs as
well.)
Is there any chance of a heads-up on how this might work, Stefan?
I currently flatten all property data *except* for CFStringRefs, by
analogy with the existing conventional Apple properties.
For Apple defined properties the associated property IDs and their
values are well documented - so a host-in-the-middle can know how to
flatten out the CF types into something that can be transferred
safely across these boundaries.
A CFStringRef is just a typedef to const void*, so you have the same
problem with these as I alluded to earlier.
There seem to be various possible approaches for handling remote
procedure calls between the audio unit and its user interface:
1) The RPC code itself knows about which of the conventional Apple
properties pass strings, and flattens only those and nothing else.
This is somewhat unpleasant for third party developers (and would
be bound to lead to lots of repetitive "why?" emails here!), but at
least it's simple.
Yes
2) You allow strings and flattened data but nothing else, and there
is some adjunct to GetPropertyInfo that tells the host which
properties are strings.
That's potentially an interesting approach - some definition of a
standard set of private property layouts that would enable the host-
in-the-middle to know how to deal with this just as in your point above
3) AUBase provides a FlattenPropertyData method, which may be over-
ridden by audio units which have their own string properties beyond
the conventional ones. At first sight, this seems like a lot of
unnecessary work ("why not just flatten the data in your
GetProperty method?") - but in so far as it does all the flattening
in one place, and in so far as it could allow other Core Foundation
types (arrays, property lists etc.) to be used in the future, it's
probably the nicest in the long run.
I think we've been describing the desirability of this feature for
long enough that AU developers should already be doing something
about this (as we're discussing) - I don't see how adding an
additional Flatten call is going to help (its the same amount of work
for the AU somewhere)...
Bill
Third party developers could easily prepare for any of these in
advance, provided they knew which to prepare for (or None Of The
Above).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
Ian Kemmish 18 Durham Close, Biggleswade, Beds
SG18 8HZ
email@hidden Tel: +44 1767 601361 Mob: +44
7952 854387
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
_______________________________________________
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