Le vendredi 14 mai 2010 à 06:49 -0700, William Brent a écrit : > 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? [pix_dump] ? Maybe a faster method ? ++
Jack > > > > 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 > > > > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
