[PD] graph on parent problem?

[Ivica Bukvic]

If I understood your problem correctly, this might be because pd redraws
array contents very inefficiently, so if you are constantly changing array
contents that can prove quite cpu intensive. Similarly, moving such gop
patch requires complete redraw of all its contents. Pd-l2ork fixes latter
problem by moving such structures via tag, rather than redrawing everything
(so in pd-l2ork moving such gop structure would be one instead of
potentially thousands of commands), but the former problem is something
that can be only solved by rewriting or getting rid of the networked
gui-dsp communication protocol.
On Dec 7, 2012 3:43 PM, "Oded Ben-Tal" <oded at ccrma.stanford.edu> wrote:

>
> I have an array in a subpatch, when I applied graph-on-parent property to
> the subpatch (to view the array which holds sound so could be fairly large)
> Pd didn't like that. With dsp off it worked fine but when I turn dsp on Pd
> becames unusably slow to react (sliders, etc.). I was able to solve the
> problem by removing the graph-on-parent option. So it seems there is
> something in the interaction of graph-on-parent and the sound engine.
> this is on a planetCCRMA system: FC17 PD0.42-5extended
> Anyone else encounter such a problem? Any solution (beside moving things
> outside subpatches)?
> Thanks
> Oded
>
> ______________________________**_________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/**
> listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20121207/87ca9f8f/attachment.htm>