[PD] GEM - multiple geos - each accessable for transformation

Peter Todd peter_todd82 at yahoo.co.uk
Sun Nov 28 14:55:45 CET 2004


Try this one, based on tables, with each slot in a table corresponding to 
one cube.  Translator needs telling each individual time you want it to do 
something different, which means that your method of only sending in data 
when the counter ID matched the chosen object to move, meant that data would 
remain there for all the other cubes.  So instead, you can use your 'chosen 
for editing' number, to decide which slot in the tables to write to.  Then 
you read all of them back, every frame.   I hope that, and my attached 
example, make sense.

Cheers,
Peter

> Hi
> thanks for the modified patch - now I got how repeat works :) - but
> there is still an important thing I want to do in this patch. Its about
> the transformation of each single geo. I though how it may work but it
> doesnt as you can see in the attached patch. So I used a separator to
> get each single geo accessable and the geo is now in an abstraction
> with more inlets to get kind of IDs in there which will be compared to
> the number given by the repeat object. But all in all there seems to be
> something wrong in this patch ...
>
> thanks for help, regards, christian
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: uzi.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20041128/76f74a01/attachment.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: single_cube.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20041128/76f74a01/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tableTransform.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20041128/76f74a01/attachment-0001.asc>


More information about the Pd-list mailing list