Re: [PD] animation api

-- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico@vt.edu www.performingarts.vt.edu disis.icat.vt.edu l2ork.icat.vt.edu ico.bukvic.net On Jan 6, 2016 9:31 AM, "Jonathan Wilkes" jancsika@yahoo.com wrote: > Are there more than two people (matju and Miller) who understand the > _current_ design? > > -Jonathan > > On Wednesday, January 6, 2016 12:00 AM, Ivica Ico Bukvic ico@vt.edu > wrote: > > > The following is going somewhat OT but nonetheless based on this very > interesting topic: application framerate is no more deterministic than the > proposed idea. Just because monitor refreshes at 60Hz doesn't mean the app > will do the same or consistently. Yet, pegging GUI updates at 60Hz (think > speedlim-like behavior) despite all the loose ends will undoubtedly provide > improved responsiveness over a GUI where one can send sub-millisecond > change requests, most of which will never see the light of the day, despite > eating up tons of CPU and in all likelihood bringing it down to its knees. > > On 1/4/2016 9:32 PM, Jonathan Wilkes wrote: > > Having an animation method allows GUI-side optimizations that aren't > possible when the animation is smeared across the socket/parser/eval'er. > > Determinism: GUI rendering isn't deterministic, at least not in the way > Pd's > scheduler is. For example, how could the GUI (tcl/tk or otherwise) even > know that it missed a deadline? > > I guess the simple API I'm toying with is "stretching the accordion" so to > speak, and potentially showing the cracks more explicitly with a longer > running animation than can currently be seen in Pd's GUI. But that can be > remedied, either by recursively halving a single animation into smaller > ones, > or just giving up and using [line]. > > The greater benefit is that more elegant types of visual feedback become > possible without being discarded out of hand due to their potential for > audio interruption. > > -Jonathan > > On Monday, January 4, 2016 5:20 PM, Ivica Ico Bukvic ico@vt.edu > ico@vt.edu wrote: > > > On 1/3/2016 3:24 PM, Jonathan Wilkes wrote: > > It's actually way more simplistic than that-- just an "animate" method > that > wraps around whatever attribute is available to the drawing command. All > I'll have is a ramp time, an optional delay time, and an optional easing > curve. > That will make it a bit like a [vline~] for GUI side animation. > > I'm using the web animations API because it makes things very simple, even > to do complex things like animating path data. > > The idea is that this would open up some modest visualization > opportunities > that are otherwise too cpu intensive. For example, if you're animating > using [line] the socket messages can quickly get in the way of the audio. > > > Will you at some point drown the CPU? Sure, but that is no different than > a million of other ways of doing the same. OTOH, implementing the animation > this way helps you ensure that your animation remains in sync with the > audio, which to me seems much better gain than a potential CPU/socket > overhead may be a shortcoming. > > There could be some very cool ways of filtering gui messages, as well > (short of getting rid of the socket-based communication in favor of a > shared memory/multithreaded design). For instance, your animation object > could be given the screen refresh rate and therefore it would not send out > a message via a socket unless a desired frame-worth of time has transpired > since the last message was sent. This would do wonders not just in terms of > animation, but also the overall gui responsiveness, if implemented > system-wide. > > Best, > > Ico > > > > -Jonathan > > > > > > > > > On Sunday, January 3, 2016 1:08 PM, Ivica Ico Bukvic ico@vt.edu > ico@vt.edu ico@vt.edu wrote: > > > I think it may make sense in addition to having a one-shot-independent > animations that have no guarantee of staying in sync with the audio (e.g. > these could be useful for mouse-over button animations) that your animation > object can also receive a decimal value between its originator and > destination, allowing for each keyframe to be a whole number. So, 0-1 would > interpolate between the starting state and first keyframe, 1-2 between > first and second keyframes, etc., and thus allow pd to use its timing > mechanism to project changes in animation state via a line object, a > counter or something similar. IIRC most (all?) HTML5-based animations can > be triggered as independent events or can be given a specific percentage > value. The one-shot object could interact with independent events, while > the proposed object could interact with the latter. > > That said, not knowing how you have imagined your animation object, it may > be tricky to implement this as it would require object to keep track of all > the keyframed events (assuming there are more than one). If you are > thinking of having the animation object track only one single animation > (e.g. something progressing from 30% to 90%), the same could still prove > useful except in this case you would only allow for values between 0 and 1. > > On 1/2/2016 1:12 PM, Jonathan Wilkes via Pd-list wrote: > > Hi list, > I'm playing with adding a simple animation api to data structure drawing > commands. > The parameters will be sent to the GUI, and the GUI will take care of the > ramp, delay, etc. > > I'm thinking of just making it a simple "set it and forget it" api. That > is, you send a message > with your ramp and delay times to the GUI, and you just blindly trust that > the GUI will make > things happen in the right amount of time. The alternative I can think of > is to have the GUI > call back when an animation is finished, but that would encourage mixing > the two clocks > (i.e., GUI and Pd clock) in unpredictable > ways. > > Does this simple approach seem like a reasonable design? The biggest > problem would be that > a long-running animation could skew. But in that case you could probably > amortize the cost of > sending more messages over the longer time period. > > -Jonathan > > > _______________________________________________Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > http://lists.puredata.info/listinfo/pd-list > > > > > > > > >