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: William Stewart <email@hidden>
- Date: Tue, 2 Mar 2010 13:02:54 -0800
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.
On Mar 2, 2010, at 12:35 PM, Jim Wintermyre wrote:
>> Actually, you can know this with the AU spec
>>
>> Two ways:
>> There are two properties that an AU should report about its processing, tail time and latency. Tail time we have described as being a conservative property (whereas latency should be accurate). Tail time is the time that it takes for you audio to go silent after the last real input has been presented to the AU - basically a reverb/delay decay time
>>
>> So, as a host you see this:
>>
>> 1st sample in -> appears in the output latency samples later
>> (the first latency number of samples out are silent)
>> last sample in -> you still have latency + tail samples within the AU that need to be "pulled through"
>> (feed in latency + tail samples of silence)
>>
>> If you want to align sample edges as a host, you would discard the latency samples of an audio unit from its output after the AU has been reset (or initialised)
>>
>> If you want to pull out all of the samples of an AU, you need to feed latency+tail number of samples into the AU. You will get back latency + tail samples (you already had to throw out latency samples at the start, so you need to get these back "after" the last sample of input)
>
> The latency value is essential for proper host operation (automatic delay compensation). The tail time is perhaps a little less useful IMO. Why? Because in many cases the tail time changes as parameters are adjusted (eg. reverb decay), and in some cases the tail time might not even be known (eg. resonant filter). So a host would have to query this value whenever a parameter in the plugin changes, and also properly deal with essentially infinite tail times.
>
>> The auprocess example we shipped for a while did this with effects (there are some additional notes in that example you can read if you are interested)
>>
>> For a AU host, you can use these numbers to load balance your plugins - once they have gone past an active segment, you can use these numbers to know how much additional data you need to pull through them. Once you have done that, any further "rendering" by that AU is wasted CPU cycles until you have new data to give it.
>>
>> Both Logic, STPro/FCP use these numbers to handle their rendering (as does QT actually), so many of the initial problems we had with these properties have been shaken out now.
>
> In my experience, Logic does NOT observe this, or at least does not use this as its sole technique for detemining when to stop calling plugins. I know this because we essentially report infinite tail time in some plugs for reasons mentioned above, but yet we see that Logic does still stop calling our plugins at some point anyway, basically when it thinks the plugin output is silent. I assume that it is measuring the plugin output, maybe using the track metering level and assuming some cutoff for being inaudible.
Well, this is inefficient, and it probably does this because you aren't providing a reasonable tail time. I think you should fix this (at least in the cases where you can, and I am sure that that will be the majority of the use-cases).
>
> 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.
>
> 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. 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"...?
Bill
_______________________________________________
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