[PD] Pd as sound editor (issue with "scrolling" a table) ??

[Billy Stiltner]

"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"

thats why i say fix tcl/tk
my old graphics library could be used for a new gui. it is c++ but has the
logic to even only update lines as in blit an arbitrary line.


On Tue, Mar 4, 2014 at 1:33 PM, Jonathan Wilkes <jancsika at yahoo.com> wrote:

>  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.off at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140304/a8d566af/attachment-0001.htm>