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 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