[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