Hi,
it would be cool if the various operations of list-abs could also be made to work with pointers. However one important construct doesn't work and sometimes even lets Pd crash): extending a list with a pointer element using [list append]X[pointer]
Attached patch illustrates what I mean: The example on the bottom right doesn't work correctly. I wonder: is this even supposed to work?
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi,
See attached abstractions for a desperate (but working) way to store and recall lists of pointers ... Nevertheless, making this possible in a standard manner would be far more convincing ...
Cheers
Pierre Cage
2007/3/1, Frank Barknecht fbar@footils.org:
Hi,
it would be cool if the various operations of list-abs could also be made to work with pointers. However one important construct doesn't work and sometimes even lets Pd crash): extending a list with a pointer element using [list append]X[pointer]
Attached patch illustrates what I mean: The example on the bottom right doesn't work correctly. I wonder: is this even supposed to work?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, pierre cage hat gesagt: // pierre cage wrote:
See attached abstractions for a desperate (but working) way to store and recall lists of pointers ... Nevertheless, making this possible in a standard manner would be far more convincing ...
Very nice package. I think, I was using a similar approach in my xy-controller to speed up pointer access, but having the idiom in a set of readymade abstractions is very useful.
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, pierre cage hat gesagt: // pierre cage wrote:
See attached abstractions for a desperate (but working) way to store and recall lists of pointers ... Nevertheless, making this possible in a standard manner would be far more convincing ...
I made some changes to your patches, mostly cosmetic (aligning patch cords etc.), but one change is a bit more intrusive: I like to start counting at 0, because that makes modulo-counting a bit easier, so I changed the patches to start that way. I also reduced the number of send/receive names used, added a little functional example to the help-patch and removed the loadbang-clearing in add-tag-pointer.pd, because I'd rather do this by hand, and "next" now takes off where the last index number was sent.
Anyway, this is very useful for my current project....
Frank Barknecht _ ______footils.org_ __goto10.org__
Glad to know these can serve other data-structure enthusiasts ...
Cheers,
Pierre Cage
2007/3/2, Frank Barknecht fbar@footils.org:
Hallo, pierre cage hat gesagt: // pierre cage wrote:
See attached abstractions for a desperate (but working) way to store and recall lists of pointers ... Nevertheless, making this possible in a standard manner would be far more convincing ...
I made some changes to your patches, mostly cosmetic (aligning patch cords etc.), but one change is a bit more intrusive: I like to start counting at 0, because that makes modulo-counting a bit easier, so I changed the patches to start that way. I also reduced the number of send/receive names used, added a little functional example to the help-patch and removed the loadbang-clearing in add-tag-pointer.pd, because I'd rather do this by hand, and "next" now takes off where the last index number was sent.
Anyway, this is very useful for my current project....
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hmm, I think I should fix this... it adds an ugly layer of complication to the list object but I think it would be inconsistent simply to refuse to handle them. And yes, it's a bug that they currently just get passed through without making the necessary consistency checks.
cheers Miller
On Thu, Mar 01, 2007 at 07:50:48PM +0100, Frank Barknecht wrote:
Hi,
it would be cool if the various operations of list-abs could also be made to work with pointers. However one important construct doesn't work and sometimes even lets Pd crash): extending a list with a pointer element using [list append]X[pointer]
Attached patch illustrates what I mean: The example on the bottom right doesn't work correctly. I wonder: is this even supposed to work?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK... looks like [list append] does deal with pointers almost correctly (I forgot I had done that), but there is a bug when you send a new list to its inlet re-entrantly. I'll fix this for 0.41 but in the meantime you can work around it by forcing a copy of the outgoing message (send a list to "t b l" connected to the two inlets of "list append" to make a copy of the list)...
cheers Miller
On Thu, Mar 01, 2007 at 07:50:48PM +0100, Frank Barknecht wrote:
Hi,
it would be cool if the various operations of list-abs could also be made to work with pointers. However one important construct doesn't work and sometimes even lets Pd crash): extending a list with a pointer element using [list append]X[pointer]
Attached patch illustrates what I mean: The example on the bottom right doesn't work correctly. I wonder: is this even supposed to work?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
OK... looks like [list append] does deal with pointers almost correctly (I forgot I had done that), but there is a bug when you send a new list to its inlet re-entrantly. I'll fix this for 0.41 but in the meantime you can work around it by forcing a copy of the outgoing message (send a list to "t b l" connected to the two inlets of "list append" to make a copy of the list)...
Ah, this seems to work. I still get "consistency check failed: gpointer_copy" messages however using Pd from current CVS. But it's nice to see this in action generally.
Frank Barknecht _ ______footils.org_ __goto10.org__
On Tue, Mar 06, 2007 at 10:00:37PM +0100, Frank Barknecht wrote:
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
OK... looks like [list append] does deal with pointers almost correctly (I forgot I had done that), but there is a bug when you send a new list to its inlet re-entrantly. I'll fix this for 0.41 but in the meantime you can work around it by forcing a copy of the outgoing message (send a list to "t b l" connected to the two inlets of "list append" to make a copy of the list)...
Ah, this seems to work. I still get "consistency check failed: gpointer_copy" messages however using Pd from current CVS. But it's nice to see this in action generally.
Shot in the dark; so does this mean we can store GEM pointers in lists too? That would be neat because then you could make a non-zexy abstraction-only [repeat] object.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
Hi all, gpointers are used (de facto) to store pointers by many externals and library. Would it be more stable to provide a standard data type for pointers like gemchains, #grids and such ? I doubt, but it would be more consistent.
BTW Chris, you can also use iem_anything to store and repeat *gem lists.
Cheers,
a
2007/3/6, Chris McCormick chris@mccormick.cx:
On Tue, Mar 06, 2007 at 10:00:37PM +0100, Frank Barknecht wrote:
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
OK... looks like [list append] does deal with pointers almost correctly (I forgot I had done that), but there is a bug when you send a new list to its inlet re-entrantly. I'll fix this for 0.41 but in the meantime you can work around it by forcing a copy of the outgoing message (send a list to "t b l" connected to the two inlets of "list append" to make a copy of the list)...
Ah, this seems to work. I still get "consistency check failed: gpointer_copy" messages however using Pd from current CVS. But it's nice to see this in action generally.
Shot in the dark; so does this mean we can store GEM pointers in lists too? That would be neat because then you could make a non-zexy abstraction-only [repeat] object.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, Mar 11, 2007 at 10:24:23PM -0400, Alexandre Quessy wrote:
BTW Chris, you can also use iem_anything to store and repeat *gem lists.
Sure, but that defeats the purpose of making an external-free [repeat].
Best
Chris.
chris@mccormick.cx http://mccormick.cx