[PD] GEM - multiple geos - each accessable for transformation
Johannes M Zmoelnig
zmoelnig at iem.at
Fri Nov 26 16:10:07 CET 2004
chun lee wrote:
> Hi Christian:
>
> How are you getting on with your multiple geos experiment?
>
> I had a look into your patch and here is what I think:
>
> 1. in your 02_main.pd, the [repeat 10] does not generates 10 squares, it
> just send sends different values to the [translateXYZ] object and bang to
> [gemhead] 10 times. This does not create 10 squares, I think.
if banging the gemheads and sending the translate-values is in sync this
might work.
>
> 2. to create 10 squares, from what I understand, you need 10 sets of
> [translateXYZ]->[square]
not necessarily;
you can call one instance of [translateXYZ]->[square] multiple times
(e.g. with [t a a a a a] or simpler [repeat]) and get 10 squares drawn
the joys of state-machines...
>
> 3. so, the way to use [repeat] is that to work out the necessary internal
> messages to create [translateXYZ]->[square] first and use [repeat] to repeat
> the whole script 10 times.
i guess this means, that you use [repeat] to create a patch with
pd-internal-messages ?
you can do that without [repeat]; you have [until] !!
>
> 4. or, build [translateXYZ]->[square] into a abstraction, and use the patch
> I made to create 10 of them. However, to do it, you might what to do like
>
> [r from_gemhead]
> |
> |
> [translateXYZ]
> |
> |
> [square]
>
> And in the parent window do:
>
> [gemhead]
> |
> |
> [s from_gemhead]
>
> Making sense? Correct me if I am wrong.
it does make sense, although using send/receive is not very recommended
(you have _no_ control over execution order any more, which might prove
essential...)
however, if you have a fixed number of objects, it might be simple
enough to use something like that.
i think it is always good, if 1 object (e.g. "abstraction", "set of
objects") represents 1 drawn object ("geo")
if you want a dynamically changing number of objects, this might work
also, if you have a fixed maximum number of objects.
if everything should be dynamically, use [repeat] to repeat the gemList
(the message that comes out of a gem-object) and enjoy the joys of
state-machines.
what i was missing in this discussion is: [separator]
to have control of each object individually, you might want to use a
table to store the individual values and a counter to read them.
mfg.ad.r
IOhannes
More information about the Pd-list
mailing list