[PD] Gem crash: Why?
cyrille.henry at la-kitchen.fr
Tue Apr 26 00:33:35 CEST 2005
Frank Barknecht a écrit :
> james tittle hat gesagt: // james tittle wrote:
>>...can't wait for katamari 2, I bet :-) I'm wasting time with a neat
>>psp...oh yeah: the question...
> Grr, can't afford a PSP currently... ;)
>>>could anybody maybe test attached patch? It leads to a segfault on my
>>>machine and I'd like to find out, why or ow to work around this. [any]
>>>from IEM is required.
>>...oddly enuff, it's not crashing for me on osx, at least when run in
>>gdb (haven't tried a normal run)...looking at it, I'm not really sure
>>what you want to do (outside of have randomly xy-placed colored
>>squares)? Are you trying to put 500 squares on screen per frame? Or
> It's just a test patch stripped to the bones, nothing really useful.
> Basically I'm trying to understand how [seperator] works for creating
> lots of objects of the same kind using just lists as input. I got this
> idea from the example patches in CVS at externals/numsk/msd2D etc.
> There Nicolas Montgermont is using a similar approach. However he is
> actually not using a metro, but [gemhead] to drive the gemchain in [pd
yes, and i think it's the main difference that make your patch also
crashing on my computer.
i first experiment this technic for the L-system generation. using the
gemhead for the list generation look logic to sincronise the list
generation to the openGL rendering.
using an external metro looks strange : it allow you to try drawing
primitives out of gem timing.
your patch works perfectly if you replace the metro with a gemhead...
hope that help.
More information about the Pd-list