There certainly are a few performance issues on my old mac, but yeah, let’s see how it goes in your redesign.
Terrible performance
Sorry to open an old topic but I’m interested about the results ! @kilon Any news ? As you linked above, I’m running through the same issue with ToneZ (that was the big project I talked about in my thread).
I got many many complains about how ToneZ is CPU hungry… I can see this myself too when I layer many instances and play 4 notes chords
I’ll try to play a csound only version of the example I gave, to see if this is a csound issue or cabbage issue (pretty sure it’s csound, but still, let’s try & see)
EDIT : Tested in Cabbage, LMMS (VST), Csound (native from CMD)
=> Same result : roughly 14% CPU used when I play 20 notes in my example
So it seems to be a on Csound side
I wonder if there might not be an less CPU hungry way to generate those band-limited waveforms. In his book on Computer Music Instruments Victor outlines several ways of generating band-limited waveforms using various summation formulae. He shows a generalized formula as follows:
I think this might be faster than the FFT mechanisms employed by vco2
, but I’m not DSP expert. He also gives a example in python of this might be implemented.
Perhaps it’s worth investigating?
You might also want to take a look at some code Jeannette C posted to the Csound list a while back. It generates band limited waves by limiting the number of upper harmonics depending on the current note. You can grab the code here.
Hi @Retornz. I did some more reading and I don’t think these formulae will work for sawtooth waveforms. But I did come across an article where Victor outlines how waveshaping can be used for cheap generation of sawtooth waveforms.
Try the following .csd
saw.csd (1.2 KB)
This is basically Victor’s code. It’s not quite the same as vco2 sonically, but I expect it wins hands down when it comes to performance. And if you’re super-sawing things, it might just be Ok? Please let us know if it works.
Thanks for all the research Rory !
- The 2 first solution (Formula + band limited waves) : it’s really interesting, not quite useful for sawtooth waveforms, but still, it’s great stuff, thanks for sharing !
- For the Waveshaping : I tried it and I ended up with this kind of saw-ish shape, doesn’t sound that much of a saw IMO (more like a distorded sine), at least not the kind of saw I expect & like
- Finaly, the last one is very interesting :
It’s definetly a saw (reversed saw compared to the VCO2 one)
here is VCO2 saw :
We can already notice the saw is quite rounded on the ends (doesn’t have the small peaks at the ends) so we can expect it to sound softer, like if it was low pass filtered
The Spectrum Analyser confirms, we can definetly see a rolloff at the high end of the spectrum (like a filtered saw)
Here is VCO2 saw :
So now the CPU test, playing 100 notes at the same time :
- Test Saw : 6% CPU
- VCO2 : 7.5% CPU
So yeah, the Test saw is more CPU friendly !
So, even if this saw is quite interesting & cleverly made, I think it can’t replace the VCO2 saw. Even if we save like 1.5% CPU during the test, the same test with Sylenth or Spire shows like 1% CPU usage so we are still way too high !
What is quite interesting to notice is that using OSCIL, so the most simple SINE opcode, we are still around 6-8% CPU usage for 100 notes played… So that means there is something inside Csound that takes up lots of CPU.
An interesting test would be to try to make a really simple SINE synth like the example synth in JUCE, and do the same 100 notes test, to see if we are closer to Csound or to the comercial synth.
Interesting results. I just tried here and I see more or less the same thing. The more instances you have of an instrument, the more CPU seems to be used. On the other hand, if you could generate each of the source in a single instrument, the CPU usage is halved…
I should check what what happens when one uses a recursive UDO…
Here is some code Steven Yi shared with me a while back. I added a vco2 to it and changed the number of partials to 100. It runs with only about 1% CPU when it is playing full harmonics.
K-Recursion.csd (1.2 KB)
Check out this one. It’s a supersaw type of recursive UDO I wrote for @ThesePenguins in response to a question on the forum. I can run this to 100 voices and I see very little CPU usage at all.
SuperSaw2.csd (1010 Bytes)
I tried again with 1000 vco2
's. I get to about 10% CPU. I guess the bottleneck you’re experiencing comes from using multiple instances of you synth.
Thanks ! I tried the 2 codes you posted above, and only 1% CPU !
So using a rercursive opcode seems to make a huge difference !
Actually, I think it might also incur a slight CPU gain, but it’s much easier than writing 100 of lines of the same code!
And also perhaps running multiple instances of your Csound instrument within a single orchestra…