<br><br><div class="gmail_quote">On Mon, Apr 5, 2010 at 8:43 PM, Matteo Sisti Sette <span dir="ltr"><<a href="mailto:matteosistisette@gmail.com">matteosistisette@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(this is a little OT respect to the thread)<br>
<br>
> nicely enough, pd's graphical interface and the actual process,<br>
> are separate threads,<br>
<br>
The communication between the engine of Pd ("Pd") and the graphical interface ("GUI") 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 "set" 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 "blocked" 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'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 "on the stage" by users that are not "pd-ers", 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 "snapshots" of configuration that are then called (_not_ loaded from disk at the moment of calling them), so there often are "massive" 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 "engine" patch which does all the audio and midi stuff but has no GUI, and an "interface" 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 "protocol" of communication between the two patches is not even very optimized, so I send a lot of messages that could actually be avoided (don'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 "at the patch level" 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></font><br></blockquote></div><br>I'd just like to add that the same happens to MIDI with DSP off on a rather strong machine (Opteron 148 @ 2200).<br>
This is a very interesting thing that you brought up and i would very much like to hear the experts' opinions.<br><br>Andras<br>