loadImpulseResponse() usage

Following the discussion with @edsut, @reuk, and @daniel that started here:

It was recommended we start a new thread.

I was mainly asking about the correct usage of loadImpulseResponse() when the change has to happen from the message thread. Say, following a button the user clicked, drag and drop of an IR file, etc.

When rewriting the convolution, we wanted the loadImpulseResponse methods to be wait-free, so that they could be called from the audio thread if necessary. However, making them wait free and also callable from any thread is quite complicated (I think we’d need a multiple-producer lockfree queue, which we don’t currently have in the library).

Perhaps in hindsight making these functions wait-free wasn’t the best trade-off. It seems quite rare that a plugin would need to call these functions from the audio thread (although perhaps a plugin may want to generate and load new convolution kernels in response to parameter changes…). At least the current implementation provides the option, though.

If you do need to load new IRs from events triggered in the main thread, you could use a queue, or some SpinLocked data which is try-locked on the audio thread. There’s an example of the spinlock approach in the ConvolutionDemo.

1 Like

Thank you for explaining that. Yeah, I can add another synchronization mechanism in this case, it’s just added complexity I was hoping already solved by the Convolution class.

I really think the docs need to be clarified in this case…