# loadImpulseResponse() usage **URL:** \ **Category:** General JUCE discussion\ **Created:** [July 23, 2021, 12:46pm UTC](https://forum.juce.com/t/loadimpulseresponse-usage/47042 "2021-07-23T12:46:44Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [July 23, 2021, 12:46pm UTC](https://forum.juce.com/t/loadimpulseresponse-usage/47042/1 "2021-07-23T12:46:44Z")
Following the discussion with @edsut, @reuk, and @daniel that started here: > [@.jucer GUI project run on Linux without desktop... can I?](https://forum.juce.com/t/jucer-gui-project-run-on-linux-without-desktop-can-i/46995/23): > > You shouldn’t create any Component at all. They will when added to the desktop create a ComponentPeer, which is the connection to the window system. From that point the X libraries will be loaded and it won’t run without X11. You can use AudioDeviceManager to open the audio device and AudioSourcePlayer to play from any kind of AudioSource. Hosting AudioProcessors is already tricky, I don’t know if it will work, since the createEditor() will return a Component. The juce\_audio\_processors depend… 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. ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [July 23, 2021, 1:05pm UTC](https://forum.juce.com/t/loadimpulseresponse-usage/47042/2 "2021-07-23T13:05:38Z")
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. ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [July 23, 2021, 1:12pm UTC](https://forum.juce.com/t/loadimpulseresponse-usage/47042/3 "2021-07-23T13:12:50Z")
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…