Hi list, I'm looking for an example interface that I cannot find atm-- how to accumulate an arbitrary-length list and output it from a Pd object written in C. I can think of several ways to do it but if there's already something that exists I'd rather just hook into that.
I want to add a few messages to [canvasinfo] to return a list of matching object indices on the canvas. So I need to be able to iterate through all the objects in the canvas, add them to a list if they match, then output that list.
Any externals out there that would contain a decent model for doing this? I looked at the code for [list append] but that only glues together two lists, where I may be adding a large number of float atoms for a single output.
Thanks, Jonathan
slipdec accumulates floats until end of packet then outputs the list: http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/sli...
Martin
On 2014-06-05 14:11, Jonathan Wilkes via Pd-list wrote:
Hi list, I'm looking for an example interface that I cannot find atm-- how to accumulate an arbitrary-length list and output it from a Pd object written in C. I can think of several ways to do it but if there's already something that exists I'd rather just hook into that.
I want to add a few messages to [canvasinfo] to return a list of matching object indices on the canvas. So I need to be able to iterate through all the objects in the canvas, add them to a list if they match, then output that list.
Any externals out there that would contain a decent model for doing this? I looked at the code for [list append] but that only glues together two lists, where I may be adding a large number of float atoms for a single output.
Thanks, Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-l2ork also has [list cat]
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@mail.iem.at] On Behalf Of Martin Peach via Pd-list Sent: Thursday, June 05, 2014 2:18 PM To: Jonathan Wilkes; pd-list@lists.iem.at Subject: Re: [PD] outputting arbitrary size list
slipdec accumulates floats until end of packet then outputs the list: http://sourceforge.net/p/pure- data/svn/HEAD/tree/trunk/externals/mrpeach/slipdec/
Martin
On 2014-06-05 14:11, Jonathan Wilkes via Pd-list wrote:
Hi list, I'm looking for an example interface that I cannot find atm-- how to accumulate an arbitrary-length list and output it from a Pd object written in C. I can think of several ways to do it but if there's already something that exists I'd rather just hook into that.
I want to add a few messages to [canvasinfo] to return a list of matching object indices on the canvas. So I need to be able to iterate through all the objects in the canvas, add them to a list if they match, then output that list.
Any externals out there that would contain a decent model for doing this? I looked at the code for [list append] but that only glues together two lists, where I may be adding a large number of float atoms for a single output.
Thanks, Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
-Jonathan
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
-
Ivica Ico Bukvic via Pd-list -
Jonathan Wilkes via Pd-list
-
Martin Peach via Pd-list