IOhannes m zmoelnig a écrit :
Patrice Colet wrote:
Hi, there is certainly an error in this source file:
http://pd-gem.cvs.sourceforge.net/*checkout*/pd-gem/Gem/src/openGL/GEMglMap1...
t_atom*argv should be 't_atom *argv'
i don't know of any compiler that parses "t_atom*argv" differently as "t_atom *argv" or "t_atom* argv". in this case, the space is really redundant characger.
did you have any problems with it?
fgmasd.r IOhannes
In fact this object crashes PureData (win32) when we submit a number at the last input, so I've watched the source just to see what kind of data do I have to submit. Matju already told me in #dataflow that this missing space doesn't even cause a warning, so I've no clue about what's happening with this function. I wanted to construct control bezier curves, following this tutorial:
http://glprogramming.com/red/chapter12.html
Apparently this was a bad idea.
Patrice Colet a écrit :
IOhannes m zmoelnig a écrit :
Patrice Colet wrote:
Hi, there is certainly an error in this source file:
http://pd-gem.cvs.sourceforge.net/*checkout*/pd-gem/Gem/src/openGL/GEMglMap1...
t_atom*argv should be 't_atom *argv'
i don't know of any compiler that parses "t_atom*argv" differently as "t_atom *argv" or "t_atom* argv". in this case, the space is really redundant characger.
did you have any problems with it?
fgmasd.r IOhannes
In fact this object crashes PureData (win32) when we submit a number at the last input, so I've watched the source just to see what kind of data do I have to submit. Matju already told me in #dataflow that this missing space doesn't even cause a warning, so I've no clue about what's happening with this function. I wanted to construct control bezier curves, following this tutorial:
why don't you use the curve / curve3d object?
cyrille
Apparently this was a bad idea.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Patrice Colet wrote:
IOhannes m zmoelnig a écrit :
Patrice Colet wrote:
Hi, there is certainly an error in this source file:
http://pd-gem.cvs.sourceforge.net/*checkout*/pd-gem/Gem/src/openGL/GEMglMap1...
t_atom*argv should be 't_atom *argv'
i don't know of any compiler that parses "t_atom*argv" differently as "t_atom *argv" or "t_atom* argv". in this case, the space is really redundant characger.
did you have any problems with it?
fgmasd.r IOhannes
In fact this object crashes PureData (win32) when we submit a number at the last input, so I've watched the source just to see what kind of data do I have to submit. Matju already told me in #dataflow that this missing space doesn't even cause a warning, so I've no clue about what's happening with this function.
usually, a debugger reveals more....
I wanted to construct control bezier curves, following this tutorial:
http://glprogramming.com/red/chapter12.html
Apparently this was a bad idea.
no it is a great idea.
the problem turned out to be a stupidity in the script that write all the openGL-objects and which dealt badly with lists.
it is fixed now in CVS
gamsdr. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You probably have to give more than one number at the right inlet. The number of control points has to be equal or less to the 'order' value. The parameters are very specific for setting memory accesses by the driver and some drivers are not good at doing sanity checks. This is probably a very tricky object to get working using GL wrappers.
On Jan 21, 2008 8:12 AM, Patrice Colet pat@mamalala.org wrote:
In fact this object crashes PureData (win32) when we submit a number at the last input, so I've watched the source just to see what kind of data do I have to submit. Matju already told me in #dataflow that this missing space doesn't even cause a warning, so I've no clue about what's happening with this function. I wanted to construct control bezier curves, following this tutorial:
http://glprogramming.com/red/chapter12.html
Apparently this was a bad idea.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
chris clepper wrote:
You probably have to give more than one number at the right inlet. The number of control points has to be equal or less to the 'order' value.
The parameters are very specific for setting memory accesses by the driver and some drivers are not good at doing sanity checks. This is probably a very tricky object to get working using GL wrappers.
the problem was really on the pd-side of the object: the list-callback was expecting (void*, int argc, t_atom*argv) instead of (void*, t_symbol*s, int argc, t_atom*argv) this makes a huge difference when receiving lists :-)
the really tricky objects in the GEM-wrapper are those that expect more complex data than just (small) arrays of floats. e.g. textures,... nobody has taken care of them yet :-) (i will eventually do so, when somebody comes up with: "[GEMglDrawPixels] crashes...")
gmasdr. IOhannes
-
chris clepper -
cyrille henry -
IOhannes m zmoelnig -
Patrice Colet