[PD] animation api

Thu Jan 7 08:20:24 CET 2016

In the GUI port I hooked up about 14 toggles to a [metro 1] and was getting 
anywhere between 30 and 40 fps in the GUI.  I could continue creating new 
objects in the same patch.
Now if I connected each of those toggles to a [print] I'd probably freeze the 
GUI.  But I'm not doing any optimization on console, nor limiting the 
size of the scrollback buffer.  (I am, however, displaying a hit count beside 
duplicate messages which cuts down immensely on noise.)
At least for now, if some common patch behavior is able to DOS the 
GUI I'd rather have it freeze up as an incentive to fix the underlying problem.
-Jonathan

    On Wednesday, January 6, 2016 1:07 PM, Ivica Bukvic <ico at vt.edu> wrote:

 Create a metronome with less than 2 milliseconds clock and connect it to a bunch of toggles, turn it on, and enjoy interacting with a barely responsive gui. The same is achievable with a less dubious implementation where a graphical user interface simply has a lot of concurrently animated components.NB: depending on your computer specs the two millisecond threshold may have to be set lower.-- 
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 at 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 at 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 at 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 at 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 at 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 at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

 _______________________________________________
 Pd-list at lists.iem.at mailing list
 UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160107/a26ba773/attachment-0001.html>