You can get Renoise to peak at least one (virtual) core?
I know this sounds spoiled and greedy, it prolly is, but still… just about everything else that calculates something as fast as it can (and lasts more than a moment) seems to peak easily, yet Renoise never does (obviously talking about rendering here).
Oh yeah. Didn’t occur to me that Renoise might not support multi-core rendering.
Dunno if that’s the case, or if so, why. Not really all that familiar with parallel processing and all of it’s quirks.
To render a bottleneck:
+1
I would like to see this added as a feature to Renoise.
most likely rendering supports multicore, as it is “nothing more” than redirecting the audio to a WAV writer driver. It should never be slower than normal audio rendering, but it’s not said that it must be way faster: if your CPU is already peaked when playing the song, there will not be much difference.
I guess that using multiple cores so efficiently that the whole CPU peaks is next to impossible, I’m really not that greedy 
No, most songs use 10-20% when playing. When I render, one (virtual) core gets to at most 2/3rds usage - yet when extracting a big archive, running a simple benchmark and such things, one (virtual) core usually peaks. Hence my talk of a “bottleneck”.
Hey, wait a second… maybe it’s the GUI updates? Maybe there could be a checkbox to turn them off?
try if minimizing the application makes things faster (this will avoid GUI updates). also try to disable pattern following.
The highest as in the fastest or realtime results?
Realtime rendering takes care that all plugins can be processed safely as well, this does not mean that Renoise will process this faster than the song-tempo goes as you told Renoise that in some way most of your plugins cannot handle the fast rendering speed Renoise can process song rendering.
Actually i would expect with realtime rendering that CPU usages would go down instead of up since the processing burden is being divided across more cores and this will result in less load.
If you go for the fastest results, you risk that those plugins that indeed cannot keep up the pace will cause hickups, spikes or other type of glitches that spoils your end-result.
But the fastest rendering priority will usually be the quickest, if you want to compare multi-core vs one core results, then set Renoise to the fastest rendering mode and clock the result on a stopwatch, repeat this process using only one core inside Renoise.
You ain’t got quality output, but you have probably two different time results.
Well, that makes one core that was used totally idle, but the core that seems to do the brunt of the rendering still doesn’t get above 2/3 
(note that when I say I core I mean virtual core, one graph in the task manager) (setting the process priority to real-time doesn’t change anything either)
But please not that I’m not complaining at all; it’s fast, it’s a dream to work with Renoise on this machine… rendering is more than fast enough… but I also noticed that getting the most out of the system really depends on what the software is doing… and maybe there is room to improve?
another issue could be the way in which the sound outputs are set: having n cores does not immediately mean that rendering will go n times faster; a very silly example is that, if you have 4 cores but your song has only 3 tracks, Renoise will divide the audio process only in 3 threads, so a core will not be used anyway.
things are more complex than this, as Renoise does not make a separate thread for each tracks, but it makes a separate thread for each sound output, which basically means that if two tracks share the same send track, they are computed in a single thread. this means that, even if your song has a number of tracks which is higher than the number of cores, still the number of threads can be lower than the number of cores.
ps: sorry if the possible explanations are coming into my mind at little steps, but I’m using the forum in a background brain thread during work 
rendering has always been a mistery to me performance-wise.
my CPU has also never been used to its full potential and none of the four cores gets utilized by 100%.
screen updates do not play a significant role here, because a maximized or minimized renoise does not make any noticeable difference.
would be cool to get taktik comment on this as everything else seems to be vague guessing on what’s going on.
He actually already did when introducing multicore support in 1.9.0:
http://tutorials.renoise.com/UC/ApplicationFaq
Renoise and multi-cpu / multicore HT cpu support, how does it work and when does it work?
Renoise 1.8 and lower cannot handle multicore CPU’s. On PC’s having HT technology, one of both cores is turned off by default. But on Intel based MacOSX, this is not the case yet. If you can somehow set the CPU affinity to make Renoise only use one core, you won’t have to fear crashes. Also, one user reported to be capable of running Renoise fine on a multicore CPU when using an emulated environment (or a virtual pc environment) that only uses one core.
Renoise 1.9 supports now multicore CPUs.
Here is what you can expect from it and what not:
Hyperthreading CPUs are not supported.
They will be treated like single CPUs as our testing results did not show any real performance gains, or even worse: They cause a performance decrease.
Why? HT Cpus are “faked” multicore CPUs. Realtime parallel Audio processing (the way we use the multiple cores) can not really be handled by them.
2 CPUs = 2x performance speedup?
Unfortunately its not that easy. Handling multiple CPUs first costs the engine a bit of performance (you need to take care of the multiple “audio streams”), but this is in overal not very much. The amount of this overhead is visible when enabling/disabling the multicore support in an empty song (not playing back anything). Then Renoise has to split your song into “independent streams” that the CPUs can then handle separately. In complex songs with a lot of send tracks and devices this limits the sharing capabilities a bit, which means that the performance is not very well balanced.
In practice this means that the speedup will be something like 1.2x to 1.6x, (on OS X even up to 1.8x) per CPU, depending on wich song you are running.
Multicore support in VSTs
Some VSTs already provide multicore support (like Kontakt), so Renoise wont be able to process such VSTs faster than before.
Taskmanager shows the same CPU usage as before!
This is not because all we did is faking the Renoise CPU meter, but because the overall application performance does not increase. Let my try to explain why:
Lets say you have 2 CPUs and run a song in Renoise 1.8:
When the CPU meter showed 100 percent in Renoise, Renoise only used 100 percent of !one! CPU. The other CPU idled around then but you could not go beyond the 100 percent in Renoise. Taskmanager would have shown an overal CPU amount of 50 percent then, as your other CPU had nothing to do at all.
If you load this song in Renoise 1.9, the CPU meter in Renoise will show something around 60 percent, Taskmanager will still show 50 percent. The overall performance is still the same, but you now have 40 (100 - 60) percent free for more FX and stuff in Renoise!
I experience big CPU overloads even while nothing is being played
if you have got an AMD dual core system (such AMD FX2), you need to download the dual core optimizer
Sorry, I missed that earler: I meant “highest priority”, not “real time”.
And I know that I can’t expect “N times faster results”. That wasn’t my issue. As keith303 said:
I really don’t mean “full of use of every core”, but full of use of at least one core. Renoise doesn’t even do that when limited to one CPU.
Nope. That doesn’t address the question of “why can’t Renoise fully utilize even just a single core for rendering?” I’m aware of these questions and their answers, they just don’t seem to apply here.
Last time I had enabled really really high rendering priorities, we got reports like this:
http://www.renoise.com/board/index.php?sho…render+priority
So the the high prio mode is not the “highest priority” possible, but a bit more gentle so that you can still use your computer while rendering.
I could try a to add another a bit less compromised prio mode, if that helps…
But if I manually (via task manager) set Renoise’s priority to high, higher, or real-time, wouldn’t that have a similar effect? And that didn’t make any difference for me, Renoise still doesn’t make full use of the CPU that is available to it (as always, I’m speaking about one core).
Would a third priority setting be too much? → “background”, “normal” and “high/aggressive”? I definately wouldn’t want to mess up the Renoise experience for others just because I’d like a track to render in 20 seconds instead of 30, that wouldn’t be worth it… but on my system there really is no reason for Renoise to be gentle or careful either, so if there are any “brakes” that could be removed I’d be all for it.
I don’t think it is the same: in Task Manager you specify the application’s priority, while taktik can specify the priority of the threads created by the application.
btw, this might be interesting for some, it shows the actual CPU usage (ignores waiting cycles)
i don’t think it’s the priority which hinders renoise from rendering any faster. i mean… i’ve been rendering songs ever since there is renoise 1.2x and i never had the impression it was utilizing more CPU resources when rendering in any of the previous versions. maybe it was measurable, but it didn’t really feel like it.
besides that it’s not really like i’m encoding a HD movie in the background whilst rendering an xrns, so apart from the usual windows idle stuff going on, there isn’t that much for the OS to priorize anyway.
a similar feeling arouses in me when i’m loading a .wav or .mp3 file:
according to certain indicators (HDD LED, taskman.) neither the HD nor the CPU is overly “busy” at doing something whilst loading a faily large sample and still it takes a respectively long time to for renoise to load the sample and generate a waveform.
but that’s just on a related note.
that’s exactly what i meant when i said it.
Hey, this is offtopic but before I forget it: it would rock if either
a.) loading samples could be queued
b.) there was an in-your-face indicator (mouse pointer busy thing) to display it’s stll loading the sample
… because when you load another sample while one is still loading, the first loading process just silently aborts To be honest I haven’t checked if it’s still that way in the latest versions, but it used to be that way and that can really suck if you don’t pay attention.
The super high prio mode was temporarily enabled in a beta only. I think it was 2.0. I’ve for now raised the priority again a bit more, but not as much as last time…