excellent question... it might prove that all I'd need, besides the changes to block~, would be to write a larger suite of objects based on pix_sig2pix and pix_pix2sig (for a wide variety of access styles and interpolations).
By the way, has anyone ever fixed pix_texture so that it can take non-power-of-two image sizes? (I assume it's still true that pix_texture is the fastest way to display an image - if that's still true, it would be important to support at least arbitrary rectangles...)
thanks Miller
On Sat, Jun 03, 2006 at 09:28:52PM -0500, chris clepper wrote:
GEM already has two objects for turning audio into video and back again - pix_sig2pix and pix_pix2sig. How is this proposal different from what those objects do already? Would changing the block~ object and using the pix_ objects implement the system as proposed?
cgc
On 5/27/06, Miller Puckette <mpuckett@imusic1.ucsd.edu > wrote:
To Pd developers,
After years of worrying about it, I'm thinking it's time to add video support natively to Pd. My basic idea is to add a feature to the block~ object so that windows of DSP computation can be triggered from external messages. That way, video I/O objects could be designed to spit out frames or portions of frames on demand, and the user gets the ability to explicitly schedule how the video computations should be run.