On 03/04/2014 01:20 PM, Jonathan Wilkes wrote:
On 03/04/2014 10:11 AM, i go bananas wrote:
[...]
2014-03-04 12:12 GMT+01:00 i go bananas <hard....@gmail.com
<mailto:hard....@gmail.com>>:
just for interest perhaps, here's the sound editor i made
years ago:
http://puredata.hurleur.com/sujet-1295-sound-editor
and probably even more interesting, here is maelstorm's wave
display abstraction:
http://puredata.hurleur.com/sujet-5890-waveform-display
basically, what maelstorm discovered was that using [until]
with a counter was not nearly fast enough to do the
calculations needed for a decent zoom/scroll function, and we
looked into it, and there just didn't seem to be a vanilla
workaround. So he uses iem_tab objects to do the table
calculations.
Remember that when you redraw an element of an array you actually
redraw the _entire_ array in Pd Vanilla. And depending on the array
style you may have a separate tk canvas item for each element.
So when you use the [until] loop you are sending drawing instructions
to the GUI ($arraysize * $no_mouse_events) times. A single array
redraw instruction in tcl is about 4k, so to scroll a single pixel for
a 100-element array:
100 elements * 1 = 100 redraws * 4k = 400k
That's flowing from the core to the GUI for a _single_ mouse event.
If you trigger ten scrolls you're already at 4 megs of data sent.
I'm pretty sure commercial editors avoid that type of design. In
editors like the upcoming Openshot Video that have several discrete
parts that sending messages, the GUI part almost certainly sends
nothing at all to the video core for zooming/scrolling. For moving a
chunk of audio/video, it almost certainly sends a single message about
a single object's delta.
I may have showed this already, but I think it's instructive here:
https://jwilkes.nfshost.com/pd-tiger.webm
I don't have sound on that clip, but I believe I tried it with the "test
audio" patch going and I wasn't getting dropouts. This is because a)
I'm sending a single transform message for every scroll of the number
box and b) the GUI toolkit-- not Pd core-- is doing the math to
transform and redisplay the drawing.
Socket traffic is bad because it require both the core (sending) and GUI
(receiving) to do work. If you generate megs and megs of traffic you
can end up with dropouts and choking display even if there's very little
being redrawn.
-Jonathan
-Jonathan
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
