From the original SynthMaker forum (2004–2014), with its members’ names and dates.
tester ·
I'm not sure how to specify so I try this way. How much CPU (at 2GHz core 2 duo or in some other comparison) will eat synthmaker made standalone (denormals unoptimized) application, made let say of 300 parametric (sine or similar) oscillators? Some of them serve as a tone generator, most of them as modulators. Im curious how much rather basic sonic ideas (smart gui) I can put inside SM and still get live effects.
Dell ·
Hi.
There are a few options to test CPU consumption in your design.
1. In Synthmaker. Insert the ASIO Out or Direct Out module that enables you to listen to your design while testing. The CPU percentage will tell you how much your design is consuming.
2. Your DAW. Load your design in your DAW and, play it. If your DAW does not offer a CPU Meter, download REAPER and use the CPU meter as a means of reference.
3. For Standalone (exe) devices you can use Task Manager in addition to option one.
De-Norma-ling may not be needed if your design is for personal use in which, your computer’s processing chip does not encounter such issues. Some current Intel processors still offer remnants of the Pentium 4 so you will need to check if your processor falls into that category through real-world testing using your design.
If you are planning to offer your design to the public it would be wiser to just leave it in.
Bear in mind using large amounts of De-Zipper & De-Normal modules will elevate your CPU consumption in addition to raising the noise floor of your design.
Having the option to turn things ON (Off be default) will reduce the CPU consumption. Synthmaker’s signal path goes from Right (out) to Left (in) not Left (in) to Right (out). If you choose to add additional switch modules to turn off components (to reduce CPU consumption) make sure you add the modules from Right to Left and not Left to Right.
Cheers!
trogluddite ·
In addition to Dell's great tips - here's a few other points to watch out for...
1) SM's internal meter is a little weird. SM always runs on only one CPU core, even if your CPU has more available. The CPU usage shown is only for that one core. So for example, on a dual core system, the built in meter will show a % figure that is double what an external measurement will show.
It also does not show any CPU usage due to green or GUI components - so will read too low if, for example, you have animated graphics on screen, or use lots of 'green' calculations triggered by tickers etc.
2) I guess a design like you are suggesting is going to be very 'modular' - so build it up in stages, checking the CPU as you go along. You can then 'multiply up' the CPU from a smaller design to get an idea what adding more will do.
However...
3) The CPU usage will not necessarily go up in direct proportion. The biggest reason for this is the CPU cache.
When e.g. waves/variables are read from memory, a big chunk of RAM is read at once and put into the cache - from where it can be read by the CPU much, much faster. As you add more oscillators etc. the cache will fill up faster, forcing the CPU to read the main memory more often, costing a lot of CPU cycles. So it really pays to keep memory usage as low as possible by, for example, sharing a single wavetable rather than having one per oscillator (the standard toolbox oscillators do this already IIRC).
4) It is worth making a start on learning a little code and/or assembly if you want to optimise a big design. Stringing together lots of small 'DSP' primitives carries some 'baggage' - i.e. for reading/writing the values carried by links. So you can make some savings by condensing those into a single line of code inside a code primitive etc.
5) In FX sections (i.e. blue mono), mono4 is your friend - you can think of it as a form of parallel processing that gets 4 times as much done for the same amount of CPU.
As for predicting the kind of CPU usage you will get - this is very hard to do with any accuracy. As well as CPU clock speed, it also depends on the CPU 'architecture' - i.e. such things as the size of the CPU caches, the length of the instruction pipeline, motherbpard bus speeds, and many more.
I would strongly recommend Dell's suggestion of trying out Reaper - it allows FX CPU to be measured 'per track', so will let you get some good 'real world' CPU figures that are not distorted by the CPU load of your ASIO driver etc. The demo is fully functional (except for a pop-up box) - and is not time limited. Of course, if you end up using it for music production, then you should do the honest things and pay for the (cheap) single user licence.
tester ·
Thanks for advices. When everyting clarifies in my head - I post some more data. Right now, while learning SM - I'm focusing on single/simple but practical solutions that can be used in multiple ways and combinations.
Wrote something here? To have a post removed or your name hidden, write to [email protected].