Apple

On May 31, 2016, at 2:38 PM, Paul Davis <email@hidden> wrote:

On Tue, May 31, 2016 at 5:27 PM, Howard Moon <email@hidden> wrote:
Hi Paul, thanks for the reply.

So, for our change to take affect in your hosts, the user would have to make the change in our plug-in, start the transport, and then STOP it again before the change was picked up? Not the best scenario from our users’ point of view, but at least that is something we can tell users who inquire.

That's more or less correct. The user can make the change in the plugin whenever they want, however. It is just that the change will not be acted upon (or even detected) until a transport stop. They cannot make the change and expect that our hosts will respond immediately/dynamically - while the transport keeps rolling things will not be correctly latency-adjusted.

We happen to think that it is a better scenario for the user than the alternative of responding immediately, because our anywhere-to-anywhere topology for routing makes it essentially impossible to adjust to new plugin latency without causing clicks. So we defer the adjustment to a time when the chance of it causing clicks is dramatically reduced.

References:
	>kAudioUnitProperty_Latency property changes and Logic (From: Howard Moon <email@hidden>)
	>Re: kAudioUnitProperty_Latency property changes and Logic (From: Paul Davis <email@hidden>)
	>Re: kAudioUnitProperty_Latency property changes and Logic (From: Howard Moon <email@hidden>)
	>Re: kAudioUnitProperty_Latency property changes and Logic (From: Paul Davis <email@hidden>)