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.

-Jonathan




 

   

 On Sunday, January 3, 2016 1:08 PM, Ivica Ico Bukvic <[email protected]> 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
   
  
 _______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list
 
 
 
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


  
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to