Till this patch is fully loaded up @ 100% Zoom.
It’s lovely to see this slowly reveal itself
HowLongLiBerg-28112019.vcv (26.8 KB)
Me… about 11 seconds.
The reason I posted this was because I noticed that the woodpanels took rather a long time to render. I thought it was funny to make a patch with only woodpanels and see if other people also notice this. There are no prizes to be won by the fastest time, nor will anything be done with the results.
11 seconds here, and i have a very good pc. I noticed graphics are kinda “glitchy” here sometimes. When i zoom in/ out some modules get weird for a moment, or disappear and only reappear after a few seconds. Audio works flawlessly tho 
Lol about same
Does it use all your CPU drawing? I’ve heard it is quite fat.
This test isn’t well-defined unless you specify the zoom level.
Lindenberg Wood Panel has probably way more paths than needed (probably 10,000+), so it’s not optimized and will render slowly.
Correct.
Does anyone know where the manuals for Lindenberg are? The plugin manager still points to github, but since he went closed source the github has not been updated.
The problem is the patina texture. The dust and scratches have a lot of paths, as pointed out by Andrew. But to be honest, I did not optimize it, because I encountered no problems here while rendering. (But of course I didn’t used more then 4 or so).
But thanks for the hint, I will do some tests/optimization today, I am not afraid that it slowes down rendering.
Maybe that kind of graphics should be rasterized.
Cheers
I didn’t wrote so much manuals, just Woldemar has one located on github in the ‚doc‘ folder.
Any certain question?
Wanted to see if the manual for this graphic warns about the potential side effects of using it.
No :-/
I love the way these blanks are customisable, i use then in every patch to cap the ends of my racks.
And it looks gorgeous and I love the fact that the way they are programmed so that not one of them is the same. 
This was NOT the intention of my post 
they look beautiful 
but at a cost, and using 60 of them is a bit much.
That’s why I wish all super cpu intensive plugins would warn you in the manual. It’s fine if a plugin uses a ton of cpu, but if you don’t let people know, then every user will need to discover on their own why some of their patches act strange. The it’s really difficult to find which one is causing this.
Hi all,
finally I fixed this problem by handling complex graphics as cached bitmaps. This may take a bit more RAM but increases speed dramatically. Please take a look at Version 1.3.3 coming at the end of the week - it is currently in the final beta-test. Thanks again for reporting.
Cheers, Patrick
For more information please follow my announcement thread:
