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
