<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Thanks for the extensive description of the solution. I&#39;m currently working with vvvv on win7 but I&#39;m osx user and this is the main reason why I&#39;d like to switch to pd+gem. I&#39;ll work on visual output only, so I won&#39;t do any dsp (there is a plan for future but lets not think about it). vvvv also uses only one core per instance (without a solution to somehow split process in one instance) and my current project is quite heavy to handle it this way. There is a solution as with pd, to run two or more instances who communicate and leave the system to handle the multicore spliting. I&#39;ll try pd+gem anyway just to see how it will work...<div>
<br></div><div>thanks,</div><div>vedran</div></span><div class="gmail_quote"><div><div class="im"><br clear="all"><br><br><br><br>.....................................................<br>vedran kolac<br>.....................................................<br>
gTalk - <a href="mailto:vedran.kolac@gmail.com" target="_blank">vedran.kolac@gmail.com</a><br></div><div class="im">
.....................................................<br>skype - vedrankolac<br>.....................................................<br>+385 (0) 91 567 07 17<br>.....................................................<br><a href="http://www.onoxo.net" target="_blank">http://www.onoxo.net</a><br>

<a href="http://www.projectmoe.net" target="_blank">http://www.projectmoe.net</a><br>.....................................................<br>
<br><br></div><div><div></div><div class="h5"><div class="gmail_quote">On Mon, Apr 5, 2010 at 8:43 PM, Matteo Sisti Sette <span dir="ltr">&lt;<a href="mailto:matteosistisette@gmail.com" target="_blank">matteosistisette@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(this is a little OT respect to the thread)<div><br>
<br>
&gt; nicely enough, pd&#39;s graphical interface and the actual process,<br>
&gt; are separate threads,<br>
<br></div>
The communication between the engine of Pd (&quot;Pd&quot;) and the graphical interface (&quot;GUI&quot;) is not as efficient as you may expect it to be - at least not as much as I expected it to be.<br>
<br>
When you send a message to a GUI object, such as for example a &quot;set&quot; message to the receive-symbol of a slider, the Pd process sends a message to the GUI process and the GUI process actually redraws what it has to redraw: so the Pd process is not &quot;blocked&quot; while all the (embarassingly cpu consuming) draw operation is performed. So you would expect that the time needed to send a message to a GUI object is just the time needed to send a message through a TCP socket.<br>


<br>
Not quite so.<br>
I don&#39;t know why, but when you send a message to a GUI object it takes significantly much more CPU time to the Pd process than simply sending a message through TCP, though much less than it takes to actually redraw things. I _guess_ the Pd process probably waits for some kind of aknowledgement or respose from the GUI process or something like that, but this is only a guess.<br>


<br>
I found this out because I create patches that have to be used &quot;on the stage&quot; by users that are not &quot;pd-ers&quot;, so I make extensive use of GUI. All significant parameters or values that can be changed and/or need to be monitored are displayed on the GUI. So I send a lot of messages to the GUI. I also store &quot;snapshots&quot; of configuration that are then called (_not_ loaded from disk at the moment of calling them), so there often are &quot;massive&quot; bursts of messages to a lot of GUI objects in zero logical time (I already reduced the messages to only the actually needed ones). So, soon I began to have a lot of audio dropouts.<br>


<br>
So I tried out a solution that seemed ridiculous at first: I made an &quot;engine&quot; patch which does all the audio and midi stuff but has no GUI, and an &quot;interface&quot; patch that has only the GUI stuff, and exchanges control data (in both senses of course) with the engine patch. And obviously I run them on two different instances of Pd.<br>


<br>
My &quot;protocol&quot; of communication between the two patches is not even very optimized, so I send a lot of messages that could actually be avoided (don&#39;t tell anybody).<br>
Well with this system, despite the huge quantity of messages to and from GUI, I get no dropouts at all, everything works fine.<br>
<br>
I have indeed replicated &quot;at the patch level&quot; the engine-GUI architecture that is already implemented in Pd. When I did it, I really was afraid that I was doing something stupid; but it did work, and it makes an enormous difference (well I did do some test before, that seemed to indicate that it may work).<br>


So the time it takes (meaning the time during which the Pd process is either blocked or busy) to send a message through a [netsend] (with even a little overhead: passing through a [s] and a [r], a [list prepend send] and a [list trim] at the very least) is significantly less than the time it takes to send a message to a GUI object.<br>


<br>
I am curious to know whether this overhead in the communication between the two processes of Pd is entirely necessary (to robustly guarantee consistency for example) - and in case it is not, whether it is going to be addressed in the gui-rewrite......<br>

<font color="#888888">
<br>
-- <br>
Matteo Sisti Sette<br>
<a href="mailto:matteosistisette@gmail.com" target="_blank">matteosistisette@gmail.com</a><br>
<a href="http://www.matteosistisette.com" target="_blank">http://www.matteosistisette.com</a><br>
<br>
_______________________________________________</font><div><div></div><div><br>
<a href="mailto:Pd-list@iem.at" target="_blank">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -&gt; <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div><br></div></div></div>
</div><br>