defer_low inside the external
i know i can call a function deferlowed like this
defer_low(x, (method)flop_bang, NULL, 0, NULL);
my question is, can i tell a method to always execute low prio if it gets called? or do i have to call one function that calls the second function with deferlow?
O.
i have to read the quelem related parts of the manual before i reply. but now i have to cook the pasta with mushrooms.O.
hey vanille, nice that i have your attention again. i'm confused why i should use qelem. it seems much more effort than call the method from another method with deferlow. in both cases the call from the patcher cannot directly do deferlow without calling/set_qelem something.?O.
A_DEFER_LOW a special signature for declaring methods. This is like A_GIMME, but the call is deferref to the back of the queue.
hmm. there seems to be a way..
yes, "unknown message argument type". the thread you mentioned is what i should have searched for before creating this one. although i don't really understand what Timothy Place is saying there about ownership of an event. would be helpful to just know in what kind of situation one could get problems because defer_low(fun) is used instead of a qelem.O.
A_DEFER_LOW probably only works for jit_class_addmethod.
It is true that A_DEFER_LOW only applies to Jitter classes.
The qelem is prefered to defer_low() because for a couple of reasons:
1. If you are calling defer_low, then you are basically creating a qelem sticking your call onto it, and then having it destroy itself. Meanwhile you have no control over the qelem. You can't stop it, your object might be deleted before the method is called, it's wasting computational resources, etc.
2. With a defer_low() you open yourself up to flooding Max's queue, and thus degrading the performance of the application. Every call that comes into defer_low() will go out. Occasionally this is the desired outcome and the use of defer_low() here is appropriate. Usually it's not. Usually when you need something deferred like this and several messages arrive before any of them is handled, you really just want the last value (or the first value) and with a qelem it will do that. This way Max doesn't have to spend a lot of cycles processing useless garbage that is on the queue but won't really be used.
Once you're used to it, the extra plumbing of using a qelem shouldn't seem like that much extra work...
Hope this helps make sense of it all!
Tim
thanks Timothy, for the additional info.
im sorry if this is described somewhere,it may be that i did not noted it at the right time : is it true that qelem'ing will act for the whole max application threading or just the structure/object threading itself ? do im creating unique thread that is let say compensated from a particular object thread (my object) or it affects Max main thread/schedule ?
Hi .
thanks , it actually clarified everything . im participating in one of those threads , this is what i wanted to know . I will be able to deduct the rest with SDK doc .
My question was not clear because of my understanding , so im formulating questions based on my intuition that i build upon how i understood certain aspect which leads to bs sometimes . reading SDK sections for a few times now