Hmm, revisions to block~.
I think it would suffice to offer a flag, as in "nlock -manualsync 234 ..." that would decare the local block size to, say, 234 samples and require that one ban the block~ object to run one block of 'audio' computation I'd still require that subblocks that aren't "-manualsync" be a power of two multiple or quotient of the parent to make the inlet~/outlet~ code manageable, but if "-manualsync" were on I'd simply disable inlet~/outlet~ as undefined behavior.
One thing I'll be concerned about eventually is getting video input into a storage buffer without the need for an intermediary. I don't know whether Gem's storage buffers (as in pix_multiimage) are easily enough visible to C code to work in this way. In other words, if pix_multiimage just instructs openGL to read a file into its own buffer somewhere, then it's not easily available for me to write random-access interpolating "tabread4~" style objects that use it.
cheers Miller
On Sun, Jun 04, 2006 at 01:23:36AM -0500, chris clepper wrote:
On 6/3/06, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
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).
One of the more time consuming (and potentially frustrating) aspects of video systems is the dealing with the various APIs for reading and writing frames. Using the existing libraries to handle those chores would save some redundant effort.
Can you go into more detail about the revisions to block~? My rough calculations put a 720x480 YCbCr image at about 64 times the data of a single 96khz audio signal. RGBA is double that.
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...)
Rectangle textures work on Linux, Mac and Windows now. Right now all three handle RGBA, but only OSX has native support for YCbCr (the other two require software conversion to RGBA before upload).
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev