[PD-dev] call for discussion: native video for Pd

[Miller Puckette]

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 at 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 at iem.at
> http://lists.puredata.info/listinfo/pd-dev