Re: [PD-dev] pix_multiblob mem leak
Attached patch reproduces problem, reading video from file. On Sat, Mar 13, 2010 at 10:07 AM, Gerrie Roos gerrier...@gmail.com wrote: Hi! It looks like pix_multiblob is leaking about 4kB/frame/blob. Anybody else seen this? I'm in a bit of a tight spot. I've got an installation coming up on 18 March and my extensive pd patch is now running out of memory every couple of hours. Would love to check out the source code and try fix it myself but since I've never done any pd dev it will put me back a couple of days (at the least). I'll buy you beer! Windows XP SP2 Pd version 0.41.4-extended Gerrie memleak.pd Description: Binary data ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] GUI performance clarification
Hallo, Lee Azzarello hat gesagt: // Lee Azzarello wrote: Hot on the heels of the great GUI rewrite thread, I have a simple question that would help clarify some CPU performance questions I have with my current project. I have incoming serial data from an arduino. This data is getting buffered every n milliseconds and sent to a vslider object. I have 6 channels of data with a vslider on each, so 6 vsliders and 6 buffers. If I set n to 20ms, my dual core 2.4 ghz CPU with an i945 graphics card on Linux 2.6.32 hits 100% with no audio processing. If I lower n to 60ms the CPU usage drops to about 15%. Is this the expected performance for a vslider? About yes. You can't see faster than about 50msec anyway, so I don't think it makes much sense to update a slider any faster. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] worth to create external?
Lorenzo wrote: Hi list, I'm already on the pd-list. I signed up to the pd-dev as I'm starting to look into some (simple) external development. cool. please note that pd-dev has the same netiquette as pd-list, that e.g. asks you to not hijack another thread for your unrelated postings. see http://puredata.info/community/lists/Netiquette#Threads First, though, I thought it would be wise to ask when is it really worth to write an external vs using directly pd abstractions considering the various c/b? Is this in some way 'measurable'? yes. relate the time spent writing one solution (including learning to actually do it plus doing big-fixes) to its relevant benefits (does it work? what's the performance? is it portable? ...) and compare the scalars you get for the various solutions :-) fgmadr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pix_multiblob mem leak
Gerrie Roos wrote: Hi! It looks like pix_multiblob is leaking about 4kB/frame/blob. Anybody else seen this? I'm in a bit of a tight spot. I've got an installation coming up on 18 March and my extensive pd patch is now running out of memory every couple of hours. Would love to check out the source code and try fix it myself but since I've never done any pd dev it will put me back a couple of days (at the least). I'll buy you beer! Windows XP SP2 Pd version 0.41.4-extended what Gem version is this? does the problem exist with the latest and greatest Gem (0.92.2)? (if not, i claim the beer :-)) thanks for sending an example patch; it's pretty generic, and i do not see any memleak occuring here (using the alea.mpg example film). however, the bug might be related to the number of blobs found and the image format, neither of which i can reproduce; could you put the clock.avi online somewhere so i can download it? or: how does your patch behave with homer.avi? fmadrs IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] videogrid + pd-extended 0.42.5
lluis gomez i bigorda wrote: hi all, yes, we say here esoteric bug cause we cannot understand at all why if Gem is linked against libavifile it beaks our ffmpeg code. videogrid is not linked against libavifile !!! that's crazy? or not? not necessarily, since most of those video decoding backends like ffmpeg, libavifile, gmerlin, quicktime4linux are plugin based and use each other as backends. so the interrelations between all those are somewhat messy... and more, if we load videogrid before Gem the crash desapears. why the lib load order can change behaviors of a library in that way? maybe some namespace conflict? yes. i guess that libavifile comes with an ffmpeg-plugin which will be initialized on loading and which (due to the way ffmpeg is not released) conflicts with the ffmpeg version installed on the computer. anyone can put a bit of light on this please? we are just belivers of almighty pd wisdom. you know ... :) a similar problem occured with libstdc++ and ati/radeon drivers a while ago. i don't think there is a generic solution for such problems (hmm, on w32 you have to bundle your library with all it's dependencies; maybe this is the solution;; maybe not) gfmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pix_multiblob mem leak
Hi, tnx for the reply! I started with Pd extented 0.41.4 (that's using Gem 0.91 I think) then I installed a file marked as gem-0.92.2-W32-i686.exe (fresh from http://gem.iem.at/) but if I look at the release notes in there it looks like 0.91 as well, but the .dll is a different size, so I assume the release notes are not up-to-date and I'm running 0.92.2. Pd also prints out 0.92.2 when it starts up. Sorry, no beer yet... Clock.avi comes standard with Windows XP at least. Here's a copy: http://www.sendspace.com/file/smz01u Can't load alea.mpg with pix_film...just get an 'unable to open file...error. Weird. Tried homer.avi, also leaks 8( Originally found the problem using my usb webcam and played around with the number of blobs quite a lot. It always leaks when blobs are detected. Probably not the webcam since it leaks with clock.avi and homer.avi as well. 2010/3/14 IOhannes zmölnig zmoel...@iem.at: Gerrie Roos wrote: Hi! It looks like pix_multiblob is leaking about 4kB/frame/blob. Anybody else seen this? I'm in a bit of a tight spot. I've got an installation coming up on 18 March and my extensive pd patch is now running out of memory every couple of hours. Would love to check out the source code and try fix it myself but since I've never done any pd dev it will put me back a couple of days (at the least). I'll buy you beer! Windows XP SP2 Pd version 0.41.4-extended what Gem version is this? does the problem exist with the latest and greatest Gem (0.92.2)? (if not, i claim the beer :-)) thanks for sending an example patch; it's pretty generic, and i do not see any memleak occuring here (using the alea.mpg example film). however, the bug might be related to the number of blobs found and the image format, neither of which i can reproduce; could you put the clock.avi online somewhere so i can download it? or: how does your patch behave with homer.avi? fmadrs IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-2970336 ] pix_coloralpha and pix_alpha on OSX Intel
Bugs item #2970336, was opened at 2010-03-14 18:29 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=2970336group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: v0.41 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Hans-Christoph Steiner (eighthave) Summary: pix_coloralpha and pix_alpha on OSX Intel Initial Comment: pix_coloralpha and pix_alpha don't work correctly (they do something but don't work as they do on Powerpc) under OSX Intel (on all extended 0.41+ versions) when used with RGBA pix_film. See attached zip. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=2970336group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-2950978 ] iemlib/[soundfile_info]: does not load certain wav files
Hi I would like to know, how likely it is that this bug is going to be fixed in the next couple of weeks. Please do *not* understand this as a request and certainly not as a demand to fix it. Having this piece of information helps to define a strategy of what audio software can be used in an upcoming project with with students - a project that also involves Pd. Any feedback (such as 'the maintainer of this object is not on this list') might be helpful. Thanks Roman On Sat, 2010-02-13 at 01:09 +, SourceForge.net wrote: [...] https://sourceforge.net/tracker/?func=detailatid=478070aid=2950978group_id=55736 [...] Initial Comment: an example file showing described behaviour can be downloaded here: http://www.romanhaefeli.net/test8kanal_interleaved_www.wav when loading such a file with [soundfile_info], it prints the following error: soundfile_info_read-error: /home/roman/projekte/liestal/soundfiles/test8kanal_interleaved_www.wav has a format-chunk not equal to 16 this and other files generated with the nuendo software have this problem. the files though seem to be compliant wav-files. [readsf~] loads and plays them fine. 'mplayer -identify test8kanal_interleaved_www.wav' prints: Opening audio decoder: [pcm] Uncompressed PCM audio decoder AUDIO: 44100 Hz, 8 ch, s16le, 5644.8 kbit/100.00% (ratio: 705600-705600) Only [soundfile_info] seems to have troubles with those files. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
