Re: Clarification of Write-only AudioUnit parameters
Re: Clarification of Write-only AudioUnit parameters
- Subject: Re: Clarification of Write-only AudioUnit parameters
- From: Chris Rogers <email@hidden>
- Date: Tue, 3 Dec 2002 11:53:47 -0800
Hi Brian,
I think your comments about read-only parameters sound good. The only
remaining difficulty seems to be the write-only parameters.
I did some thinking over the past couple of days about these to
see if I could come up with any reasonable use for them.
The example you give below about the write-only hardware register
isn't really reasonable in my opinion because any conceivable AudioUnit
representing a hardware DSP processor could always software cache
the parameter value. In this case the AudioUnit is a software wrapper
talking to the device and could always report the parameter as read/write.
The only reason I could think of for a parameter to be write-only is a
case where the value of the parameter ONLY has meaning at the instant
when the parameter is set. The instantaneous value of this parameter
would be taken into account somehow in the DSP operations and would
affect the audio output, but this value would make no sense to read
back at a later time. One can imagine a parameter which is a delta or
offset to tweak another parameter, such as changing pitch or speed by
delta rather than absolute, but maybe this is silly since it would
be more direct to just perform the delta outside of the AudioUnit?
Another case would be a set parameter which would inject a bit
of energy into some kind of synthesis or processing, perhaps exciting some
resonant frequency. But maybe this type of application would be
best handled by the MusicDevice (or MusicEffect) note APIs
(but maybe not for certain realtime control of playing notes)
In any case, I think it's fair to say that write-only parameters
would be fairly rare in actual practice. Any generic UI, like the
Apple generic AudioUnitView would want to completely ignore them.
Any custom UI would have intimate knowledge of the special meaning
of any such write-only parameters and would be able to put up a reasonable
interface representing them.
Chris Rogers
Core Audio
Apple Computer
Hi folks,
I'm not sure that we've fully hashed out the question of write-only
parameters
- at least *I* still have questions. Note, parts of the following
summary may
be obvious, insightful, or wrong - so please respond with your
feedback if you
have something to add or clarify or correct.
With Read-only parameters, it seems obvious that display of these values
should be only done via controls which do not respond to mouse or keyboard
input. One familiar example would be a VU meter. In any event, a normal
slider could not be used with read-only parameters, because the
Human Interface
would imply that the user can grab the slider to make a change. TextFields
should have editing turned off, so that the value is visible, but the user
cannot type in a new value. PopUpButtons would also seem to be verboten,
unless there is a way to stop them from popping up when clicked.
Write-only parameters are a little more difficult to envision. Being a
hardware person with a lot of device driver development experience, my first
thought was of write-only hardware chip registers. There are many
I/O devices,
especially the less expensive ones, which implement registers which can be
written to but not read from. If any user interaction depends upon
knowing the
previous value, it must be cached in software somewhere, because it cannot be
read back from the hardware no matter how hard you try. Typically, the
hardware driver hides this low-level detail by providing cached values in
driver memory where the value can be "read" even though the hardware does not
actually support literally reading it.
This analogy doesn't fully map to AudioUnits, since hardware-based AUs will
probably be a serious minority. It still makes sense that CoreAudio allows
even pure software-based AUs to advertise write-only parameters.
One issue that I particularly want to raise is this: It seems to me that Host
Applications are inherently required to cache the last value for any
write-only
parameter displayed. If I am correct in this, then it's probably something
that should be documented.
Another issue is whether there is any Human Interface Guideline that
can guide
us to the proper appearance for a write-only control. The typical control in
Aqua is a read+write control, and I'm wondering if we need a new class of
control appearances for manipulating write-only values.
Of course, if the Host App caches all write-only values locally, then it
becomes easier to provide controls for these parameters. Local caching
effectively turns a write-only parameter into a write+read
parameter. The one
thing to watch out for is that a write+read control differs from a read+write
control in that the current value of a write+read is not known until it has
been written at least once, while a read+write can be queried
initially before
being displayed.
Read-only controls are already common, such as VU meters, and non-editable
TextFields. It's only truly write-only controls that need a new
look in order
to provide intuitive feedback to users.
One final note: It also seems possible for an AudioUnit to cache values that
are "write-only" for whatever reason and then advertise them as
"read+write" in
order to simplify Host Apps. While the same trick cannot be implemented for
true read-only parameters, I'm wondering if it would be a good idea for the
AudioUnit documentation to recommend the caching variant of write-only
parameters wherever possible, but still define the case where write-only
parameters require special treatment by Host Apps.
Brian Willoughby
Sound Consulting
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.