[PD] videoPYLON C++ update needed

[Csaba Láng]

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 <zmoelnig at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180901/cbd06c4f/attachment-0001.html>