[PD] pix_motion_sector

[William Brent]

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 <zmoelnig at iem.at>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jaime Oliver wrote:
>> On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard <matju at artengine.ca>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
>>> _______________________________________________
>>> Pd-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Pd-list at iem.at 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-----
>
> _______________________________________________
> Pd-list at iem.at 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