[PD-dev] [GEM] cvs update *.*

bbogart bbogart at ryerson.ca
Fri Mar 7 20:48:39 CET 2003


Hey Devs

 From Coder's POV pix_buf may be more accurate, but I think 
pix_separator makes more sense from the user perspective.

B.

On Friday, March 7, 2003, at 02:28 PM, chris clepper wrote:

>> hi GEMers !
>>
>> last night i have updated some files in the Gem-CVS and had no time 
>> for sending out a mail ... sorry, here it goes:
>
> <snip>
>
>> 3. [separator]
>> hopefully i have fixed the bug that kept it crashing when it was used 
>> with images.
>
> as you note in the source, there is now a memory leak in the separator 
> object.  i have yet to figure out what the problem is, but calling 
> free on that pointer should cause a warning not a crash (it doesn't 
> segfault on OSX).  maybe a linux bug??
>
>> 4.[pix_buf]
>> hopefully fixed the bug that kept it crashing when it was used with 
>> images.
>> [pix_buf] will store image-data into a separate buffer. all pix_ 
>> objects below [pix_buf] will have access to the buffered data instead 
>> of the original one.
>
>> 5. [pix_crop]
>> i thought i had checked this in long ago (but obviously had not, and 
>> now i have found the original code again)
>> it takes sub-images of images (withan offset x/y pair and a dimen w/h 
>> pair)
>
> i was thinking of making an object that combined both of these 
> functions so one could 'cut up' and image and process each part 
> differently.  maybe it would be called [pix_split] or [pix_cut(up)] or 
> [pix_slice]?  basically the user would send messages selecting the 
> area to output and a for loop would move the pixels around.  it would 
> be nice to have N number of outlets for this object, but i'm not sure 
> how possible that it with GEM.
>
> i have also written a mode of processing called processSubImage() that 
> only processes a user specified area of the image.  it's probably not 
> practical to add this to each and every object so maybe [pix_split] is 
> a better way to go....
>
>> 6. what else ?
>> a minor configure-script update
>> + "cannot remember"
>
> there were some updates to GemBase with the ultra-informative log 
> entry of '???'.  what happened there?
>
> cgc
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.kug.ac.at
> http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev





More information about the Pd-dev mailing list