So I believe this works the same as the first one and it is easier to use. But I found the first method “findMinMax” sometimes returns the magnitude = 0 even the buffer has non-zero values. I haven’t tested if it is a findMinMax() bug or getLength() bug, or maybe I did something wrong with my code.
I use MacOS Catalina 10.15.5 and Xcode 11.6. I tested this in Fl Studio.
Whilst it’s certainly possible that findMinMax has a bug, the internals of it haven’t changed for a very long time and we haven’t had any other big reports.
Would it be possible to get the contents of a buffer where it’s not doing what you expect it to?
Could it be that the isClear flag is set for those buffers? From another thread, doing something like the following (getting the write pointer before calling clear()), causes the isClear flag to remain set, even after changing data in the buffer:
auto buf = buffer.getWritePointer (0);
buffer.clear();
buf[0] = 1.f;
When that flag is set, findMinMax will return the range 0…0.
Would it be possible to narrow it down a little further? When sampleMaxType is zero could you print the number of channels in the butter, the number of samples in each channel, and the value of all the samples in each channel?
Ideally we would have a case where we could feed a single, prefilled, buffer to findMinMax and see it produce a zero.
Also you can paste code and output snippets into this forum if you surround the snippets with three backticks and it’ll be formatted nicely, so you don’t need to screenshot. This makes it searchable if anyone else if having the same problem.
But I found the first method “findMinMax” sometimes returns the magnitude = 0 even the buffer has non-zero values.
The code referenced (his first example, using findMinMax) gets the range from findMinMax, which would be 0…0 if isClear is set. This would cause his call to get the magnitude to return 0. How can that not be relevant? It’s exactly what he said was happening!
Nevertheless the more likely explanation that I pointed out is, that in the OP’s formula a buffer with a DC signal would yield 0, while the juce implementation will yield the value of the DC offset. Especially for buffers of the length for 1 sample, this will always return 0.
Reason for that is a wrong definition of magnitude. (I wonder which one is the correct?)
As Daniel has pointed out the definition of “magnitude” as determined by the algorithm in the original post is not the same as the one returned by getMagnitude from the JUCE AudioBuffer. JUCE returns the “highest absolute sample value”. The original post returns half of the range between the highest and lowest sample values.
Take the last two values printed in the example buffer values after start=====. They are both -0.197144, the range of these is 0, divided by 2 is still 0, whereas getMagnitude will return 0.197144. Maybe this is the result of buffers with very few values? (DAWs sometimes do this to improve automation accuracy) although @HowardAntares makes a good point too however it’s not clear from the examples why this would only happen occasionally.
As a side note the original post calls buffer.findMinMax for the entire buffer, for every sample? the sample variable is actually unused in the example (unless I’m missing something?).
No, the loop is over the number of channels, not over every sample. We don’t see the rest of the code for actually processing the samples in the post.
But yeah, if the buffer is short enough, that code will just grab a few adjacent values, whose range is not likely to cover the whole range of the audio over a larger time span, and could indeed lead to 0 as the range.
This is the code from the original post, it loops over the channels then inside that it loops over the samples but never does anything with the samples but instead calls findMinMax on the entire buffer (for each sample). It doesn’t really change anything in terms of outcome it just means the calculation is being performed for every sample when it only needs to be performed once.
So from that output I think findMinMax returns the correct output. However, there are two kinds of output from that result. -0.710976 and 0.315113 are the correct values for min and max. But in another situation, the loop only has around 20 values for both left and right channels, not 512. And it returns 0.233697 and 0.309581. I don’t know why @t0m
Yes, exactly! I posted the test result just now and found that sometimes the buffer doesn’t have 512 samples, only around 20 samples. Does every DAW do this? I tested this in fl studio, what about Ableton Live? @anthony-nicholls
That’s to be expected. DAWs are free to pass fewer samples than the maximum that you specified. They can even pass 0 samples (for example, to simply send parameter changes but not audio);
Off the top of my head I don’t know what DAWs do and don’t do this, however you’ll have to deal with it either way.
If you want to make sure you always have at least n samples then you’ll need to make a buffer. Set the size of the buffer in prepareToPlay() and create an int to keep track of the number of samples you have added to the buffer, once you have filled the buffer perform the calculation on the buffer and set the number of processed samples back to 0 and repeat.
