cyrille henry wrote:
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
hello, thanks for the answer,
that would be great i think, but is this a plan or a work in progress?
well, the patch i sent should actually work (with a recent Gem that already has [gemreceive]), so it is already "work in progress".
ok, cool. look like my 2 month old Gem was to old! i update / recompile and yes, this patch is working.
trying to understand the use of gemreceive, i realized that replacing it with a simple receive did work. look like gemreceive is a receive with priority, is it true?
exactly. it really has nothing to do with Gem per se, but as it is not in Pd-vanilla and would be needed i added it.
This mean that even with older Gem version it is possible to render multiple gemhead in the same frambuffer using something similar to your example...
oh yes. it was just a matter of show off (and of course i didn't know whether you needed a certain render-order, which is impossible to do with pure [receive]s)
([gemhead] should be an abstraction with a [gemreceive] and some"gemreset" object(s))
the gemreset objets does not exist yet (?).
correct
should/could it be made with GEMgl objects?
part of it could be done with GEMgl; other parts will need access to the gem_list structure (and thus have to be done in C++)
- a [gemwin] abstraction should do the [send] and setup the viewpoint
and the like (rather than code hidden within GemMan)
ok
same question : should/could it be made with GEMgl objects?
yes, i think most of it can be done with GEMgl.
it is related to that. though the "is in development" hurts a bit :-)
oups, sorry, did not wanted to hurt.
well, it was just a reminder of something that should have been done for ages. sometimes it is good to be kicked (very lightly)
gfmasdr IOhannes