[PD] videoPYLON C++ update needed

Csaba Láng langcsaba at gmail.com
Mon Sep 3 21:50:55 CEST 2018


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 <langcsaba at 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 <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/20180903/d1c440f7/attachment.html>


More information about the Pd-list mailing list