AudioBlock::copyTo issue after upgrade to 5.4.4

#1

Hello,

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:

Error	C2664	'const juce::dsp::AudioBlock<const float> &juce::dsp::AudioBlock<const float>::copyTo(juce::AudioBuffer<const float> &,size_t,size_t,size_t) const': cannot convert argument 1 from 'juce::AudioBuffer<float>' to 'juce::AudioBuffer<const float> &'	AudioBlockCopyToIssue_SharedCode	c:\users\mateusz\workspace\small_projects\audioblockcopytoissue\source\pluginprocessor.cpp	138

I have prepared an example project: https://gitlab.com/mateusz.salski/audioblockcopytoissue/
There are exporters for Visual Studio and XCode.

The problem is illustrated in method:

void AudioBlockCopyToIssueAudioProcessor::processBlock (AudioBuffer<float>& buffer, MidiBuffer& /*midiMessages*/)
{
    ScopedNoDenormals noDenormals;

	juce::dsp::AudioBlock<float> block{ buffer };
	juce::dsp::ProcessContextReplacing<float> context{ block };
    
	auto& inBlock = context.getInputBlock();
	inBlock.copyTo(tempBuffer); // <---- Compile error
}

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.

#2

Change

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.

#3

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!

#4

Thank you @MBO and @jules.
I will track dev branch for fix and use above workaround if necessary.

#5

Thanks - yes, this has raised a few issues, we’re going to review that class to try to give it more obvious behaviour!

#6
#7

The fix works great. Thank you. :slight_smile:

#8

This doesn’t compile with JUCE 5.4.5. It used to:

ScopedPointer<dsp::Oversampling<float>> oversampler{nullptr};

void GranularPitchShifter::process(const dsp::ProcessContextReplacing<float>& context)
{
    auto inputBlock = context.getInputBlock();
    auto workingBlock = oversampler->processSamplesUp(inputBlock);

Some kind of const issue with <const float> vs <float>.

What are we doing wrong?

#9

Hi,

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?

Could you also past error message?

Regards,
Mateusz

#10

It was an oversight on our behalf, but fixed now:

1 Like
#11

Oh, it is JUCE Oversampling processor. :stuck_out_tongue:
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.

#12

Well it’s fixed now :slight_smile:

Looked like a bug!

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 :slight_smile:

However quite frankly I long for the glory days of ScopedPointer. unique_ptr is ugly, better maybe, but ugly and painful to change!

2 Likes