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 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. > - 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
