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