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 ofsending more messages over the longer time period.
-Jonathan
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
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 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
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 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 mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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> 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> 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
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 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 mailto: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 mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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> 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> 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
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 pd-list@lists.iem.at:
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 mailto: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 mailto:ico@vt.eduico@vt.edu mailto: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 mailto: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
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-listhttp://lists.puredata.info/listinfo/pd-list 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
Hallo Gerhard
Ja, üblicherweise wird in Englisch korrespondiert. Es hat aber einige deutschsprachige Mitglieder, daher würde ich dein Anliegen einfach mal auf Deutsch mitteilen. Ich glaube, selbst wenn es nicht üblich ist, wird das wohl schon in Ordnung sein.
Liebe Grüsse Roman
On Mit, 2016-01-06 at 15:40 +0100, Gerhard Kern wrote:
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 wäre nett, wenn sich jemand findet. gerhard
Am 06.01.2016 um 15:31 schrieb Jonathan Wilkes via Pd-list pd-list@lists.iem.at:
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 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 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
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
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.
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@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@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> 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> 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
Would you please test the same on pd-l2ork and/or vanilla? If there is a stark difference, this may suggest that node webkit does some kind of internal event pruning (which would be really sweet). Also, checking CPU overhead may help shed some light as to what is going on. Finally, what are the specs of your machine?
On 1/7/2016 2:20 AM, Jonathan Wilkes wrote:
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@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@vt.edu mailto:ico@vt.edu www.performingarts.vt.edu http://www.performingarts.vt.edu/ disis.icat.vt.edu http://disis.icat.vt.edu/ l2ork.icat.vt.edu http://l2ork.icat.vt.edu/ ico.bukvic.net http://ico.bukvic.net/
On Jan 6, 2016 9:31 AM, "Jonathan Wilkes" <jancsika@yahoo.com mailto: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 <mailto: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> <mailto: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> <mailto: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 <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Do you have a simple patch to test? Not sure exactly what's going on, but I can think of three relevant areas:* node.js APIs are largely built to be asynchronous* V8 javascript engine does JIT compilation of hot code* Chromium goes out of its way to ensure that nothing blocks the renderer from doing its job Of course advertisers don't have to pay for the CPU they consume on your device, which mean all browser-based technology are CPU hogs. -Jonathan
On Thursday, January 7, 2016 11:19 AM, Ivica Ico Bukvic <ico@vt.edu> wrote:
Would you please test the same on pd-l2ork and/or vanilla? If there is a stark difference, this may suggest that node webkit does some kind of internal event pruning (which would be really sweet). Also, checking CPU overhead may help shed some light as to what is going on. Finally, what are the specs of your machine?
On 1/7/2016 2:20 AM, Jonathan Wilkes wrote:
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@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@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> 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> 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
I would test the same patch you built. To tax tkpath and tk in particular you can spread toggles to the four corners of the screen since redrawing area calculation on those toolkits is fairly inefficient. CPU spec and CPU overhead data would also help figure out where the bottleneck lies. e.g. my experience is from a low-powered AMD APU (essentially AMD's Atom counterpart).
On 1/7/2016 11:52 AM, Jonathan Wilkes wrote:
Do you have a simple patch to test?
Not sure exactly what's going on, but I can think of three relevant areas:
- node.js APIs are largely built to be asynchronous
- V8 javascript engine does JIT compilation of hot code
- Chromium goes out of its way to ensure that nothing blocks the
renderer from doing its job
Of course advertisers don't have to pay for the CPU they consume on your device, which mean all browser-based technology are CPU hogs.
-Jonathan
On Thursday, January 7, 2016 11:19 AM, Ivica Ico Bukvic ico@vt.edu wrote:
Would you please test the same on pd-l2ork and/or vanilla? If there is a stark difference, this may suggest that node webkit does some kind of internal event pruning (which would be really sweet). Also, checking CPU overhead may help shed some light as to what is going on. Finally, what are the specs of your machine?
On 1/7/2016 2:20 AM, Jonathan Wilkes wrote:
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@vt.edu mailto:ico@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@vt.edu mailto:ico@vt.edu www.performingarts.vt.edu http://www.performingarts.vt.edu/ disis.icat.vt.edu http://disis.icat.vt.edu/ l2ork.icat.vt.edu http://l2ork.icat.vt.edu/ ico.bukvic.net http://ico.bukvic.net/
On Jan 6, 2016 9:31 AM, "Jonathan Wilkes" <jancsika@yahoo.com mailto: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 <mailto: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> <mailto: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> <mailto: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 <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Try changing GUI_BYTESPERPING back to its original value. -Jonathan
On Thursday, January 7, 2016 12:21 PM, Ivica Ico Bukvic <ico@vt.edu> wrote:
I would test the same patch you built. To tax tkpath and tk in particular you can spread toggles to the four corners of the screen since redrawing area calculation on those toolkits is fairly inefficient. CPU spec and CPU overhead data would also help figure out where the bottleneck lies. e.g. my experience is from a low-powered AMD APU (essentially AMD's Atom counterpart).
On 1/7/2016 11:52 AM, Jonathan Wilkes wrote:
Do you have a simple patch to test? Not sure exactly what's going on, but I can think of three relevant areas: * node.js APIs are largely built to be asynchronous * V8 javascript engine does JIT compilation of hot code * Chromium goes out of its way to ensure that nothing blocks the renderer from doing its job Of course advertisers don't have to pay for the CPU they consume on your device, which mean all browser-based technology are CPU hogs. -Jonathan
On Thursday, January 7, 2016 11:19 AM, Ivica Ico Bukvic <ico@vt.edu> wrote:
Would you please test the same on pd-l2ork and/or vanilla? If there is a stark difference, this may suggest that node webkit does some kind of internal event pruning (which would be really sweet). Also, checking CPU overhead may help shed some light as to what is going on. Finally, what are the specs of your machine?
On 1/7/2016 2:20 AM, Jonathan Wilkes wrote:
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@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@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> 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> 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
Is there an estimated release time of your edition, or do you need any
help with testing etc?
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 messagewith your ramp and delay times to the GUI,
and you just blindly trust that the GUI will makethings 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 unpredictableways.Does this simple approach seem like a reasonable design? The biggest
problem would be thata 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
No estimated time atm. I'm currently stuck in the Makefiles-- while I have a deb package building smoothly, OSX is really a pain. If you want to test on Ubuntu or Debian I can get something ready. There are a few regressions I'm working through with the gui toolkit atm, but in about a week or so most things should be working.
I haven't looked at building on Windows yet. But if someone wants to donate a windows laptop and a Faraday cage to store it in, I'll dive in. :) -Jonathan
On Sunday, January 3, 2016 2:00 PM, João Pais <jmmmpais@gmail.com> wrote:
#yiv8808675196 body {font-size:13px;}Is there an estimated release time of your edition, or do you need any help with testing etc?
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 ofsending more messages over the longer time period.
-Jonathan
-
Gerhard Kern -
Ivica Bukvic -
Ivica Ico Bukvic
-
Jonathan Wilkes -
João Pais -
Roman Haefeli