[PD-dev] call for discussion: native video for Pd
Miller Puckette
mpuckett at imusic1.ucsd.edu
Sun Jun 4 18:10:52 CEST 2006
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
More information about the Pd-dev
mailing list