Heh, responding to myself...
Uh, I checked it out and removed the submenu I mentioned and it works fine. Oddly enough. The subpatch contains 5 bangs, a symbol atom, a couple messages, and two makefilename instances. Why would this cause the array to not redraw??
I tried moving the subpatch out and back in to isolate the problem, I moved everything back in and it works fine still. I can't even repeat the error with the archive I sent.
So... just ignore this unless you've a fancy to become a ghost hunter.
Cheers, ian
Ian Smith-Heisters wrote:
Hi all,
I've got an array in a GOP abstraction that doesn't redraw, and I can't figure out why. At first it worked like a charm, but then it stopped working for no apparent reason. The only thing I changed was adding a subpatch (click "submenu" on the GOP in the attached example).
The attached tarball has the patch, it requires xrecord~ and xgroove~. Just open Lude.pd, turn on DSP, turn up the [osc~]'s freq, hit REC, and watch it not graph. If you open the GOP you can see that it draws fine once it refreshes. If you want to record a second time you need to hit "reset_rec".
The pertinent bits are all in the abstraction under [pd non_gui]->[pd rec_display] and perhaps [pd non_gui]->[pd set_defaults], where I set xrecord's draw property to 200.
Any thoughts? Is it xrecord? Or is it the array in GOP? If I can't have it redraw in realtime, how could I just force it to redraw (with a resize message?) without interrupting the DSP?
Thanks for any suggestions.
-Ian