ffaudio / ff_meters Goto Github PK

The pragma does not compile on MSVC:

#if FF_AUDIO_ALLOW_ALLOCATIONS_IN_MEASURE_BLOCK
#warning The use of levels.resize() is not realtime safe. Please call resize from the message thread and set this config setting to 0 via Projucer.
            levels.resize (size_t (numChannels));
#endif

The function std::sqrtf is not available by default in GCC, it requires you to add the -lm flag to the compiler which may damage portability.

Can be found in file ff_meters_LevelMeterSource.h:105 (LevelMeterSource::ChannelData::getAvgRMS())

Edit: Removing std seems to fix the problem

Thank you for ff_meters! I am using it in a multichannel plugin. On Windows 10/11, performance is top notch.

But on the Mac OS Monterey 12.5 and Juce 6.16, I seem to be getting excessive CPU utilization.

On Windows10/11 with the plugin loaded in AudioPluginHost and with the UI showing with the meters, I am getting approximately 4% CPU utilization. On MacOS under the same scenario, I am getting 40% CPU utilization.

I tried JUCE_COREGRAPHICS_DRAW_ASYNC=1 and that saved a few percent CPU cycles.

If I comment out meterSource.resize (juce::jmax(2, getTotalNumInputChannels()), 0.01 * sampleRate / 512); in prepareToPlay and comment out meterSource.measureBlock (buffer); in procesBlock then the CPU drops to 18% with the UI open.
The meters appear to add ~20% CPU utilization on the Mac.

Maybe I am doing something wrong?

I have been trying for 2 days, but I have not been able to change the color of the border (currently white) around the meter control (or each individual channel of the meter control). I have tried setting "foleys::LevelMeter::lmOutlineColour", but that has had no effect. How do I change the meter border color (from white)???

Also please note, the control does not really display until your sent audio data through it, it would be VERY helpful to have some sort of "test" function call within the meter class to display it (at a given meter level) so that I can see what the meter looks like while I'm trying to do the layout (and tweaking) of the UI.

In addition, it would also be great if there was some sort of #define that would set whether the meter control is derived from "LookAndFeel_V3" or "LookAndFeel_V4".

Hi,

Thanks for sharing your work!

It seems it is not possible to have both FFAU::LevelMeter::SingleChannel and FFAU::LevelMeter::Minimal flags enabled?

I like the interface, however it seems not trivial in the current implementation to enable both.
And actually I don't need the ticks as well :). I was just looking for some (very small) indication of sound coming in/out (for 10+ channels) and possibly the clipping indicator.

I get errors on the following header files when I try to build ff_meters using the latest version of the Juce library:

#include <juce_audio_basics/juce_audio_basics.h>
#include <juce_gui_basics/juce_gui_basics.h>
#include <juce_events/juce_events.h>

The ff_meters_LevelMeter.cpp seems to depend on JuceHeader which makes compilation fail in any non JuceHeader based environment.

The title might be a bit misleading because this only happens if one does not resize() the level meter sources in prepareToPlay(), however I thought it might be good to add this to the readme.

To reproduce, open a plugin with level meters in the juce plugin host, save the filter graph (ctrl+s) while the plugin is open, then restart the plugin host.

The exception is an out of range exception which occurs in LevelMeterSources.h in getMaxLevel():

float getMaxLevel (const int channel) const
{
    return levels.at (size_t (channel)).max;
}

The obvious fix is to call resize() on the level meter sources before processing audio. I didn't do that because I followed the tutorial and it wasn't done there.

After some effort, I got this control/component to build as part of my application (though I still get warnings).

Everything looks good, and I did my best to follow the code example below, however... I do NOT get any activity on the meters.

Is there something that needs to be initialized, other than what is shown in the code example below?

Is there some example application that uses this that I can download/build?

Hi again about multi threading

ChannelData also raises a bit suspicion. The rmsHistory should really be a vector of atomics, getAvgRMS (from UI thread) clashes with pushRMS (from AudioThread). You did it right with the rmsSum field.

Then there is also a race condition inside pushNextRMS because it might be called by the UI thread by decayIfNeeded. I would highly suggest removing that from LevelMeterSource and by that use a const reference to the LevelMeterSource in LevelMeter. You could do the time check inside the LevelMeter class and just "render zeros" no matter whats inside the LevelMeterSource.
If thats not possible, I would make rmsPtr atomic too and use "fetch_add" in pushNextRMS to read and increment the ptr in one atomic action. You'd calculate the module operation every time so the ptr just increases until the max value of size_t and then overflow to start over at zero (perfectly acceptable behaviour).

I get the following errors with the latest version of ff_meters. I have tried a few things, but can't get them to go away.

1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.26.28801\include\numeric(35,26): warning C4244: '=': conversion from 'double' to '_Ty', possible loss of data
1> with
1> [
1> _Ty=float
1> ] (compiling source file ....\Source\MonitorCls.cpp)
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.26.28801\include\numeric(44): message : see reference to function template instantiation '_Ty std::accumulate<_InIt,_Ty,std::plus>(const _InIt,const _InIt,_Ty,_Fn)' being compiled
1> with
1> [
1> _Ty=float,
1> _InIt=std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types>>,
1> _Fn=std::plus
1> ] (compiling source file ....\Source\MonitorCls.cpp)
1>D:\Dev\X-platform\Juce-Modules\ff_meters\LevelMeter\LevelMeterSource.h(102): message : see reference to function template instantiation '_Ty std::accumulate<std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types>>,float>(const _InIt,const _InIt,_Ty)' being compiled
1> with
1> [
1> _Ty=float,
1> _InIt=std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types>>
1> ] (compiling source file ....\Source\MonitorCls.cpp)
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.26.28801\include\numeric(35,26): warning C4244: '=': conversion from 'double' to '_Ty', possible loss of data
1> with
1> [
1> _Ty=float
1> ] (compiling source file ....\Source\MainOutputCls.cpp)
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.26.28801\include\numeric(44): message : see reference to function template instantiation '_Ty std::accumulate<_InIt,_Ty,std::plus>(const _InIt,const _InIt,_Ty,_Fn)' being compiled
1> with
1> [
1> _Ty=float,
1> _InIt=std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types>>,
1> _Fn=std::plus
1> ] (compiling source file ....\Source\MainOutputCls.cpp)
1>D:\Dev\X-platform\Juce-Modules\ff_meters\LevelMeter\LevelMeterSource.h(102): message : see reference to function template instantiation '_Ty std::accumulate<std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types>>,float>(const _InIt,const _InIt,_Ty)' being compiled
1> with
1> [
1> _Ty=float,
1> _InIt=std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types>>
1> ] (compiling source file ....\Source\MainOutputCls.cpp)

NOTE: There are also several places where "unreachable code" is defined, and those cause warnings as well, but I just commented out the code that caused it.

I think the bool suspended in LevelMeterSource would make a great use of an atomic boolean. This way (and I think it is intended that way?) the UI would be able to suspend a meter source since it nows when it is not showing the level meter. The audio thread doesn't even have to call measureBlock if it wants to suspend the level meter.

Let me know what you think / if I should create a pull request.

After doing my first implementation with the OutlineBuffer (based on the documentation in the Readme), I am running into the issue where there is a center deviation between the 2 halfs of the waveform, and the bottom half seems to behave weirdly.
Demonstration video: https://youtu.be/_qVR8wtTCcM
Is this expected behavior and if so, how could this be solved?

Thanks