spectre

I've written a script which attaches to objects and animates any changes to their location, width & height. This could prove useful for patches that wish to conserve space until a certain event occurs, adding space only when necessary. But there seems to be an odd issue with faster animation speeds...

Just wondering if anyone is able to figure out why? Project attached.

I've written a script which attaches to objects and animates any changes to their location, width & height. This could prove useful for patches that wish to conserve space until a certain event occurs, adding space only when necessary. But there seems to be an odd issue with faster animation speeds...
Just wondering if anyone is able to figure out why? Project attached.

morphing-max-objects

It works perfectly fine until the animation interval is set to anything below 15. I've tried all sorts of ways to figure this out, but I can't make any sense as to why it only works above an interval of 15. The closest guess I had was that the animation event was firing before the previous one had time to finish, but the code I wrote to catch this appears to disprove this theory.

A great alternative would be a method that could asynchronously delay the animation's frame rate. But I can't find any topics on this. It seems once a script method is called, the thread focuses on the script until it returns execution to the patch. But if there is a way around this, it'd be just as helpful to know about!

Can you please describe the behavior? I've set it up on mine, and the only difference between animations is the speed. Explaining the problem would possibly help me see it. Nothing appears to be wrong.

Also, details about OS, etc. can't hurt.


Set the animation interval to 25 or so then expand 3 times, and then compress 3 times. Works fine.

Then set the animation interval to 1 and expand 3 times, then compress 3 times.

You'll notice that the animations end prematurely and go out of control, sometimes even allowing the user to compress more than the maximum allowed compressions.

I read that the Task() object shouldn't be used for time-critical operations (such as sample-accurate audio processing), but since this is all just sequential eye-candy, the only thing that this should effect is a slight *delay* between animation frames, not the opposite. So I don't believe this to be the culprit, but I can't figure out what is.

Steps to reproduce behavior:
============================
Set the animation interval to 25 or so then expand 3 times, and then compress 3 times. Works fine.
Then set the animation interval to 1 and expand 3 times, then compress 3 times.
You'll notice that the animations end prematurely and go out of control, sometimes even allowing the user to compress more than the maximum allowed compressions.

I read that the Task() object shouldn't be used for time-critical operations (such as sample-accurate audio processing), but since this is all just sequential eye-candy, the only thing that this should effect is a slight *delay* between animation frames, not the opposite. So I don't believe this to be the culprit, but I can't figure out what is.


I could reproduce the problem you described. I could not figure out why this problem occurs. But I have attached my version of the patch which seems to be working alright. My guess is that the problem may be that the Task object at some point sends requests for updates faster than the execution time of the functions it is calling.

'Morphing' max objects