[PD] Pd as sound editor (issue with "scrolling" a table) ??
Jonathan Wilkes
jancsika at yahoo.com
Wed Mar 5 20:40:20 CET 2014
On 03/05/2014 04:36 AM, i go bananas wrote:
> >>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.<<
>
> why do the iem tab objects work so much better then?
I haven't looked at the code, but I'd imagine those externals do some
array-wide operation then trigger a single redraw of the entire array.
For a 100-element array that'd be 100x faster.
But if you want the GUI to look modern you want the chunk of samples
you're displacing to redraw ASAP. For that Pd (Vanilla) still needs to
continually delete and redraw the array as you click-drag the
selection. So it's better than the worst of all possible worlds-- using
[tabwrite]-- but still extremely inefficient (not to mention it doesn't
scale).
To be fair, it's unclear how to "do this right" even with a "clean"
separation of GUI/core. It's unclear what "clean" means, and it's
unclear what "this" is.
To be specific: it's really hard to predict what purpose the user will
find for the realtime audio engine when the GUI is also a programming
language. For example, you can get all kinds of speedups in a DAW by
waiting for the user to release the mouse button when displacing a
selection. But if you did that by default for "Put" menu arrays you'd
ruin several of Miller's tutorials, where an immediate connection
between visual array change and audio change is vital if inefficient.
-Jonathan
> maelstorm said that it was incredibly slow using an [until] based
> counter, but worked smoothly with the iem objects. This was for
> EXACTLY the same gui, so i'm not really sure if it's a gui redraw issue.
>
> Then again, he also said that the iem tabs objects seem to process
> tables in chunks...so maybe the gui is also only redrawn in those
> chunk sizes? that would make sense i guess.
>
>
>
>
> On Wed, Mar 5, 2014 at 10:35 AM, Billy Stiltner
> <billy.stiltner at gmail.com <mailto:billy.stiltner at gmail.com>> wrote:
>
> "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 <mailto: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 <mailto: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 <mailto:Pd-list at iem.at> mailing list
>> UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
>
>
> _______________________________________________
> Pd-list at iem.at <mailto:Pd-list at iem.at> mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at iem.at <mailto: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/20140305/6b290d7b/attachment-0001.htm>
More information about the Pd-list
mailing list