On Feb 21, 2007, at 7:23 PM, William Stewart wrote:
I don't follow you.
What you describe is basically what AUParameterSet does.
We were surprised that AudioUnitSetParameter followed by AUParameterListenerNotify is not the same as simply calling AUParameterSet. It seems like a bug -- or maybe there's some subtle thing that is not clearly documented.
I'm concerned about doing VU Meters this way - it seems to me from your description that you would be changing the parameter value in your render call - if that ends up sending a notification each render call that is alot of notifications. VU Meters are better done by marking the parameter as a VU meter and then having the view poll for its value a few times a second to draw it (this is how we do the meters in the compressor/limiter AUs)
Yes, there is definitely merit to the approach you suggest. We are using an event-driven system along with a technique of reducing the number of messages sent. Whether that system is any better than polling remains to be seen . . .
Finally, I'm also confused about your comments about stopping the time line and showing problems in AULab - AULab does have a transport, but it doesn't have a timeline and has no notion of feeding silence to an AU. I'd be happy to look at this if you can see a problem in AULab and we can reproduce it here.
This is contrary to what I have observed. (I'm using AULab 1.0.3.) I can create a simple AULab project consisting of an AUAudioFilePlayer, then insert one of our AU plugins. As long as the audio engine is running, I can set a breakpoint in
ProcessBufferLists and the breakpoint will be triggered regardless of whether the transport is playing or paused. When the audio engine is stopped, (by clicking in the area that says "Audio Engine Running") ProcessBufferLists is no longer called. It sure looks to me like AULab feeds silence when the audio engine is running.