hallo liste, ist es üblich, dass über die pd-liste in english korrespondiert wird ? ich bin 70 jahre alt und habe das nie richtig gelernt, habe eine menge fragen zu pd-projekten und suche jemanden, der oder die mir hilfreich zur seite stehen könnte. meine fragen bewegen sich vor allem im bereich von midi und arduino zur steuerung von musikmaschinen. einiges zu meinen arbeiten ist zu lesen unter www.musikmechaniker.blogspot.de <http://www.musikmechaniker.blogspot.de/> wäre nett, wenn sich jemand findet. gerhard
> Am 06.01.2016 um 15:31 schrieb Jonathan Wilkes via Pd-list > <[email protected]>: > > 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 <[email protected]> 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 <[email protected]> >> <mailto:[email protected]> 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 >>> <mailto:[email protected]><[email protected]> <mailto:[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] <mailto:[email protected]> mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> <http://lists.puredata.info/listinfo/pd-list> >>> >>> >>> _______________________________________________ >>> [email protected] <mailto:[email protected]> mailing list >>> UNSUBSCRIBE and account-management -> >>> <http://lists.puredata.info/listinfo/pd-list>http://lists.puredata.info/listinfo/pd-list >>> <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
