I am using in my code juce::dsp::AudioBlock::copyTo method, because I need a temporary copy of the input signal. After upgrading JUCE to 5.4.4 I got an error while compiling:
tempBuffer is of type AudioBuffer<float>, but for some reason AudioBlock::copyTo expects AudioBlock<const float>, if I understand the error message correctly. What does not make sense because copyTo would modify buffer.
IMHO the problem is return type of context.getInputBlock().
I double checked on Windows that this code compiles with JUCE 5.4.3. On MacOSX I only checked that this is not compiling with 5.4.4.
Could you please help me to resolve this? I have no idea how could I fix it on my own.
The AudioBlock class now differentiates between const and non-const data.
Possible Issues
The return type of the getInputBlock() method of the ProcessContextReplacing
and ProcessContextNonReplacing classes has changed from AudioBlock to
AudioBlock.
Workaround
For ProcessContextReplacing you should use getOutputBlock() instead of
getInputBlock(). For ProcessContextNonReplacing attempting to modify the input
block is very likely an error.
Rationale
This change makes the intent of the code much clearer and means that we can
remove some const_cast operations.
Actually, that does look like a mistake - copyTo should take a templated destination type rather than the same sample type as the object itself - thanks, we’ll sort that out!
So the question is: “How to pass input buffer to custom method, so we can modify it?”. Not just about copyTo. Am I right?
As far as I understand copyTo was fixed by adding std::remove_const<NumericType>::type> to the declaration.
Unfortunately I am “out of JUCE” right now and I do not have enough time to check it. But it looks like a good question. I will try to play a bit with this. Maybe there are some JUCE processors using inputBlock?
Oh, it is JUCE Oversampling processor.
And there is nothing hard in passing inputBuffer to custom methods. It has simple definition void processSamplesUp (const AudioBlock<const SampleType>& inputBlock) and input block is just read only.
We’ve spent a few days upgrading projects to VS2019, Xcode 10 (from 2015 and Xcode 9) and from JUCE 4 in some cases to JUCE 5.4.x. So we’ve hit a few painful moments
However quite frankly I long for the glory days of ScopedPointer. unique_ptr is ugly, better maybe, but ugly and painful to change!