Re: Does anybody implement 'reset' in their Instrument Audio Units?
Re: Does anybody implement 'reset' in their Instrument Audio Units?
- Subject: Re: Does anybody implement 'reset' in their Instrument Audio Units?
- From: Jim Wintermyre <email@hidden>
- Date: Tue, 2 Mar 2010 16:10:07 -0800
At 1:02 PM -0800 3/2/10, William Stewart wrote:
On Mar 2, 2010, at 12:47 PM, Jim Wintermyre wrote:
At 12:42 PM -0800 3/2/10, James McCartney wrote:
On Mar 2, 2010, at 12:35 PM, Jim Wintermyre wrote:
and in some cases the tail time might not even be known (eg.
resonant filter).
The ring time of a filter can be computed from its Q.
I thought in some IIR cases it couldn't, but honestly it's been so
long that I don't remember. What I do know is that we have several
plugins that have additional nonlinearities/randomness/other DSP
weirdness/etc etc that make it impossible to exactly know the tail
time. So the original point remains the same.
Actually, no it doesn't.
We explicitly describe tail time as a CONSERVATIVE estimate - we
don't expect this to be sample accurate, and we understand there are
cases where this can be difficult to assess. A host can get to the
point where it needs to know tail time, and ask the AU at the point
- you can make a reasonable calculation at that time based on your
state.
Not trying to get into an argument here, just noting that it seems to
me that there are a lot more subtleties with how tail time should be
treated both from the host and plugin perspective, vs latency which
is pretty clear. For those difficult to assess cases, it could be
useful to have an "always call me" flag or some standard that says if
the tail time is above X seconds, assume it's unknown so always call
me.
> Also, I recall that in DP (at least in an older version, maybe
4.6, dunno if this is still the case), if the reported tail time was
very large (like more than the number of seconds in a day), it is
ignored and the plugin is always called.
Yes - which is a fine use for tail time IF that is really what is happening.
This has ramifications for users, so I would encourage you to fix
this. If you are spending alot of cycles processing and generating
silence, you are not really providing a good user experience. For
battery life, heat (which also affects how fast a processor can be
run)... all kinds of issues.
The "running on external hardware" factor brings up other issues that
can be tough to balance with these. In our case we can gain a lot of
efficiencies by actually being called consistently. From a host
point of view, the render time is tiny because the processing is
being done on external hardware, so it's not the same as a host
plugin doing a bunch of host CPU processing that ends up producing
silent output in the end. From that perspective, this is a case
where a flag saying "always call me" like someone recently suggested
would be useful. As it is, we already have special-case code in
various hosts, and we do special-case stuff on our end depending on
the host, when it would have been cleaner to have this be part of the
spec. We can discuss our specific needs and limitations in more
detail if you like offline.
> In our case, this all comes into play because it can be
problematic if the host stops calling the plugin without some sort
of notification that is about to do so, because we are running on
hardware and have more complications with state management vs.
normal host-based plugins. So it is useful to either be able to
tell the host "always call me" (eg. infinite tail time), or "notify
me if you're going to stop calling me" (eg. sending AUReset). But
then we're back to the original problem where not all plugins
implement AUReset properly, so the host mfg may not want to call
that... or they have to special-case it for different plugins!
Sigh. The joys of plugin/host development. :)
Well, that raises an interesting point.
First: Reset is not defined to be something that you would call
before you stop.
Some hosts do...
It is called as a prelude to when you would start again. Maybe we
should add a property along the lines of "i need to know when you
are going to stop calling me"...?
Yes, that would be useful for us in particular. I suggested AUReset
because that is the only thing in the current spec that is close to
what we need. But then that tends to dilute the meaning of AUReset,
resulting in different hosts assuming they can use it in different
ways (similar to the confusion with AU bypass which we discussed a
while back).
The problem, of course, is the chicken-and-egg issue where even if
you add it, we have to get hosts to adopt it before we can count on
it, and this sort of thing is always a hard sell if it isn't required
for host-based plugins.
Thanks,
Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden