Platform specific convolution engine problems

Hello, I have been running a marathon of tests for getting consistent results about convolution engine behaviour. Below is the simple code responsible for it (part of something huge) and the platform specific behavior.
// this is running in the process block. the ‘dryWetBuffer’ is a AudioSampleBuffer of which settings is done in prepareplay method. The ‘dryWetBuffer’ renders the signal to be processed by the convolution engine and after the convolution process it is being added to the ‘buffer’ of the process block. Practically the same principal in the demo example of Juce DSP.

dsp::AudioBlock<float> block (dryWetBuffer);
if (block.getNumChannels() > 2)
    block = block.getSubsetChannelBlock (0, 2);

process (dsp::ProcessContextReplacing<float> (block));

               0, // destChannel
               0, // destStartSample
               dryWetBuffer, // sourceBuffer
               0, // sourceChannel
               0, // soucreStartSample,
               myConvGain*3.5f * myConvSW// gain

               1, // destChannel
               0, // destStartSample
               dryWetBuffer, // sourceBuffer
               1, // sourceChannel
               0, // soucreStartSample,
               myConvGain*3.5f * myConvSW// gain

Here is the platform specific report; all systems / DAW’s are latest versions.


Juce 5.1.2 (I guess it is september version)

Logic : The convolution runs and sounds ok. AU validation passes at first time or second.
Live : Neither the VST nor the AU runs the convolution process, the sound is flat.
Reaper : Only the AU runs with correct convolution process, no conv. processing on VST.
Standalone : The convolution process works and sounds correct.

Juce Developer Branch / OSX

Logic : The convolution runs but I hear only full wet sound. AU validation passes directly.
Live : No convolution process, only flat sound.
Standalone : The convolution runs but only with full wet sound, as on Logic.


Juce 5.2.0 official release

Live : Convolution runs and sounds correctly.
Reaper : Convolution runs and sounds correctly.

So this clearly shows, that the same code ideally should behave the same in all DAW’s and plugin formats. I hope you can bring in useful explanations or this report will be useful for you for further fixes; or you are welcome to bring in a working code example.

Hello !

I don’t understand why you are showing examples of different platforms and different JUCE versions. I fixed recently some issues with the convolution engine class, so for starters you should use only the develop branch JUCE on Windows and macOS. We are not going to debug the previous releases of JUCE, it wouldn’t make any sense !

Then, could you provide the code of the whole PluginProcessor class, so we can see if something is wrong there ? I don’t know how you initialized the Convolution class, and how you set the IR, so I can’t help you for now until I have more information :wink:

Moreover, if you hear sometimes the dry signal + wet and sometimes the wet signal, obviously something is wrong with your code. For example, I think you should change the size of your audio block so its number of samples is the same than the one in buffer.

Thanks for the reply. I wirite them in order to show where it works! And obviously it is not working on your fixed develop branch in none of the cases. This is the reason I do this list, so that people can see how the same code works and does not work on which system, which format and which DAW! I don’t understand how you can call this a fix then :slight_smile:

This is a multi platform development environment. I am doing this table for you so that you are aware of these things! For me there are no documentation on what you have done between the official or developer branch, how it is effected by the code, in what sense. No precautions are given. I can understand your Juce DSP demo and trying to apply the same, that’s fine. However in my experience I can’t call that there is a fix, I am sorry!

If the same code works on the standalone version and Logic but not Ableton Live, behaves different between OSX and Windows, I think it is not the code to blame here directly , and yes I am trying different buffer sizes and monitoring that it is read correctly by the process block and the AudioSampleBuffers. Please understand that I have to keep the same code for all these systems, since I deliver cross platform solutions.

Here is how the convolution class is defined at the prepareplay method

auto channels = static_cast (2);
dsp::ProcessSpec spec { sampleRate, static_cast (samplesPerBlock), channels };
convolution.prepare (spec);

and for the AudioSampleBuffer which renders the dry signal for the convolution…

dryWetBuffer.setSize(2, buffersize);

in the process block inside the loop;

dryWetBuffer.setSample(0, i,2.0foutputEnvofClamp((sum[16]+sumN[16])*CrossAmp1+(sumP[16]+sumPN[16])*CrossAmp2, -1.5f, 1.5f));

dryWetBuffer.setSample(1, i,2.0foutputEnvofClamp((sum[17]+sumN[17])*CrossAmp1+(sumP[17]+sumPN[17])*CrossAmp2, -1.5f, 1.5f));

That’s all, nothing more to show really about the convolution part.

Hopefully this helps too,

best wishes

Sorry, but again there is nothing I can do if I don’t see the full code, and in your first example I can tell that the AudioBlock number of samples is wrong, because it can be higher than the buffer number of samples !

Are you recalling to this part ? Sorry, can you be more specific ? I just assign the AudioSampleBuffer which has the defined number of buffersamples by the process block, to the DSP Block object, as it was being done on the demo example as well.

Your dryWetBuffer has a size which can be higher than the size of the current block (it happens a lot in Logic Pro X and FL Studio) so you need to add that instruction before your process call :

block = block.getSubBlock(0, buffer.getNumSamples());

Otherwise, you will process more samples than what is provided by the buffer :wink: Remember that the size of your dryWetBuffer is set to the maximum potential size of the buffer in the processBlock function.

