GEM, PDP, GridFlow, all use fake pointers. That is, pd defines A_POINTER as being a t_gpointer * and all of the above externals disregard this completely and send something else. It's because pd provides no other sensible means to send a pointer.
Older versions of GridFlow were sending a pointer as 2 floats of integer value, and I was going to make it 3 floats when beginning to support 64-bit, but thought that although misusing A_POINTER was more evil in my book, at least it's being done with passing only one atom around, and I'm also happy to be doing the same evil as everybody else too.
(I could have tried a plain reinterpret_cast<> so that it'd be 1 float in 32-bit or 2 floats in 64-bit, but I didn't want to think of the special float values such as +0, -0, +inf, -inf, NaN, denormals, and anything else. It could've been fine, but I didn't want to have to think about it.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hi, I think a t_pointer * is a must in a mature dataflow software. Let's face it : it is sometimes necessary.
a
2007/6/23, Mathieu Bouchard matju@artengine.ca:
GEM, PDP, GridFlow, all use fake pointers. That is, pd defines A_POINTER as being a t_gpointer * and all of the above externals disregard this completely and send something else. It's because pd provides no other sensible means to send a pointer.
Older versions of GridFlow were sending a pointer as 2 floats of integer value, and I was going to make it 3 floats when beginning to support 64-bit, but thought that although misusing A_POINTER was more evil in my book, at least it's being done with passing only one atom around, and I'm also happy to be doing the same evil as everybody else too.
(I could have tried a plain reinterpret_cast<> so that it'd be 1 float in 32-bit or 2 floats in 64-bit, but I didn't want to think of the special float values such as +0, -0, +inf, -inf, NaN, denormals, and anything else. It could've been fine, but I didn't want to have to think about it.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Thu, 28 Jun 2007, Alexandre Quessy wrote:
I think a t_pointer * is a must in a mature dataflow software. Let's face it : it is sometimes necessary.
You seem to like to face things. Now face this: pd-dev is not the right place for discussing pd development issues!
I made the same request (actually, a better one, involving custom atom types) for Pd 0.35 (in August 2002 on pd-list) and the response has been close to none. I reiterated in 0.38 times (during 2005) when I got Miller on IRC and basically from that point I knew that it wouldn't be possible through Miller.
(I will tell you more about this when we get to see each other next week.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
I was wondering if you could clarify for me what types of data structures you are pointing to, because I could think of an application that this would solve.
For a while now, I was wondering how to include a wave packets transform in pd. The wave++ library has a wave packets transform, where the structure of the transform is provided as a tree, and the tree is a class. Could we make an external that does the wave packets transform and stores the tree, then passes a pointer to the tree to the next stage in processing. (I'm not suggesting to do this any time soon, I just thought of an example) Do you do similar things in GridFlow? What kinds of pointers do you think are necessary to handle?
Chuck
On 6/23/07, Mathieu Bouchard matju@artengine.ca wrote:
GEM, PDP, GridFlow, all use fake pointers. That is, pd defines A_POINTER as being a t_gpointer * and all of the above externals disregard this completely and send something else. It's because pd provides no other sensible means to send a pointer.
Older versions of GridFlow were sending a pointer as 2 floats of integer value, and I was going to make it 3 floats when beginning to support 64-bit, but thought that although misusing A_POINTER was more evil in my book, at least it's being done with passing only one atom around, and I'm also happy to be doing the same evil as everybody else too.
(I could have tried a plain reinterpret_cast<> so that it'd be 1 float in 32-bit or 2 floats in 64-bit, but I didn't want to think of the special float values such as +0, -0, +inf, -inf, NaN, denormals, and anything else. It could've been fine, but I didn't want to have to think about it.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Sat, 7 Jul 2007, Charles Henry wrote:
I was wondering if you could clarify for me what types of data structures you are pointing to, because I could think of an application that this would solve.
In modern GridFlow, "grid" messages (the only special messages in GridFlow) contain one single fake pointer which is always pointing to a GridOutlet structure. When an object receives that, it calls ->callback(x) on the structure, where x has to be a GridInlet*. This subscribes the GridInlet to the streaming that will be performed by the GridOutlet as soon as the message handler returns.
As of now, this is always ever done by grid.c, so actual grid-handling pd classes named like [#whatever] never know about this and it could actually change from version to version (and it did). When patching, you are not allowed to assume anything about the contents of the grid message.
For a while now, I was wondering how to include a wave packets transform in pd. The wave++ library has a wave packets transform, where the structure of the transform is provided as a tree, and the tree is a class.
We've had an experimental datatype in LTI (a C++ library wrapped by GridFlow) for pointing to special (non-gridoutlet) structs like that but it's not like we're so proud of it.
Btw, if that's a balanced tree, it's rather easy to flatten it into an array in a predictable way. You've thought about that? (Are you talking about wavelets?)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On 7/8/07, Mathieu Bouchard matju@artengine.ca wrote:
On Sat, 7 Jul 2007, Charles Henry wrote:
I was wondering if you could clarify for me what types of data structures you are pointing to, because I could think of an application that this would solve.
In modern GridFlow, "grid" messages (the only special messages in GridFlow) contain one single fake pointer which is always pointing to a GridOutlet structure. When an object receives that, it calls ->callback(x) on the structure, where x has to be a GridInlet*. This subscribes the GridInlet to the streaming that will be performed by the GridOutlet as soon as the message handler returns.
I think I understand now. You pass pointers to structures. That makes a lot of sense.
As of now, this is always ever done by grid.c, so actual grid-handling pd classes named like [#whatever] never know about this and it could actually change from version to version (and it did). When patching, you are not allowed to assume anything about the contents of the grid message.
For a while now, I was wondering how to include a wave packets transform in pd. The wave++ library has a wave packets transform, where the structure of the transform is provided as a tree, and the tree is a class.
We've had an experimental datatype in LTI (a C++ library wrapped by GridFlow) for pointing to special (non-gridoutlet) structs like that but it's not like we're so proud of it.
Btw, if that's a balanced tree, it's rather easy to flatten it into an array in a predictable way. You've thought about that? (Are you talking about wavelets?)
The wave packets transform is a wavelet transform, in which each of the branches with greater than 1 point can be expaned in the same manner. The big idea of using one is to do a best basis search, which depends on the signal characteristics. So, the best basis can be drastically different from one signal to another. I am sure there is a way to flatten the tree into an array, with various extra parameters that tell you how to traverse the tree as moving to different indexes of the array. You're certainly correct. I really hadn't thought of that before. The existing wave++ library has functions on classes. So to flatten the tree for passing, only to be un-flattened afterwards is less efficient than to pass a pointer to the tree.
But really..... it's a pretty impractical example there would be little need to have these specialized structures as externals, to be passed to other externals. A series of objects that perform some kind of wave packets analysis/processing would only be compatible with each other. If you wanted to do some kind of processing on the packets, you would have to write another external for it, just to decode the structure anyway. It's really just a curiosity (as far as I can tell) Thanks for describing to me how you pass "fake" pointers :)
Chuck
On Sun, 8 Jul 2007, Charles Henry wrote:
I think I understand now. You pass pointers to structures. That makes a lot of sense.
Actually, GridFlow's struct GridOutlet it's more like a C++ object class, which isn't much different from a C struct, especially as that class doesn't have any virtuals in it. (It has method templates though)
So to flatten the tree for passing, only to be un-flattened afterwards is less efficient than to pass a pointer to the tree.
Yeah, that was what happened when we were wrapping LTI (Aachen university's image library). We were ok to do it for cases where it was merely slowing down because then it allowed better integration with existing GridFlow features, but were thinking about on-demand conversion to get the best of both worlds (speed and flexibility) and then for at least one case, the data wasn't really amenable to be processed by GridFlow, so we left it as in and used pointers to non-Grids (I'm not going to tell you how we did it, because you shouldn't be imitating that solution! it's even crazier)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Alexandre Quessy -
Charles Henry -
Mathieu Bouchard