Well, Jitter does it the GridFlow way, which is already pretty abstracted out from low-level considerations. The most difficult part is actually mapping the dimensions and indices of one data structure to another in a _meaningful_ way (or at least an interesting way). The most lowlevel is direct redimensioning, but actually there are much more sophisticated transforms than mere reinterpretation of data.
the 'meaningful way' is what i'm talking about. how to make it simple for the user to get some element of the pixel data, like the Y for example, and map it to another system like texcoords or vertices.
In any case, a type conversion is not more that just saying that you want a type conversion to happen ([@cast uint8]), and a redim is not more than saying you want it to happen ([@redim {240 320 3}]), and all objects do check bounds automatically. So I'm not sure what kind of "housekeeping like creating buffers, type and bounds checking, etc" that you are talking about.
ok, i'm not making any sort of value judgement about GridFLow at all, but i think you actually made the point for me: i don't think users need to care or even know about which C data type the pixel info is in and what it needs to be cast to to work in GL. there are lots of people i know and work with that really couldn't be bothered with the process of explicitly doing the buffer parsing to get at the data they want, casts and resizes - that's the sort of thing the programmers of the system are supposed to do for them. ;)
instead a series of bridge objects can be constructed either in code or by abstraction to translate and guide the data around. [...] just wanted to bounce the idea off the others devs to get some input.
could you please elaborate on this?
i do not have anything working at the moment, it was only an idea i thought the other devs might want to think about too. but basically the concept is to have objects that took info out of the pixel buffer and turned that info into something that the particle system could use or could be vertices used to built a 3D Geo, etc. the object would simply require the user to select which part of the data they want to use and optionally resize and rearrange it. a hypothetical object could be [pix_to_vertex R 64 64] which would take the red channel of the video and scale it to 64 by 64 array of vertices. of course this is quite limited in a way but also direct, and hopefully efficient to implement in C code as well. again this is purely off the top of my head with no actual system in place, so who knows what the final result will be...
cgc