Laggy GUI (~2 FPS) when using 64klang2 VSTi


I’ve upgraded my PC to Windows 10 Anniversary and to Renose 3.1.0. Previously I had no problems, but since I’m using the newer versions, I have a huge problem.

Note that the PC is freshly installed, there’s no bloatware running. Current nVidia graphic drivers are installed. CPU is a Core i7 4770, and I have 24GB of DDR3 RAM. The system and renoise drives are a RAID0 of 2 Crucial MX300 SSDs. So the PC is quite fast.

Here’s a video showing the problem:

As soon as I create an instance of my VSTi, the whole renoise GUI becomes laggy. Key strokes arrive some 200-400ms too late. What I noticed is that the entire UI gets ‘refreshed’ and feels responsive, every time that I move the mouse on the plugin window. Moving the mouse on the renoise window doesn’t help though.

The CPU usage is minimal, it also happens with an empty song and without triggering any single note in the VSTi.

I have a friend with a similar configuration (also Windows 10 Anniversary and Renoise 3.1.0, same VSTi) who doesn’t have this problem.

I’ve tested single/dual monitor setups, closed/minimized VSTi GUI, DirectSound or ASIO (via ASIO4all), compatible GUI rendering, GUI effets/animations disabled, etc. Nothing has helped so far.

I’d be glad for any kind of help.


  • xTr1m

xTr1m: I think the vst in question is 64klang2?? I’m just wondering does the gui in that use any DirectX/OpenGL calls? Anyway, I assume you’ve already thought of this but if you haven’t I’m curious, is there an option with the NVidia driver preferences program to disable ‘wait for vertical sync’ (similar to this post -> )? Not that I think that will help the stuttering/laggy gui xTr1m in this case but I was a little curious if there is any slight difference.

I will try that tonight when I return home.

Yes, the plugin in question is indeed 64klang2. From what I know, it uses WPF to draw its GUI, and WPF uses DirectX9 for rendering, with our without hardware acceleration.

You see in that other thread what I eventually discovered is that the Melda plugins default to 80fps(!) Which to me is a bit high, I found that limiting the frame rate down in the plugin to say 30fps made Renoise more happy. I’m not saying though that in your case xTr1m it will help you, it is just a long shot thought about gui refresh rates in plugins :slight_smile:

I’ve tried turning VSync off in the nvidia control panel, and this has indeed improved by situation. Now it’s not ~2FPS, but ~4FPS. And I can now force a GUI refresh from within the renoise window, meaning that there’s no more input lag when I use the keyboard, and moving the mouse on the renoise window will make it look responsive.

But still, without user interaction it’s very laggy.

Yes xTr1m, I’m not really surprised. To be honest I/we can only speculate what is going on because we don’t understand nor have the source to Renoise. But I can tell you where I stand with this. I first came into contact with this problem with the Melda plugins running at say 80fps on my machine. I initially thought it was to do with hardware acceleration/GPU rendering, hence why I opened that other thread I pointed to. But I think (again pure speculation on my part) it is just to do with high vst gui refresh rates. I speculate that if you could limit the refresh of 64klang2 you’ll probably find that this now gives back more time for Renoise to refresh its gui. The question is though should you need to? I assume that other music applications don’t mind 64klang2? Their gui continues to refresh at a healthy rate in the background. I would imagine that taktik has got to find a plugin that does what you show in your video and he has got to assess whether it is to do with the way Renoise is handling its refresh :slight_smile:

(Pah, the Amiga would never put up with such nonsense. I say bring back the copper list and get the copper to trigger the blits for a nice full frame rate scroll :D)

4Tey: Yes, I’ve tried it with other DAWs and their refresh rate is just fine. I will try to narrow it down by disabling startup programs, until the bare minimum of windows is left. If nothing helps, then I don’t know what else could be the problem.

OK. I’ve been doing selective startup, disabling and enabling startup programs and services, each time testing if renoise was lagging and when it wasn’t.

I did this because I thought to give it a try to boot only with essential services, drivers and no startup programs, and renoise didn’t lag!

Finally I’ve isolated the problem: Microsoft’s “Touch Keyboard and Handwriting Panel Service”. Disable that, be happy.

No more lag.

Microsoft’s “Touch Keyboard and Handwriting Panel Service”??..oh well, so long as it works with no lag xTr1m :smiley: