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…