I implemented Miller's phase vocoder from the documentation in C and was amazed to see that the CPU load was exactly the same. So much for improving efficiency... But I have seen a big difference for traversing tables and lists. The process of summing the elements in a large table is much faster in an extern than with an [until] loop.
In the case of [pix_motion_sector], what's the easiest way to duplicate the functionality of reporting % of pixels changed in the region? Is there an obvious way to count up the number of pixels that crossed [pix_movement]'s threshold in the cropped region? 2010/5/14 IOhannes m zmölnig <[email protected]>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jaime Oliver wrote: >> On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard <[email protected]>wrote: >> >>> On Thu, 13 May 2010, William Brent wrote: >>> >>> Yes - it's exactly that: an adaptation of pix_movement that lets you >>>> specify an area to analyze. That way you can use several instances to >>>> create multiple regions for triggering different events. I haven't looked >>>> at this in two years! I'll take a look at the helpfile and see what's >>>> missing/unclear. >>>> >>> what's the difference between that, and using [pix_crop] and [pix_movement] >>> with [pix_separator] ? >>> >> >> Please correct me if I'm wrong, >> Doesn't having these as externals instead of abstractions, make it >> significantly faster/efficient? >> particularly if you have many of them? >> > > no not necessarily. > the overhead for message communication between objects is usually quite > small, compared to the pixel operations. > > you would only need [pix_crop]->[pix_movement] without the > [pix_separator] (since the crop will have to allocate a new image > anyhow), thus no need for the extra copying of data. > > the only speedup you could expect from pix_motion_sector (i haven't > looked at the code), is that you wouldn't have to copy the data for > cropping at all, but only use the pixels in the ROI. > > > as for williams argument, that you need less objects, i would suggest > looking into abstractions :-) it's definitely less lines of code (at a > minimum 10 lines of Pd code) and still only a single object... > > mfgasdr > IOhannes > > > >> best, >> >> J >> >>> _ _ __ ___ _____ ________ _____________ _____________________ ... >>> | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 >>> _______________________________________________ >>> [email protected] mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >>> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkvtC0wACgkQkX2Xpv6ydvTVNwCgot+wBAkpacUIHBFR3Fg5OmWV > xhAAoITZ7wN077ETVr58rSVE9iunYybB > =jYk3 > -----END PGP SIGNATURE----- > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- William Brent www.williambrent.com “Great minds flock together” Conflations: conversational idiom for the 21st century www.conflations.com _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
