<p dir="ltr">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.</p>
<div class="gmail_quote">On Dec 7, 2012 3:43 PM, "Oded Ben-Tal" <<a href="mailto:oded@ccrma.stanford.edu">oded@ccrma.stanford.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
this is on a planetCCRMA system: FC17 PD0.42-5extended<br>
Anyone else encounter such a problem? Any solution (beside moving things outside subpatches)?<br>
Thanks<br>
Oded<br>
<br>
______________________________<u></u>_________________<br>
<a href="mailto:Pd-list@iem.at" target="_blank">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/<u></u>listinfo/pd-list</a><br>
</blockquote></div>