[PD] animation api

[Ivica Bukvic]

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>
> <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>
> <ico at vt.edu> <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>
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160106/4115cbaf/attachment-0001.html>