Anyone else on linux experiencing module browser issues?
I invoke the browser, it starts populating, gets increasingly slower, then grinds to a halt, sometimes with as few as half a page of thumbnails. This was an issue before but got fixed, now it’s back again.
That is exactly what I saw on Windows 11 the first time I launched Rack 2.2.0 . As mentioned elsewhere, I loaded a very simple patch and the browser was able to populate the panel images cache fairly quickly. Then I was able to load complex, high CPU patches and use the browser with no problems. I have no idea if this is the same issue as you are having on linux.
Have you played around with the engine thread count to see if that makes any difference?
Just checked, seems identical behaviour, thanks Ken.
Seems to be ok for me, or at least I don’t notice any difference.
The 2.2.0 module browser works just fine on my Debian Bullseye system, running Xfce as the graphical shell. It’s quite snappy actually. Maybe I don’t have as many plugins installed?
It does seem related to complexity of the patch at the time the browser is invoked. My template patch starts with over 70 modules, if I load a test patch of a dozen or so modules the browser is quite snappy, with my template patch far less so. As stated this was an issue a while ago, it wasn’t an issue in 2.0.6.
Yes, this seems to be a browser issue with V2.2.0 rather than an OS issue. I have the same issue now with a complex patch. If loads less than a page worth of panel image and then just stops. I can scroll down and and more images will cache, but the skipped images on the first page are still black when I go back to the top of the list. It seemingly takes forever to scroll down through all modules. As soon as I go back to a simpler patch, the browser returns to reasonable behavior.
For reference, my complex patch has 106 modules in it and is running at low frame rate and high CPU usage.
What happens if you use the module browser with the same patch in Rack v2.1.2?
That works with no problem.
It is also tied up with patch loading. For complex patches it takes quite a few seconds to totally instantiate all modules and display the panels. I suspect that there may be an interaction between panel image lazy caching. patch loading and browsing.
Naaah. The only thing I could remotely imagine is that timing stuff, but it’s above my paygrade.
Actually, I shouldn’t be so quick to dismiss, because I haven’t read the surrounding code or call-tree. I’m assuming the function with the fuzzy search changes is only evoked at the time the module browser is opened. If on the contrary it’s evoked at every patch load there might be something to investigate. But it wouldn’t make sense to me.
Maybe @jnorberg could shed some light on this, since he wrote it and submitted the improvement to Rack v2.2.0: Could the above mentioned problems be caused by the change to the fuzzy database functionality?
Is there a new rtaudio? Once a patch loads is the measured cpu usage different? On my win11 system the cpu usage goes up like 10% when the module browser is open.
I can’t see anything consistent regarding higher CPU while the patch is loading or when in the browser.
This is an extremely annoying bug. I keep having to load a simple patch to get the browser cache to populate. Then if I open a complex patch in the same session, it will do okay, but if I exit the complex patch and relaunch Rack, I’m in the same situation and have to repeat the steps again.
Same.
Have you reported this to Support?
Long since.
Also considering throwing a message in a bottle into the local canal 