ok, broc is the expert, listen to her/him. however, i’ll add…
no, sorry, i did not look at your .amxd originally – i was just answering to the ‘deferlow’ issues. however, i have looked at your example device now and the answer is very simple and is a tricky part of the API that has always been there (and documented), namely: you cannot trigger processes based on observed notifications from the API.
this is one of the API ‘rules’. it is for this very reason that use of the [deferlow] object was envisioned, and its use here is perfect and correct and exactly as you had it. there was possibly confusion because [live.path] is not strictly an ‘observer’ object but, give it the argument you gave it to track straight to “detail_clip” and it becomes one.
therefore we ascertain that SOME parts of the API are slow, in terms of callbacks. as broc said, “the path calculation of ‘detailed_clip’ is much more complicated as the clip may reside anywhere in the set depending on user interaction”.
i attach a .amxd device based on yours demonstrating this, although i am sure you get it… disclaimer: i am no API expert – i delve into it now and then.
Nov 10, 2011 at 2:11pm #215705