Re: Clarification of Write-only AudioUnit parameters
Re: Clarification of Write-only AudioUnit parameters
- Subject: Re: Clarification of Write-only AudioUnit parameters
- From: Urs Heckmann <email@hidden>
- Date: Tue, 3 Dec 2002 12:02:25 +0100
Hi Brian,
you make good points, and maybe my understanding of a parameter is tied
too much to my practical view of things :-)
I think, a write only parameter in an AU only makes sense if there is a
system outside the AU that sets the parameter. The most obvious
external systems are the GUI class and MIDI input. But you could also
imagine the AudioStream or even any System state (i.e. copy protection
scheme) being a source for such parameter. My examples had been
UI-wise, which might have been a too narrow view.
What I think write-onlies have in common is that they naturally do not
belong to the preset/settings and thus shouldn't be handled by the host.
The thinking of a "triggered parameter" is how I used to do things in
VST. This aspect is even more obvious in AudioUnit design, as you can
easily adopt the notification scheme for triggering needs when using
write-onlies the way I interpret them. For clean designs I'd prefer
having only one type of notification/communication scheme which this
way could be resolved by using AU parameters only. That way my GUI
classes don't have to know anything about the AU and don't even need to
call any methods.
However, for a non-triggering only purpose, my GUI classes sport button
classes that increment or decrement parameter values, so as another
example given, when one extends the dev-button example, the parameter
could hold the number of the preset/settings to be written to the
console. (Though this is a lame example since you practically don't
save much work with it)
Cheers,
;) Urs
Am Dienstag, 03.12.02, um 10:30 Uhr (Europe/Berlin) schrieb Brian
Willoughby:
Urs Heckmann <email@hidden> writes:
[ Hi, I think your interpretation is indeed too close to physical
[ world :-)
You may very well be correct!
[ The typical write-only control is a labelled button that doesn't
[ alter its appearence after being clicked. If you do not add
[ another control, i.e. a display, or means like opening/closing
[ windows, you wouldn't notice any change.
I think it's important to distinguish between write-only parameters and
write-only UI. You've given an example of write-only UI, a button
trigger, but
I think it would help to consider examples of write-only parameters
with
numeric values, and how they should be displayed.
[ There is no reason why one should assume a write-only parameter
[ shouldn't be readable by any part of code. A read-only parameter
[ is _written_ by the dsp (i.e. a RMS value for a VU meter) and can
[ be read by the user interface. In my understanding, a write-only
[ parameter is written by the UI and _read_ by the dsp-part.
Yes, but a write-only parameter cannot be read by the UI, so perhaps
we need
some new Human Interface to indicate this (or maybe we don't). Since
the
AudioUnit cannot present UI, it seems sensible that the UI cannot
access a
write-only value. Maybe I would understand with examples of real-world
write-only AU parameters.
[ Some examples for write-only parameter applications:
[
[ A sample-load button: The GUI starts a filebrowser or something
[ and tells the dsp to be prepared to load a new sample, for
[ whatever any notification is needed before loading.
AudioUnits should not present UI. The parameter in this case would be
the
filename or file handle for the sample. There is no reason this file
selection
parameter should be write-only. Whether the GUI presents a
sample-load button
or a menu item is independent of the sample parameter itself. You've
given an
example of a write-only button (UI), but not a write-only parameter
(AU).
[ A development purpose button: I use to add a button to development
[ versions that write current _readable_ parameters to the console
[ or a file preformattet in C++ for copy/paste into preset setup
[ code.
This seems like a UI element. The AudioUnit should not even be aware
of your
dev purpose button. The Host App could use normal AU parameter access
to
obtain the values to log. From the point of view of the AU, pressing
the dev
purpose button would trigger a series of parameter reads, which the AU
should
not be able to distinguish from any typical parameter read.
On the other hand, I do see that the AU could log write-only values
this way.
Your dev purpose button in this case would really be a write-only
trigger.
It's not really a write-only parameter so much as a hack to get a log
subroutine to run in the AU. It's not really setting a value. It's
triggering
an action. I haven't really thought about triggering actions or
calling
methods in an AU under control of parameter access. Since this seems
to be
using parameter access for something other than what was intended, why
not use
a read-only parameter access to trigger the same log? ... or a
read+write
parameter?
[ A preset independent state button: Your AU provides modes for
[ special situations that shouldn't be treated like common
[ parameters. I.e. a "Master Quality Mode" button that you push
[ before you mix down a single AU instrument track with highest
[ quality (and worst cpu performance). This time you'd provide
[ feedback and have a on/off toggle or such.
If you provide feedback, then why wouldn't this be a read+write
parameter?
I guess I'm being stubborn, because I want an example of a real valued
parameter which is write-only, assuming the CoreAudio developers had
an example
in mind...
[ Of course, you're not limited to using buttons, but I think these
[ are the most obvious write-only controls...
Yeah, I do follow what you're saying. We do have an existing
write-only UI
element, and that's the button. But I'm trying to think of real AU
parameter
examples that are write-only. If they're continuous values like would
be
represented by a slider if they were read+write, then I'm wondering
what the UI
should look like if they're write-only. A button is a control that
can only
provide a trigger, but what kind of UI control can provide a numeric
value
without looking similar to a read+write control?
Maybe I should explain it another way: Say we have a parameter value
that
varies from 0 to 99 in whole number steps. If this were a read+write
parameter, then the UI would present a slider, and the user could see
the
current value. If, for some reason, the AU must treat a similar
parameter as
write-only, then what should the user see? How do they know what to
provide
for that parameter? Maybe it would be sufficient to draw the slider
with no
thumb, and then as soon as the user clicked on the slider, the thumb
would
appear and the value would be written to the AU. From then on, the
user would
see the most recent value.
Brian
_______________________________________________
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.