Does anyone know whether Pd's Midi runs in the same thread as the GUI?

I have managed to get Plogue Bidule synced to a midi clock sent from Pd over the IAC bus (OSx), but when say a window is moved, there is loads of glitching in the audio and the jitter seems to increase enormously. I have tried wacking up the buffer sizes but of course, the increased latency means that Bidule is synced by the order of the buffer size...Or worse if theres jitter involved. ITs not really practical to not touch the computer whilst it is running!

How can this be remedied? Is some kind of latency compensation required here

I totally long for the day when Jack OSX gets midi then we can have rewire like performance but with all the benefits that Jack currently provides! (does anyone have a clue when this might be?)

cheers

Hi boonier,

afaik the GUI and the engine share no threading, they are quite separate applications and you
can run Pd completely without a GUI. I think the problems are coming from an overall system
resource scrap, the GUI is notoriously aggressive at times. If you have normally good
latency and buffering when the GUI isn't active then there's not much to do.

The best approach in my own experience is to give fewer resources to the GUI, using nice -10
in Linux or OSX. If you tweak the performance of your window manager it often helps too. Beyond
that I'm afraid you're running up against the limit of the machine and it's time to get more GHz.

Desire data is an alternative interface you might care to test out, and there is the option of building
a custom python GUI for your performance rig and not actually running the normal Pd GUI live.

best,

Andy

Why exactly do the GUI elements eat up so much juice? Surely they aren't too good looking for the computer to handle efficiently?

Good question, it's certainly not resource heavy. Perhaps it is because the GUI is written in tcl/Wish which is an interpreted shell language for Tk, definitely not as fast as a compiled GUI.