thanks for the info, let’s try then.

Hello Ivan,

There is little improvement. I can now get correct sound on Logic Au / Juce Developer Branch version. Before the sound was flat without the convolution.

Still no convolution effect on Ableton Live / Vst version; both Juce Developer Branch and Juce 5.1.2.

Any idea why Ableton Live e.g. VST does not run the convolution ? I have played a bit also with the buffer size settings on the DAW.

or if this thing becomes an endless loop like that; maybe you can propose the code for the following purpose;

  • I am filling a 2 ch. AudioBufferSample inside the process block serving as the dry content for the convolution process.

  • Then I process this with the convolution

  • Then I mix this result ( these 2 channels ) with the first 2 channels of the buffer object of the process block which contains the general output of the plugin.

I would love to see your interpretation, and this is all what is needed but creating so much cross platform problems. I hope it will be solved soon.


Have you tried to compile the DSP module plug-in demo from the develop branch (examples folder) to see if this works with all your DAWs + OSes ?

As I recall, in your DSP module demo, you are processing directly the buffer object of the process block. This is not my case here, again I am curious why this code works on some cases and not others (AU, standalone but not on VST)

So I have to find also solution which runs cross platform as the VST works on Windows but not on OSX.

As I am not the developer of any DAW listed here nor the operating systems, my hope with Juce is delivering me a cross platform solution. I can’t knock the support center of the DAW’s neither for this case, isn’t ?

This is not my case here

How is this different? It seems like you are just adding a dry/wet stage before the convolution and like Ivan said, you can’t expect every host to always give you the same buffer size so your algorithm needs to cope with that which is the reason why AU behaves differently as VST. Logic for example is known for changing the buffer size between playback and stop.

I have done what he says, it didn’t work. The behavior is the same, and it works on Logic for which you claim that it changes buffer sizes instantly. So the code is not affected by Logic’s buffer size changes. I can’t get any result on VST - OSX, I get it on Windows but not on OSX.

Is it more clear to you ?

A common fallacy that we often see on the forum is where people assume that because their code behaves OK in some hosts, then their code must be correct, even when it fails in other hosts.

They then assume the problem must lie with JUCE or the DAW or some other external thing, but usually it ends up being a subtle bug in their own code which is only triggered by a difference in the way a host behaves, e.g. it may use different buffer sizes, or channel layouts, or do threading differently, or the order in which the plugin and UI are initialised, or just the fact that the memory layout is different and this triggers some uninitialised variable stuff, etc. etc.

Ivan has been super-helpful here and my guess is that he’s probably right about buffer sizes being the cause, but like he said, it’s impossible for us to spot bugs in code that you don’t share. Often a good way to debug these things is to try to create a stand-alone piece of code that demonstrates the problem, and in 90% of cases, when you do that you’ll find the real bug.


I disagree with you. The time these new modules appear we have already our products arrived up to certain scale. It runs, it works cross platform and it sells. Now after trying to integrate a tiny amount of code of this DSP module, I face these problems which you also try to connect to UI intialisation, memory management and many underhood operations. Then it is logical to not to trust to any isolated demo example performance.

Are you in a feel that I try to neglect any opinions presented here ?

All I want is to pass this problem and move on to the next stage. However, I must express that you are not reading the facts I present here correctly, and directions based on experiences, assumptions, all with a lack of documentation is only useful up to some point. I try to use any bit of information however. You say Logic has tendency to change the buffer sizes during the operation etc., I say that it works in Logic but not as VST plugin in OSX ! Sorry, I don’t trust the behavior of your DSP framework by then.

While during the development in years, I don’t remember myself asking or pushing people for any solution on any matter on this forum. There were problems and then solutions, and I continued to use this cross platform environment which is the main reason I use it, since I don’t develop this product just for iOS.

I have programmed Core Audio applications for iOS using vDSP , SIMD programming etc. which are approved by Apple and run on multiple devices, just by reading the documentation of the relevant frameworks. I have developed my own framework. I can’t understand anything from your DSP module SIMD demo example !

Frankly speaking, if you do the marketing of your product as cross platform, does it mean that it may be cross platform if you can come up with the right code ? I understand the complexity of the situation with all these DAW’s, their updates and the system updates, compiler updates. The ground is changing all the time. The thing I don’t understand is that you throw it on my shoulders, and say that there is a subtle bug in the code.

Check out your definition of bug again ! If the code runs on Logic, Reaper (OSX), VST on Windows but not on OSX, that I don’t name it a bug !

happy new year!

Sorry, I think you’re misunderstanding me… I’m not saying that this is your fault, or that there isn’t a bug in JUCE.

If it’s our bug, then we apologise and will fix it. But you’re going to have to tell us where to look, because we’ve never seen it in any of the other thousands of juce plugins that are out there running quite happily in all the hosts you’ve named!

OK, well if it’s only a tiny bit, why not put that into some demonstration code that also fails, so we can debug it ourselves?

I don’t know what else we could suggest, as there’s just not enough info in what you’ve told us for anyone to be able to guess what else might be wrong…

1 Like

ok, thanks. I can share the whole process block code privately (about 1000 lines, and where should i send it ? There I can indicate the few lines responsable for the convolution process. Does this make sense ?

We’ll have a look at it next week if you want to PM it to me and Ivan

1 Like