On 2014-06-06 15:53, Jonathan Wilkes via Pd-list wrote:
Martin, Thanks for the link. It looks like you are setting a default size which can be overridden by an argument from the user. But for what I want, the user needs to be shielded completely from that implementation detail.
For example, let's say I make a method where the user queries the objects contained within a bounding box (though I haven't implemented it yet):
[selection 0 0 500 500( | [canvasinfo] | [print] <-arbitrary length list of object indices for objects contained within the bbox (0 0 500 500)
I don't know ahead of time how many objects may be in the canvas, so I have no way to judge what the size of the list should be. I could just set a default size of 500 or 1000 and reallocate as necessary, but that gets kind of ugly.
Well you probably won't have millions of objects in a patch and memory is cheap. It's a tradeoff between wasting memory and wasting time. In my experience, reallocating memory can sometimes take a long time, causing glitches in the audio and other undesirable effects. A compromise would be to allocate say 65kB by default and then add that much each time the list overflows. Then you have to release the unused memory after a while. But definitely, allocating one atom at a time is going to slow Pd right down and maybe even crash it. You could also load the patch the object is instantiated into and count the number of objects in the .pd file and use that as the maximum, but of course that doesn't work if it hasn't been saved yet. Also the number of pixels in the selection rectangle will be more than the number of objects by some ratio unless you're recursively counting subpatches as well.
Martin
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list