Rendering has become ultra slow for me. Offline rendering a song with a single VST (32bit) in it (all the rest native DSPs/Intruments) on prio “high”, takes many times over realtime rendering. I’ve tried switching sound drivers (DX -> ASIO, ASIO -> DX) without any result. The song in realtime uses about 30% CPU time of a single core. Offline rendering on 4 cores (@99,8%) and prio “high” takes 3 minutes, for a song length of 30 seconds.
Not for me. Worked on a Athlon X2 and XP always fast and also on the Quad with Win7, till 2.7.2. 3 minutes of rendering for 30 seconds of audio, that takes only 30% of a single core in realtime imo isn’t just slow. It’s super slowmo. Some bytes less and it’d render backwards.
I’m not agressive at all. I just wonder what’s going on, because in the past things like that were added to the pending bugs. Meanwhile some are added there and some are not. So how is one supposed to know if anyone takes care of things or even recognized them? No reaction at all imo isn’t the appropriate reaction.
Arguru’s Sync rendering is the only part of the code which remained almost untouched since the beginning, being inherited by Renoise’s predecessor. Taktik always said that he had actually little idea of how it worked, so I think there is little he can do if on a specific hardware setup (yours) it behaves even worse than on others’. I understand that in Renoise 2.7.2 it worked reasonably fast for you, but probably some changes in the way the audio engine works has caused this and t woud not be easy for taktik to understand why.
Of course we do understand how the interpolation works, and the interpolation routine has not changed since years so I’ve no idea where this difference in rendering speed may come from.
Bit-Arts: If you have an example song/pattern/sample which rendered relatively fast in previous versions, but is much slower in 2.8 could you please share it? Else I don’t know what exactly we should do here.
At first i thought:Windows 64-bit so 64-bit processing of 32-bit aligned blocks perhaps causing gaps in 64-bit blocks and that in turn making rendering stuff slower?
But when he mentions Windows Vista 32-bit, i’m out of ideas on that area.
64-bit processing of effects was already done in Renoise since version 2.5 or 2.6? So it doesn’t seem like a plausible cause either.
There must be a project on your laptop that you can share as you confirmed the same problem on your laptop:
Heh, I knew someone would say that. Even if I had a project on the laptop, this wouldn’t automatically mean I can share it. But I still haven’t. I’m just playing around a bit with Renoise here and noticed, it’s also slower than usually. To make reliable measurements, I still depend on the desktop PC.
No but you can trust Taktik and send him something, depending on how desperately you want to have this solved.
If you feel it is slower on your laptop, there is a simple method of trying out if this is true:
Generate a project in one of the previous versions of Renoise where it went faster. Clock the render time.
Save the project and render it in Renoise 2.8 and clock it again.
If you can reproduce this in a simple matter or more steps are required to reproduce, share the steps to reproduce.
I’ve reported this two weeks ago. Not even 1 week ago I’d have been able to send the file within a minute, but none asked for it. And now, after 2 weeks of waiting for a response and a smoked off drive I am pushed to send the prove at the same day? Relax and chill a bit! I know how to measure the difference. But I’m not possessed of proving this right now. Working on the laptop is a pain in the ass to me. I’d also have to install the old version and then to try to setup something replicatable. For what reason, when I have exactly the example I described with my initial report on the desktop drive? I just can’t access it right now.
Believe it or not, but my life doesn’t consist of Renoise only. Everything at the proper time.
Hey Buddy, don’t make things read the way as if we are always responsible for our actions. Don’t forget:You were the one bumping your own topic and claiming you got ignored, so we respond and try to help you considering this is an important issue to you, i’m not trying to force you, just giving ideas to help you help us.
Currently, i am not capable of discovering any large differences between 2.7 and 2.8 regarding the 32-bit version. But frankly, i can’t discover much changes between 32-bit 2.7.2 and 64-bit 2.8 either (2.8 even renders faster than 2.7 on my machine!).
Not that i have been doing very extreme things in Renoise regarding sequencing…
Another topic that comes in mind could perhaps be related? (which also did not yet ended up in the pending bugfixes btw): http://forum.renoise…painfully-slow/
Well, if you’re not responsible for the things you do, I’m for sure even less. But I’m really not up to this kind of discussions anymore.
I really appreciate your effort to help, yet “Will do so as soon as possible. Some days ago my system drive smoked off.” in my response to Taktik actually said it all. We could keep talking about things now for 3 weeks. It’s not gonna change a thing, until my desktop PC is back on. With bumping the topic anyway there’s imo nothing wrong, because till yesterday none at all asked for a file. I’m no clairvoyant and I guess none else here is.
In short: Let’s get back to this, when it makes sense again.
Edit: But before I forget again, maybe Sam is willing to provide his file as an example, since he obviously has similar problems!?
Okay, here we go again. Been rendering a simple demo XRNS on the laptop.
Length of audio: 30 seconds
All native Renoise, no VST/i at all used. XRNS consists of 4 tracks only, 1 effective audio track.
CPU usage (2 cores) in realtime replay about 13%. Offline rendering to 44.1kHz 16bit on 2 cores, prio high (Arguru’s Sinc) took 130 seconds.
Rendering with all the same settings, but interpolation set to “cubic” took 4 seconds only!!