Is there any way to setup a heartbeat to call a function every X milliseconds?
Sent from my iPhone On Apr 8, 2011, at 12:34 PM, Nathan Rusch <[email protected]> wrote: > I’ve got an idea simmering on the back burner to try and write a node that > fires some kind of Python callback or otherwise indicates that the upstream > tree has changed and is in the process of being re-calculated, and then > another when it’s done processing. It’s fairly low priority though, so I’m > not sure if/when I’ll actually be able to get around to it (or how doable it > will turn out to be). I’ve run into several situations now where it would be > incredibly useful to have a node that indicates tree invalidations and > exposes them for use in Gizmos/Python scripts, since testing/filtering > .opHashes() on every knobChanged trigger feels overkill and fairly > inefficient/slow. > > -Nathan > > > From: John Vanderbeck > Sent: Friday, April 08, 2011 9:12 AM > To: Nuke Python discussion > Subject: Re: [Nuke-python] Creating a custom scripted node? > > So what I am finding is that the knobchanged callback always occurs BEFORE > the frame is updated. I need a way to have my script called AFTER the frame > has been updated. Any thoughts? > > Sent from my iPhone > > On Apr 7, 2011, at 10:25 PM, Ivan Busquets <[email protected]> wrote: > >> Hi John, >> >> If you already have a callback that reliably fires up frequently enough, you >> should be able to use node.opHashes() as Frank suggested. >> >> Not sure how you tested it before, but to my knowledge any change upstream >> of a node should change the hash of that Op, as long as you have your viewer >> somewhere downstream from it. The hash should change whether it's an input >> change, changing a knob of a node upstream, moving to a different frame (if >> there's a sequence or something animated upstream) etc., but the Viewer must >> be somewhere below, or else those nodes won't be validated, and their hash >> won't change. >> >> It seems to me that the trickiest part of it would be having a callback that >> gets called "at least" as often as you want it to, but not too often. If you >> have a global knobChanged callback targeting all nodes, this will be >> triggered very often (not only on explicit knob changes, but also if you >> move nodes in the DAG, connect/disconnect inputs, etc). If you're happy with >> that, though, and all you want is to check whether a more intense >> calculation is really needed, opHashes should work for that purpose. >> >> Not sure that will help you much, but it may give you some ideas. >> >> Cheers, >> Ivan >> >> >> On Thu, Apr 7, 2011 at 6:23 PM, John Vanderbeck <[email protected]> >> wrote: >> I have things working to some extent, but i'm not 100% happy with it. >> >> By registering a global callback with nuke.addKnobChanged(), and then >> filtering the events to only fire off if the calling node is upstream, i've >> got it mostly working. Performance could be better though, and I really >> wish I could just know if I really need to recalculate things or not. >> >> Anyway i'm now running into weird issues that I think are due to how Nuke >> handles the callback stack. randomly, but quite often, the callback seems >> to occur before the image data is really completely redrawn and thus my >> script's calculations end up wrong. I haven't found a work around for this >> yet :( >> >> A better way of re-calculating when the upstream changes would be ideal. >> >> >> - John Vanderbeck >> - http://www.johnvanderbeck.com >> >> >> On Thu, Apr 7, 2011 at 10:02 AM, John Vanderbeck <[email protected]> >> wrote: >> Thanks Frank. My main issue is more with callbacks. How can Ivey my script >> to even be run by Nuke in the first place when things change. I can >> tap in with knobChanged on a global level but if I do that then i get hit >> everytime anything changes, even if it isn't upstream. It's also global and >> I was hoping for something self contained in the node. >> >> I looked at opHashes and best I can tell, it only changes based on what >> nodes are connected not if the knobs on those nodes change. IOW if you >> attach a blur to the custom node's input, the hash changes. But if you now >> adjust that blur the hash does not change. >> >> Sent from my iPhone >> >> On Apr 6, 2011, at 9:45 PM, Frank Rueter <[email protected]> wrote: >> >>> have you tried checking nuke.selectedNode().opHashes() to see if it has >>> changed? >>> >>> >>> On Apr 6, 2011, at 3:17 AM, John Vanderbeck wrote: >>> >>>> Hey all, sorry for what is probably a really noob question, but I'm not >>>> finding the answer in the docs. >>>> >>>> I write little scripts for things all the time, but what I need to do now >>>> is essentially make a custom node that runs a python script whenever >>>> anything upstream is changed. How would I go about doing this? >>>> >>>> - John Vanderbeck >>>> - http://www.johnvanderbeck.com >>>> _______________________________________________ >>>> Nuke-python mailing list >>>> [email protected] >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>> >>> >> >>> _______________________________________________ >>> Nuke-python mailing list >>> [email protected] >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> >> >> _______________________________________________ >> Nuke-python mailing list >> [email protected] >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> > >> _______________________________________________ >> Nuke-python mailing list >> [email protected] >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > _______________________________________________ > Nuke-python mailing list > [email protected] > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > _______________________________________________ > Nuke-python mailing list > [email protected] > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
_______________________________________________ Nuke-python mailing list [email protected] http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
