you obviously would do the patching *before* you switch to freeze mode...
Yes, sorry I didn't specify. By patching everything before, nothing changes. The whole GUI of Pd freezes.
so far i think the data point is: if too much traffic is happening in Pd's receiver socket, it can stall the GUI updates. afaict, audio processing is not affected (is that correct?)
The audio processing is delayed, I measured up to a 5 second delay, but at a basic level (a simple phasor~) there seems to be no distortion or glitching at an audio processing level.
it might also be interesting to know whether the CPU is idling around or busy doing "things" when that problem happens (and how the CPU load is distributed on the cores).
Having a look at the CPU and the different load on the cores there seems to be no difference between before and after turning DSP on and off. When the GUI stops responding there is a significant drop in Pd's usage of CPU, from 35% down to 0,8%.
On 11 Apr 2017, at 13:23, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-04-11 14:16, Niccolò Granieri wrote:
Hi IOhannes, thanks a lot for your feedback.
I guess there is something else that I'm not taking into account. Because both on the test patch I sent over, and on the actual patch I'm working on with which I'm having issues, if I turn DSP on the whole patch freezes, until I turn audio off.
a simple hack is to send the numbers to the cold inlet of [f] and periodically ([metro 1000]) print out the values stored therein.
I tried, but being frozen it becomes impossible to even do anything with the incoming values.
you obviously would do the patching *before* you switch to freeze mode...
I am sure that a colleague of mine had the same issues running the latest pd on another Macbook Pro, 15" late 2011 running El Captain, and a Lenovo ThinkPad running a linux build.
If that could be of any use I can try and find out more precise specs.
that would certainly not be a bad idea (though i don't know how to make use of the data *right now*).
debugging socket issues is mostly a tricky business. debugging socket issues on machines without access to, is almost impossible.
so far i think the data point is: if too much traffic is happening in Pd's receiver socket, it can stall the GUI updates. afaict, audio processing is not affected (is that correct?)
it might also be interesting to know whether the CPU is idling around or busy doing "things" when that problem happens (and how the CPU load is distributed on the cores).
fgasdrk IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev