PurrSoftware Module Browser Rendering Issue

And a bonus movie at 60 Hz


Hurry up and watch them now, they will be gone in 6 days from now, read all about it :wink: :laughing:

1 Like

Yep, that is the exact type of behavior I see. Thanks for doing these. Can you try it with frame rate set to 20 Hz? I can never get it to stall at lower than 30 Hz on my system. If it still stalls at 20 Hz, could you try at the lowest setting of 10 Hz to help do the box test?

I’ve looked at this for so long that I have a migraine aura which blocks my field of view for about 30 minutes or less. Just like with this Rack problem, I can never figure out what triggers my “migraines without headache”. In my younger years I would have the aura with terrible headache. At least no pain with just the aura :wink:

I appreciate you doing some testing on this. I need all of the help I can get in trying to understand what is happening. Thanks.


Easy Ken, I can understand your anxiety over this, but it’s far from a show stopper.


Thanks, Ewen. I hope it is not a show stopper for anyone. But I do not like it that my modules are affecting the UX for users. Sometimes I think my auras come from “waiting with bated breath” to see what happens when I make a change trying capture a problem in a box where I can figure out what variables affect the issue. My aura is already gone.

1 Like

At 20Hz it does NOT stall!

Started to make a movie but this one is just lame, 1/10 no reason to watch it :laughing: :scream: :partying_face:


I think the refresh rate must be one dimension of “the box”. Thanks for testing this.


As anyone who has ever coded sorting, searching or fitting algorithms knows, there are a myriad of ways that the algorithm can deadlock. I don’t know if that is what is in play here in the browser. It is probably going to take someone looking in the browser code to understand what could be happening. I normally don’t dig into the Rack code as that is not how I want to spend my time.

One thing I changed in my last PurrSoftware release a few months ago was to fix the panel size for each of my modules since at least one of them was not an integral HP width. I’ve wondered at times whether panel size is saved somewhere outside of rack at VCV. I have no idea.

I should add “approximating” to my list of algorithms prone to deadlocking. Looking at a previous release of Rack V2 that I have downloaded before, there is an approximation value of 12 HP in the browser code that is used to approximate how many modules will fit in the render before we know the actual module width. My modules are 80, 46 and 33 HP, so, a 12 HP assumption/approximation may lead to problems But, the Browser.cpp file is about 1000 lines long, so is relatively long and complex.

My best guess is that this is a “lazy update” bug in the browser, when some edge case is encountered.

One last thing… I get the same behavior with an empty patch, so this issue should have nothing to do with the patch.

1 Like

This in your ModuleWidget::step override looks suspicious to me.

I’m not understanding why it’s necessary to muck with your parent’s/parent like this. Seems like something that could cause issues and might be solving a problem that has a better solution (like dirtying when your setting is changed rather than unconditionally).

		// if in the browser, force a panel redraw per frame with the current panel theme
		if (!module) {
			DirtyEvent eDirty;

Thanks Paul. I will look at this. I do not remember why I do that or where I got the idea. Usually I look to see how other developers do something, in this case handling light and dark panel themes.

By golly, I think you are right. If I comment out the onDirty() line, everything seems fixed in the browser!


Here is where the parent->parent usage came from:

Anyone else who has implemented this probably needs to reconsider it.

I think I am going to test and do a quick release of my modules that fixes this problem without worrying about whether the current panel theme is rendered in the browser. The user can still change my modules themes in the patch and it will change the theme for each instance of that module in the patch as well as the default for the browser for future patches. Later I can determine the correct way to do this in the browser.


I’m very happy we solved the issue!


I am very happy you pointed this out. Thank you very much!


I wonder if this is responsible for those voxglitch render reports?

I wonder also since the browser symptoms are very similar. But some of the Voxglitch reports had the module rendering in the patch messed up. We never saw that with my problem. There are probably many ways to mess up browser performance. All of those other possibilities I was considering could still be at play in some other modules. Or not.

It it is sad that it took 2 years for us to realize I had a problem in my modules that could affect all users’ browser performance if they are subscribed to my modules. In retrospect, I and at least one other noticed the browser performance issue two years ago, but, we could not figure it out.

Luckily, there was no question when I commented out the suspected code that the browser functionality was unambiguously improved.


After testing, I have now submitted V2.0.34 to the library queue. This fixes the browser render problems with my PurrSoftware plugin modules.


Today is a good day :partying_face:


PS-PurrSoftware plugin V2.0.34 is now in the library. This fix which I made last week was for a bug affecting the browser experience for anyone who has my modules (Meander, ModeScaleQuant and ModeScaleProgressions)installed, but only when at least two of my modules were being displayed in the same browser “render frame”. The browser rendering of the modules would stall and other modules that came after mine in the users sort order would not render until the view was scrolled down a bit, sometimes the scroll would be until my modules disappeared off the top of the page.

I highly encourage everyone who subscribes to my plugin or modules install this update. You should see an improvement in your browser render speed.

Note, this bug was introduced two years ago but was aggravated when I released my 2nd and 3rd modules in the fall of last year.