• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Clarification of Write-only AudioUnit parameters
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 09:03:38 +0100

Am Dienstag, 03.12.02, um 03:08 Uhr (Europe/Berlin) schrieb Brian Willoughby:

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.

Hi, I think your interpretation is indeed too close to physical world :-)

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.

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.

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.

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.

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.

Of course, you're not limited to using buttons, but I think these are the most obvious write-only controls...

Chees,

;) Urs


-----------
urs heckmann
email@hidden
www.u-he.com
-----------
_______________________________________________
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.

  • Prev by Date: Drawing a streaming waveform..
  • Next by Date: Re: Clarification of Write-only AudioUnit parameters
  • Previous by thread: Drawing a streaming waveform..
  • Next by thread: Re: Clarification of Write-only AudioUnit parameters
  • Index(es):
    • Date
    • Thread