On 6/3/06, <b class="gmail_sendername">Miller Puckette</b> <<a href="mailto:mpuckett@imusic1.ucsd.edu">mpuckett@imusic1.ucsd.edu</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
excellent question... it might prove that all I'd need, besides the<br>changes to block~, would be to write a larger suite of objects based<br>on pix_sig2pix and pix_pix2sig (for a wide variety of access styles and<br>interpolations).
</blockquote><div><br>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.
<br><br></div>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.<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
By the way, has anyone ever fixed pix_texture so that it can take<br>non-power-of-two image sizes? (I assume it's still true that pix_texture<br>is the fastest way to display an image - if that's still true, it would<br>
be important to support at least arbitrary rectangles...)</blockquote><div><br>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).
<br></div><br></div><br>