On Mon, Apr 5, 2010 at 8:43 PM, Matteo Sisti Sette < matteosistise...@gmail.com> wrote:
> (this is a little OT respect to the thread) > > > nicely enough, pd's graphical interface and the actual process, > > are separate threads, > > 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. > > 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. > > Not quite so. > 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. > > 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. > > 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. > > 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). > Well with this system, despite the huge quantity of messages to and from > GUI, I get no dropouts at all, everything works fine. > > 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). > 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. > > 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...... > > -- > Matteo Sisti Sette > matteosistise...@gmail.com > http://www.matteosistisette.com > I'd just like to add that the same happens to MIDI with DSP off on a rather strong machine (Opteron 148 @ 2200). This is a very interesting thing that you brought up and i would very much like to hear the experts' opinions. Andras
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list