Re: Idle processing
Re: Idle processing
- Subject: Re: Idle processing
- From: Marc Poirier <email@hidden>
- Date: Tue, 25 Feb 2003 06:06:06 +0100 (CET)
RMS Buddy actually does not do what Glenn is trying to do, unfortunately.
I think that I know specifically what Glenn is after, coming from VST
experience just like he is. The VST editor API includes an idle method
which your editor can override. It will get called whenever the host
feels like it, but the basic idea is that it will get called pretty
regularly, but probably not so regularly if your system is under a really
big CPU load. The idea is that the calls occur in a low priority thread
and that the host manages how often they happen, so that those idle
updates can be deferred when the audio demands are high.
In comparison, what I do in RMS Buddy is to reconcile messaging from the
audio thread to the GUI thread by posting notification from the audio
thread via the ParameterListener system (where the messages enter a queue
rather than triggering the GUI reaction from the audio thread) and then
retrieving the actual data via custom property getting (which is an
immediate event, but which is then done from the GUI thread, when the
notification is read from the parameter listener event queue).
However, after writing all of this, I now realize that probably the
question to ask is: Glenn, why exactly do you want a VST-like idle
method? I know that in my experience, I've always used that method to do
some sort of polling, to check on some state to see if it changed, to get
new information when available, etc. But with AU, we have these property
notification and parameter notification mechanisms that are really nice
and eliminate the need for any of that polling. It's a much better way to
do all of that stuff. So anyway, if that sort of polling is what you are
wanting to do in your idle calls, then perhaps it's worth reconsidering
and instead using the better capabilities that AU provides. In which case
RMS Buddy actually would provide useful example code. ;)
Marc
On Mon, 24 Feb 2003, Bill Stewart wrote:
>
Marc Poirer just released some code that I think is exactly what you
>
are looking for...
>
>
See the message with the subject:
>
ANN: RMS Buddy AU, public example code, props to CA team
>
>
Bill
>
>
On Monday, February 24, 2003, at 09:37 AM, Glenn Olander wrote:
>
>
> I may be overlooking something, but I can't find any support
>
> in AU for idle processing, in other words a way to run non-
>
> critical tasks like GUI updating. Is there such a service?
>
>
>
> I can, of course, just run my own event loop timer, but idle
>
> processing needs to be adaptive...it should be called less
>
> frequently if the audio engine is busy, so the host should
>
> take that responsibility.
>
>
>
> - Glenn
_______________________________________________
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.