I’m surprised no one has brought this up yet, as noted in the latest Juce ADC email:
I noticed this too… Shame it’s not an introduction seminar, I’d have been well up for it…
@fabian Looking over the (massive amount!) of DSP code:
Bias::reset appears to be left unintentionally empty.
Also, I don’t think this code would compile in VS2013: I see usage of
constexpr and some other small things that should trip that compiler up.
Thanks we’ll fix that.
The DSP module is not compatible with VS2013. The dsp module has the following in the module description header:
and the Projucer should warn you if you try to use an exporter which doesn’t support this standard (you’ll need to re-compile the Projucer).
Are we about to see a million EQ and FX plugins appear on the plugin market
in about 3 months? Lol
Wooohoo finally, I’m so happy about this, and I hope you will like the new classes I have worked on with the JUCE team
I’m not sure tons of new EQ plug-ins are going to be released just thanks to the the DSP module, but filtering in JUCE is now more efficient and easier that it has ever been that’s for sure
Just had a quick overview. Some great features arriving here just a few days before I wanted to implement an fftw wrapper as well as a convolution engine - this will speed up development a lot
Just one very small thing I found: The comment in line 53 of juce_Windowing.h - I don’t understand it. Probably this is just a copy & paste error from the comment in line 57 and should more likely be something like
/** Fills the content of the instance's internal array with a given windowing method table */
I found some calls to alloca(), it would be better to use a std::unique_ptr<type>, we are in C++, not C (Ivan> nice job, I will keep my rant there, contrary to my promise :p)
Thanks for the DSP module. And congrats on another release!
I have a question about the Convolution Engine - there currently is no non-uniformly partitioned convolution in the module, is there? Thanks.
alloca allocate on the stack even if the size is not known at compile time.
You don’t want heap allocation in the realtime thread
Hello tsenkov !
Good question. The convolution engine is uniform partitioned because last time I checked, some patents on not uniform ones were still in action. I asked a few guys on DSP forums and newsletters, and nobody was able to tell me it is possible to release an algorithm without having potential problems
Moreover, using a thread for synchronized processing isn’t something easy to do (for the long size partitioned convolutions) since the DAWs can mess up with a lot of things, and I’m not an expert in this area. I see all the time commercial plug-ins such as u-he ones with optional but not default multi-core switches, so it looks like complicated and not functional all the time even for experts.
I might be wrong on all of this, but here are the reasons why the partitioning is uniform I might have a look again in not uniform algorithms at some point in the future.
In that case, it should allocated before, you don’t want that kind of object on the stack either (and it’s not available on all platforms).
Is the convolution engine fast enough for reverbs with impulses of a few seconds?
If not, we should use IPP?
The issue with multicore you mention is only related to the parallel voice processing where you need all rendering to be done for each audio callback.i.e very small latency.
This is less true for the non uniform partitioned convolution where you got “more time” to process.
But you are still screwing up the DAW thread pool. multithreading in plugins is for the moment something that should be forbidden as long as we don’t have VST4/AUv4 with a thread pool API.
It can use IPP.
Make no sense to pre allocated it if it’s only transitional data of a couple of bytes like an array of float pointers or stuff like that.
If the threads operate at a lower priority than the audio / synthesis threads, there is no issue. A “big” plugin like BFD can spawn dozens of background worker threads.