macos 10.13.6
I don’t know this “BSD” based OS…
But I will make test on Win10
1 Like
1 Like
Hm that’s weird, since in my project, only 2 of 4 cores are utilized. Are you using plugins with explicit multicore support, e.g. uhe plugins?
For the idle test, did you double click the stop button to flush all the audio buffers first? It should show more then a constant load, not jumping anymore.
I will make some tests myself this evening.
The point is, for the concept “bus processing”, you can’t put that on individual tracks, e.g. limiter, it’s about processing the summed signal.
The “Heavy FX” is “analog obsession Dynasaur”
Multitheading is not mentionned Here :
But monitoring cores use,and using only one instance of this VST,I can say it’s a multithreaded VST
From my point of view,“Internal routing process” doesn’t really impact performance
Realtime sample processing and VST(I)s have the biggest impact
Renoise “smartly” distibute threads.Routing has no impact on this distribution.
I have a silly question
Have you enabled all the cores in preferences?
yes, all 8
Maybe you can changes some parameters
The multi-CPU processing in Renoise has two modes internally:
One, where all signal paths are followed up to their end and processed asynchronously - including the send tracks which end up in the master track or some dedicated hardware outputs.
And the other one, where processing is done in two passes: first everything without the send tracks is processed asynchronously, then the send tracks are processed asynchronously.
The second mode is automatically selected when there are too many send connections. So using does not always degrade multi CPU performance.
2 Likes
Maybe some “hungry” monothreaded plugins can cause problem?
Thanks. I will make some tests with that song project once I have time again, and posts results here.
Hi again,
so here I have another project which makes me wonder why the cpu is not nicely used, but instead the Activity monitor shows a 180-220% of 400% at maximum, while the song already starts to stutter at 8ms / 44,1kHz. I have the impression that this did not happen in older Renoise versions, but I cannot load the project into the old version anymore for a comparison, so I cannot prove that.
The song has two summing sends, bass+drums and the remaining instruments. Before those two sends, there are “ducking” summing sends, to which an amount of individual tracks is sent. These ducking sends route then into the final two ones above. Sadly almost the whole song, the output stutters.
I guess due the lots of send tracks, the second mode is then used?
Could it be a problem that sends route into other sends, performance wise?
Lots of Zebra 2 instances (one single 32 bit fx plugin):
Still the activitity monitor only shows:
After deleting those two summing sends, the stuttering almost goes away, but still the usage cpu meters are weird, far away from 100% / 400%:
Activitity monitor shows:
So what still puzzles me:
- Why I can’t remember those stutterings in older Renoise versions? Am I old already?
- How can I practically change the project, so it uses most of the cpu? (Maybe using sidechain + that melda plugin?)
- Could this be cpu spikes / denormal numbers related?
- Is there a way to determine cpu spikes with Renoise?
My hardware did not change since years, I also did not flash any bioses (I don’t want any intel cpu degradation/security patches). Also I still use macos 10.13.6… I don’t have any of such problems in Bitwig, even with a “shitload” of plugins at 8ms. Please, any idea?
1 Like
Have you tried the same routing with others VSTI?
Good morning, no, not yet. I think then latency would be not accurate / daw controlled anymore.
I found one plugin which mainly caused stuttering: Ozone 8 spectral thing. But still, the usage only is at ~220% only, so like a quarter of the cpu is unused. Might be cpu spikes, but I cannot visualize those. Bitwig has a very good, very precise cpu meter graph, which does not help here.
It’s really weird. Now the audio stutters when I am scrolling the pattern view horizontally. I would assume that the GUI engine is causing cpu spikes somehow. Hence the immense headroom.
Have you try some changes on audio driver settings or audio output settings?
Have you try with another souncard?
Damn, I found one problem that was causing the unusual cpu performance drop over time: My cpu cooler did not spin anymore 
Quite remarkable performance for a computer without cooling!
Still, only 220%/400% of cpu is utilized in the activity monitor. I was looking for a system cpu meter which actually has such an high resolution that you can see cpu spikes, but could not find any for macos…
I am very missing that cpu usage live table view from Buzz tracker in Renoise… It also showed denormal spikes (I think the cpu then switches to a very slow, super accurate mode for some time, denormal number == way too small floating point values), I really wonder why no other DAW has this, because it seems to be still very relevant. Can’t be that difficult to implement either.
2 Likes
Yes, luckily CPUs since have an overheating protection these days and simply seem to drastically clock down or even halt, so it might be impossible to overheat it.
1 Like
Hi, is this still valid?
I am using a M1 pro and macos 12, I now have quite a lot performance degradation. The activity monitor shows Renoise with 130% usage (130 of 1000% or so), and the song already starts to stutter.
Is this maybe related to fix you did here? I have the impression that Renoise now performs quite worse. Before I hadn’t a single project anymore with didn’t run at 8ms…
Would the processing be more efficient, if I only used groups? I usually route bass + drums together, and either all the instruments or 2-3 groups of instruments.
Do you have any tips which routing would result in the most efficient processing? What happens, if I “misuse” the sidechain as routing device for send tracks next to a group?
Thanks for help!
Ok, I (hopefully) think that I found the cause for the bad performance: One more recent plugin hadn’t neither multiprocessing nor “disable on stop” enabled. This plugins sits on various tracks and also some mixdown busses. I now enabled multicore support for it, restarted renoise, and the project is again playable at 4ms latency 
Is this an intended/expected behaviour, or maybe a bug?