modulating alpha videoplane
I realized today that my jitter patch is slowed down by modulating the alpha of a videoplane. I want to map the amplitude of the sound to the alpha of some videoplanes. I used speedlim 30 to avoid it to be modulated faster than the speed of the images.
Someone has an idea how to do it without losing performance?
I’m not really sure but
[ jit.qball ] instead of [ speedlim ] might help.
I tried to use jit.qball instead of speedlim or one after the other and it’s about the same.
When I remove that mapping, I win 10 fps more on 8 videoplanes at the same time. It’s quite a lot and make think about removing that mapping…
How are you modulating the alpha channel? Could you post a simple patch that demonstrates the technique?
note that it is normally inside a M4L device.
----------begin_max5_patcher---------- 726.3ocuWtsaiBCDF9ZxSgEWmFYywvp8lceMpppb.2D2ZrQXSa1sp8YewFHg tAZHzFqHYB9T9mOOy3IutvwciXOQ5B9A3VfiyqKbbLco6vo8cG2b79TFVZll apHOmvUtKaFSQ1qL8+ya.3pLp.P4ci8ffqjz+Rzii7VAa6lWkS4LhxrenicJ pTc81M0BrJcGku89RRppQkH+fUgKAHXj9QTb81B7fqff6ZWCMynGwlGuIpuR 33biRb+UIEyb0C71hE5lkSzzMp1cHq.NnUf9Dq.ZDNBFXzeXW6AqnYaT+ofz r.W2gLvfN0zcpnGXNll7EsF61smwkGnUpnhQpJkCZ29cVXIQV+yiUTAumU5G GYrReiUhRVqeDE0yL+Hv7FGXgMfZ8Xazo7ZIv8Al.qNBt9pr+4Sef54dPCk0 HPQJumvwaXlsENCxxIuTuwmDt7HUsZKa0yzLhnfg4DPFIW70ib9DD5aNL7Wa b1PdmF4bBCqE484XUIcullC5Ah9dCwFgVE3zm.On+LHgfCSH+KMpr0IKPSbP noEs9xCJiGmIfeKXYeifoheDMWFbF18I3rvAkneDCOObZh9VN9WFDd91CdxB BIiQyA9vUWB57tT+p1HOOeC5PyzuBkjXO1TfeBjJXhx43aENO.40badBb1.x hQd02NTHyEB0t2AAPHzzbUyN0UyPTho.HuIjeRR2xqSDOHrh8sRpaIGWH2IT uWWeyUMHSWQnAHwZ7LknrwyBghCrBbvOSJwaIuCBg.7FofUoHe8j3SvGJrAO suMeenvogIyhcYT9++eMLRT2+GYmTTUl1If1BcAG0XFQpn7C0wcaO0zaV6nY YDd+xyynRcobYiWK2j0i2DDj9tLKoGiC64IjNAIHvNJRea04Uj8Hjw1OOgRr mOj18v6b9PweXRWc8flhdP1SOvonGKcdEO4PLjkB58mTZw.KlFJbRJZtIFA2 s3sE+CvxwI0I -----------end_max5_patcher-----------
I see no reason why this patch would cause a significant slowdown. It’s not doing anything computationally intensive. You could get rid of the unpack/pack combo in favor of [zl slice 3] and reduce your object count though.
the patch you attached is not sufficient to guess the reason.
But I’m trying to guess:
Since slow-down problems when working with open-gl objects are often caused by multiple, traditional Max timing objects such as [ metro ], [ snapshot ], [ line ], etc., I’d recommend you to check if you are using [ metro ] instead of [ qmetro ], and try to use only one [ qmetro ] as a ‘master clock’.
This is also why I told you to use [ jit.qball ] instead of [ speedim ] in the last post of mine.
Yes, I’m using a qmetro 30 as a master clock for all the videoplanes.
Note that I’m modulating the alpha of 8 videoplanes at the same time and together, when I shut the modulation off, I save about 10 fps. It means that each modulated alpha reduces the fps of about 1-2 fps…
Do you have depth_enable on or of? How big is the window and do the videoplanes fill the entire window? When you overdraw a window many times, you can start to become fill rate bound, meaning the GPU can’t process the number of pixels you’re asking it to. If you could make a normal Max patch that demonstrates the same problem, that would help.
ok. I’ve found that the patch works well in Max alone. The problem comes when I use it inside M4L.
This is the live set with the M4L device.
I tried to clean the patch the much as I could.
deph enable = 0
it’s running around 20 fps with modulating alpha activated and above 25 fps when it’s off. keep in mind that this patch is running 3 videoplanes and in the big patch, there are 5.
macbook pro, 2.8 GHz Intel Core 2 Duo, 8 gig, 10.6.8, NVIDIA GeForce 9400M