2013/8/30 Jack <[email protected]> > Hello Nicolas, > > Le 30/08/2013 10:48, Nicolas Montgermont a écrit : > > > Hello jack, > > > > yes it can be very useful and powerful. > Yep. > > > On the abstraction you send I have differents remarks: > > - it is not compatible with [pix_chroma_key] and I think this is very important. The main usage of that kind of abstractions is to have an easy and faster replacement for existing objects. > Not totally compatible, yes. I think, it is more simpler to use a range value as float which determine the distance between the target color to remove (and other color in a circle of radius equal to that range). There is many way to make a chroma_key... But you are right, the aim of this abstractions is to be like pix_ object (when it is possible). What other people think about it ?
I think it's better to have drop-in replacement of pix_* object, but it could be difficult to manage for example a strict equivalent to pix_chroma_key should handle a no argument initialisation, is this possible with glsl_chroma_key ? > > > > - I see no reasons to have a default size to 256x256, or even to have a size as an argument, texture size of the first texture will be really easier as default, and dimen can be used to change that. > 256x256 is the default size of the texture generate by [gemframebuffer]. > If you have a texture1 at 800x800 tx and a second at 400x400 tx and need a texture at 200x200 tx as output, it is possible. > If you start to change the dimen of the texture1 with [pix_resize], it is too slow... > Of course, you can use the message [dimen( on the abstraction to change the size of the texture generate. yes and pix_chroma_key doesn't handle non equal texture, so this is good but, I think we can make it more silently By scaling texcoord according to texture size But maybe i m wrong... > > > > - I think it's good if the provided example of the usage is easily transposable, beginners tends to copy directly from the help patch. I think here for example the main gemhead could be to default and the gemhead before the gemframebuffer to 49 > I let the user (beginner) to manage it with the 'main' gemhead. It is why the gemhead is outside from the abstraction. With that, you can chain glsl_ abstractions and choose the render order. > > > - for the help line : "inlet 1 all messages accepted by gemframebuffer", I think it's good to have a subpatch [pd framebuffer_messages] with a listing that can be tested. You may then copy it inside the other help patchs. > Yes, good idea. > > > - maybe the object can print a specific error message when it doesn't know the input: > > glsl_chroma_key : no method for 'toto' > > instead of: > > gemframebuffer: no method for 'toto' > Yes, good idea too. I will add a gem_state in [route]. > ++ > > Jack > > > > > > best, > > n > > > > > > Le 30/08/13 01:51, Antoine Villeret a écrit : > >> good job ! > >> could be very useful ! > >> I have some too (to replace pix_movement for example) > >> what is your working repo ? > >> > >> + > >> a > >> > >> -- > >> do it yourself > >> http://antoine.villeret.free.fr > >> > >> > >> 2013/8/28 Jack <[email protected] <mailto:[email protected]>> > >> > >> >> >> Le 26/07/2013 14:03, IOhannes m zmölnig a écrit : >> > On 07/26/13 11:44, Jack wrote: >> >> Hello, >> >> >> I would like to create GLSL abstractions in the help directory, which >> >> would replace pix_ objects when possible. The name would start with >> >> glsl_ instead of pix_. >> >> > sound good. >> >> >> Is there any objection against this ? >> >> > no. >> >> >> If not, i would like to have acces to the git repository with write >> >> access. Is that possible ? >> >> > wouldn't it be easier if you just forked the repository, and made a >> > pull-request via github? >> > i really love the decentralized aspect of git. >> >> >> > mgfd.gasda >> > IOhannes >> >> >> >> >> > _______________________________________________ >> > GEM-dev mailing list >> > [email protected] <mailto:[email protected]> >> >> > http://lists.puredata.info/listinfo/gem-dev >> >> >> I started to make seven abstractions glsl_*. >> I would like to be sure, with the example attached, if i am on the right path. >> Comments are welcome. >> ++ >> >> Jack >> >> > >> > >> > >> _______________________________________________ > >> GEM-dev mailing list > >> [email protected] <mailto:[email protected]> > > >> http://lists.puredata.info/listinfo/gem-dev > >> > >> > >> > >> > >> _______________________________________________ > >> GEM-dev mailing list > >> [email protected] > >> http://lists.puredata.info/listinfo/gem-dev > > > > -- > > http://www.nimon.org > > > > > > _______________________________________________ > > GEM-dev mailing list > > [email protected] > > http://lists.puredata.info/listinfo/gem-dev > > > > > _______________________________________________ > GEM-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/gem-dev >
_______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
