Re: SetProperty/GetProperty
Re: SetProperty/GetProperty
- Subject: Re: SetProperty/GetProperty
- From: philippe wicker <email@hidden>
- Date: Thu, 16 Nov 2006 20:11:15 +0100
On Nov 16, 2006, at 3:37 PM, Sebastien Beaulieu wrote:
Hi all,
William Stewart wrote:
At some point the host would have to marshall this... So the care
that needs to be taken is this - don't embed pointers in these
structs, but rather have the memory you pass in to the Get/Set
calls be flat and complete. So, in your example above how you have
this is fine (presuming of course that retval is a value not an
address!).
While we are on the subject, here's one I don't remember being
discussed before:
How would the AU / View residing on different machines work with
files?
The file dialog would be showing up on the "View" machine and would
select file(s) the "AU" machine can't access. While for small files
it would be possible to either have the View know what to do or
send/receive a blob to/from the AU, there are cases where this makes
no sense. As a concrete example, audio files being streamed from or to
disk.
I'm facing the same kind of problem. This is a draft of how I plan to
solve it.
- the view exists in 2 flavors: the one that resides on the machine
displaying the graphics (that I call the "view"), and a proxy
residing on the "au" machine (that I call the "view proxy") which
role is to decode and transmit messages to the "au" just as would
have done the view if the au was residing on the same machine. This
"view proxy" is only needed if host applications (or the CoreAudio
runtime) does not provide a marshal/transport/unmarshal layer. Logic
certainly have such a layer for its own plugins, the "view proxy"
role being played by the application that have to be started on the
node machine.
- "real" files are resident on the "au" machine (by "au" I mean the
machine actually performing the streaming and the rendering).
- the view must know about the "au" files' tree. For the view, this
tree is virtual, it is just a description in whatever format of the
file hierarchy of the "au" machine (e.g. the samples needed by a
sample based MusicDevice).
- the file hierarchy on the "au" machine may be queried using a
GetProperty call or agreed upon at some time and refreshed when the
user asks for it.
- the view provides a navigation GUI that allows the user to choose a
file.
- the view then marshals the relative path (e.g. /Drums/Rock1/Snare1)
of the file and sends a message to the au using the standard
SetProperty mechanism (assuming that the au framework handles the
transport of the marshaled parameters, otherwise you would have to
develop your own transport library).
--
Plogue Art et Technologie Inc.
Montreal. http://www.plogue.com
_______________________________________________
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