And yet another question for the hive mind...
Array redrawing seems to be working sporadically for me under pd 0.38-2 (CVS stable_0_38 from last night) and pd .39. At first I thought it was just my patch, but then I was playing with Frank Barknecht's fantastic waveshaper patch and noticed that when I painted in an array the sound would indeed change, but the array display would not update. Opening the array would reveal the changes had been made, and when I closed it, the array redraws. Sometimes it still works, and I can't seem to pin down what makes it work and what doesn't.
There are lines and lines of this:
invalid command name ".x841a380.c"
being printed to the terminal.
Thanks for any thoughts.
-Ian
On Sat, Feb 12, 2005 at 01:06:54PM -0500, Ian Smith-Heisters wrote:
And yet another question for the hive mind...
Array redrawing seems to be working sporadically for me under pd 0.38-2 (CVS stable_0_38 from last night) and pd .39. At first I thought it was just my patch, but then I was playing with Frank Barknecht's fantastic waveshaper patch and noticed that when I painted in an array the sound would indeed change, but the array display would not update. Opening the array would reveal the changes had been made, and when I closed it, the array redraws. Sometimes it still works, and I can't seem to pin down what makes it work and what doesn't.
i get this too, with numboxes as well as arrays (curiously toxy objects dont seem to be affected, and numbox2 is safe) with heavy gui activity, like writing to a 512-pix spectrogram and/or updating a number of numboxes every 64 samples. are you creating heavy traffic?
most of these problems (dropped updates & Random crashes when moving or drawing things, plus array names not displaying) by switching to devel_0_38, so memory locking may be involved somwhow...
There are lines and lines of this:
invalid command name ".x841a380.c"
being printed to the terminal.
Thanks for any thoughts.
-Ian
-- Ian Smith-Heisters http://www.0x09.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Feb 12, 2005, at 1:20 PM, ix@replic.net wrote:
writing to a 512-pix spectrogram and/or updating a number of numboxes every 64 samples.
Is there any reason why you are trying to draw ~750 times a second?
Not only is Pd's graphic system woefully inadequate for doing that, but
it's also many, many times the display's refresh rate. You are doing
10x the work for 0 gain by trying to draw like that. If anything, Pd's
drawing should be hard throttled to about 20ms updates with no way to
preempt it.
cgc
On Sat, Feb 12, 2005 at 01:45:51PM -0600, chris clepper wrote:
On Feb 12, 2005, at 1:20 PM, ix@replic.net wrote:
writing to a 512-pix spectrogram and/or updating a number of numboxes every 64 samples.
Is there any reason why you are trying to draw ~750 times a second?
Not only is Pd's graphic system woefully inadequate for doing that, but it's also many, many times the display's refresh rate. You are doing 10x the work for 0 gain by trying to draw like that. If anything, Pd's drawing should be hard throttled to about 20ms updates with no way to preempt it.
well the spectrogram only updates 44100/512 times a second, and looks cool and generates 5% cpu load on winXP...so why not? i'd hve to have enforced throttling ((isnt that pretty antithetical)). but it seems there may be some throttling in place? for example loading wavs into my BLT wav editor takes FOREVER on windows...but on linux its quite fast...
cgc
ix@replic.net wrote:
i get this too, with numboxes as well as arrays (curiously toxy objects dont seem to be affected, and numbox2 is safe) with heavy gui activity, like writing to a 512-pix spectrogram and/or updating a number of numboxes every 64 samples. are you creating heavy traffic?
Yes, number atoms too, but not num2. The thing is that I'm not doing that much. Processor load is below 5%, I'm recording to an array and playing osc~, that's it. In exactly the same situation it works sometimes, sometimes no.
most of these problems (dropped updates & Random crashes when moving or drawing things, plus array names not displaying) by switching to devel_0_38, so memory locking may be involved somwhow...
devel_0_38 fixed it or caused it? I tried devel_0_38 but none of my externals would load even after rebuilding them, but that's some other issue. If devel_0_38 fixes it I'll try to figure that out.
When the redraw stops working the only way I've found to get it working again is to do a total reboot, so it seems like this may be related to something that's not getting reset or unloaded between Pd sessions.
best,
-
chris clepper -
Ian Smith-Heisters -
ix＠replic.net