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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
