[PD] Gem crash: Why?

cyrille cyrille.henry at la-kitchen.fr
Tue Apr 26 00:33:35 CEST 2005


Frank Barknecht a écrit :
> Hallo,
> 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 
>>something else...?
> 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
> ups]. 

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.

> Ciao

More information about the Pd-list mailing list