Iohannes, did you have a chance to check where my memory corruption is coming from?
Popesz On Sat, Sep 1, 2018 at 11:34 AM Csaba Láng <langcs...@gmail.com> wrote: > Iohannes, > I am not sure if understood you well, did you mean that even I have a good > graphic card with my patch I am unable to exceed 60 fps? > Or you meant a [metro 5] to [gemhead] to achieve 200fps and analyzing the > center of gravity with pix_blob could do the job. > Popesz > > On Sat, 1 Sep 2018 at 01:02, IOhannes m zmölnig <zmoel...@iem.at> wrote: > >> On 8/31/18 2:42 PM, Csaba Láng wrote: >> > Just in case I send you a new Segmentation Fault log. >> > Here I have already no method for Gemstate. >> > I send you the patches to have a better idea what I am trying to do. >> > trackerping.pd is the main patch, containing filecontrol. >> > after gemwin is rendered, open languagechoice.pd >> > there are 2 cameras placed in the main window sending to the pd ping1 >> and >> > pd ping2 to languagechoice. >> > >> > Basically the 2 cameras are creating one touch surface by placing them >> one >> > above the wall facing down, the other one facing to the wall. When >> camera1 >> > gets the wall hit tells the event to camera 2 which gets the position x >> y >> >> to avoid confusion, it's probably better to reserve the term "camera" >> for the physical device. >> >> > from pix_blob. Now when the 2 cameras send to each other info about the >> > presence of an object, I get the segmentation fault. >> >> so the crash appears when you you send something to [r ball] (which in >> turn triggers a [s english] resp [s polski]; which in turn triggers the >> patch-open and patch-close). >> >> i'm pretty sure that dynamically opening and closing patches is a bad >> idea. >> what's wrong with just using [spigot] to let the gemlist through or not? >> >> >> apart from that, it's crashing because of an illegal memory access in a >> [bng] object (that is: a graphical bang). >> this is either an initialization problem or some memory corruption. >> >> anyhow, parts of the patch are missing, (the dynamically loaded >> patches), and i don't know where [once] is coming from. >> >> i have a slight suspicion that you are running yet another [pix_blob] in >> your dynamically loaded patches, which you probably don't need (you >> already have a [pix_blob] on all your video sources), no? >> >> oh, and your cameras might already support setting gain and contrast and >> cropping the image. if so, you might want to do these things on the >> camera rather than within Gem. >> >> >> as for the framerate: even if you run your cams at 1000fps, Gem will run >> at it's own fixed framerate (which is 20fps by default, and i don't see >> where you've changed that). Gem's framerate is usually bound by the >> gfx-card (so often you cannot really go beyond 60fps). >> however, if you don't do any openGL rendering (most Gem-objects will do >> openGL, with the big exception of the pix_* family - apart from >> pix_texture, which does openGL), then you can have a single [gemhead] >> run at a higher rate by simply banging it to a [metro] running at that >> rate. >> >> >> gmads >> IOhannes >> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list