I fixed it on our end.

There are three things at work here, one on the C++ side and two on the Editor side.

The two separations are dependent on whether the action is question is done in the JS Layer or not.

1. If the Convolution IR is not a UI element that has savedInPreset set to true if any other UI element is and also targets the Convolution IR as a function of its parameter target, it will leak memory.
2. If the combo box selection (as demonstrated in both examples above) is done via the code as it's written, you will leak memory. However this also happens in the case where you manually select the IR via the file browser. I've identified as the culprit of this the way we deallocate the Convolution objects. They are queued for deletion in ConvolutionBase.cpp on line 673 and 674 for both channels. However, they never leave the deletion queue, so the copys that get sent there never run their destructors. This may be an issue with the deletion queue itself, however, I have changed those lines to use the reset() function of the convolution itself and that seems to solve the issue in the near term. Though I don't know the consequences of not queueing the deletion like @Christoph-Hart would.

        if(convolverL != nullptr)
        {
            convolverL.reset();
            convolverR.reset();
        }
        
        convolverL = s1;
        convolverR = s2;

3. In the event that number 1 is active, any preset change will leak memory. Whether through the PresetBrowser or not it will always leak. So if say in FL Studio the Instrument or Plugin is reinitialized or the preset changed and reloaded, it will always leak. We fixed all of this by including the ConvolutionIR itself in the preset.

That's all for now. I don't think it wise to make a PR with the above changes as I don't 100% trust my solution using reset() but it works in our testing and we'll be releasing an update to our primary library (all the plugins of which use this) today.

I'll let you know our results. Would be thrilled to hear any additional opinions.

Edit: loadAudioFilesIntoPool() is a red herring. I wouldn't bother looking into that. The issue is with the Convolution itself.

I fixed it on our end.

There are three things at work here, one on the C++ side and two on the Editor side.

The two separations are dependent on whether the action is question is done in the JS Layer or not.

1. If the Convolution IR is not a UI element that has savedInPreset set to true if any other UI element is and also targets the Convolution IR as a function of its parameter target, it will leak memory.
2. If the combo box selection (as demonstrated in both examples above) is done via the code as it's written, you will leak memory. However this also happens in the case where you manually select the IR via the file browser. I've identified as the culprit of this the way we deallocate the Convolution objects. They are queued for deletion in ConvolutionBase.cpp on line 673 and 674 for both channels. However, they never leave the deletion queue, so the copys that get sent there never run their destructors. This may be an issue with the deletion queue itself, however, I have changed those lines to use the reset() function of the convolution itself and that seems to solve the issue in the near term. Though I don't know the consequences of not queueing the deletion like @Christoph-Hart would.

        if(convolverL != nullptr)
        {
            convolverL.reset();
            convolverR.reset();
        }
        
        convolverL = s1;
        convolverR = s2;

3. In the event that number 1 is active, any preset change will leak memory. Whether through the PresetBrowser or not it will always leak. So if say in FL Studio the Instrument or Plugin is reinitialized or the preset changed and reloaded, it will always leak. We fixed all of this by including the ConvolutionIR itself in the preset.

That's all for now. I don't think it wise to make a PR with the above changes as I don't 100% trust my solution using reset() but it works in our testing and we'll be releasing an update to our primary library (all the plugins of which use this) today.

I'll let you know our results. Would be thrilled to hear any additional opinions.

Edit: loadAudioFilesIntoPool() is a red herring. I wouldn't bother looking into that. The issue is with the Convolution itself.