Trying to create an audio plugin for mac that is the equivalent to FL Studio’s Fruity Parametric EQ 2. would be for personal use only
I wrote something quite similar, since it’s for personal use, just grab it:
Note, the download packages are outdated, if you want the analyser part as well, build the source yourself (I’m about updating the packages, but setting up a Jenkins took longer than expected)
i’m looking for the simplicity of the PEQ2 UI, and the colored bars signifying the frequencies,
basically almost a carbon copy maybe with different colors
Have a look here:
You could return an image instead of a graph and modulate the colours from the magnitudes taken from
averager… just a thought
But sorry, I didn’t want to hog your thread
Yesterday, I tried to run it but it didn’t work (using the latest JUCE 5.4.1 build in Visual Studio). To make it compile, I had to change the deprecated createParameter calls (and remove addParameterGroup) for createAndAddParameter instead (I can’t use the new constructor initialization because of the EQ band loop). However, when I run it, it crashes in FrequalizerAudioProcessorEditor::paint, see this stacktrace:
It crashes because inputAnalyser and outputAnalyser in FrequalizerProcessor.cpp have no channels yet. In fact, the channels are only initialized when calling setupAnalyser in FrequalizerAudioProcessor::prepareToPlay. However, it seems like the paint method is called before this happens, and the paint method doesn’t seem to be called multiple times. To fix it, I preset the size of the averager in the constructor of Analyser. This time it launches, but I cannot see any EQ curve (only the handles). Also, when I try to set the input / output in the plugin, it crashes every time (last assert of AudioProcessor::setPlayConfigDetails). How can I make your EQ work? Thanks.
Thanks for the report, that’s much appreciated!
I knew I will have to update for the new AudioParameter API, so now I know, it will be a little bigger task. I hope I find the time in the evening, I’ll let you know here (sorry OP…)
Much appreciated sir!
I just pushed an update to github, so it uses the new parameter classes. I also added a safety measure for the case if paint is called, before the dsp is setup. However, I couldn’t notice any problems on OSX/Logic…
Can you please check with the new update? And report back in an github issue ideally, so we don’t spam the board here…
No problem, I will do this as soon as I can (this weekend). Thanks a lot!
I just cloned the code to my linux and OSX. But strangely, the OSX is working well, and linux is running slowly. Is it the problems at buffer? Thank you.
BTW in linux, I use makefile, and in OSX, I use Xcode.
Thanks for checking it out. I didn’t test on linux yet, so I’m glad that it works at all
But what I realise here on OSX as well, that in Logic it runs pretty smooth (even the debug version), but in my own host the analysers are stuck. So that might be related to juce hosting? (I mean that I might have to do something different to make it run in juce based hosts…)
I will have to investigate.
What host did you test on Linux? The JUCE AudioPluginHost or Tracktion or something else?
EDIT: it was the bool flag in the analyser, that wasn’t wrapped in atomic (I assumed it wasn’t necessary with bool, but I learned something now)
So this should be fixed now. Let me know, if that solves your issue…
any way to completely replicate the ui of PEQ 2 ?
Thanks for your reply.
Actually I tested on “raspberry pi and its audio card” and directly used the .exe which made from Makefile. I don’t catch your meaning of bool flag(newDataAvailable), speak more clearly, please.
In the beginning, I supposed the problems were that it’s too much operations in the buffer since operations use lots of resources. I still have no idea what to do to refine the code. I would appreciate it if you have more advices for me.
Thanks a lot.
No problem, I fixed this in the github repository, so if you pull the latest version, you don’t have to change anything yourself.
This is the fix:
Rationale: the bool flag is set by the analysing thread and read by the gui, so there is the chance of a race condition. My naive (wrong) thinking was, there is no way, that setting a single bit would not be atomic, but it had an effect, so the problem I could reproduce went away by adding the std::atomic wrapper around the bool flag.
Let me know, if that works now in the rPI… I haven’t run my own software on that device yet, but I am curious…
It’s a bit better now! But it’s still not pretty smooth. May it be the problem between VST3 and .exe file? Or Is there other ways to optimize code? Thank you. You are such a patient person!
That’s very kind of you.
Unfortunately I have no specific idea, what to change. When I find anything, I will add it in the repository.
That’s definitely possible, however:
- what is the purpose to replicate an existing plugin? Why not using the existing instead?
- if you plan to distribute that clone, I don’t know if there is a design patent or any other protection in place. In any case it is not nice to do that…
- if you want to learn, how to do it, just take the code and get your hands dirty. If you get stuck, just ask…
- if you want me to code that, PM me and I can give you a quote, but it won’t be cheap, since that takes some time…