Hi Iohannes:
Thanks for the reply and being patient;) I have relatively little experience with Gem, please bare with me;)
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:
- 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.
Ummm, I can't really tell if they are in sync or in the right order, but I can't see 10 squares been drawn (unless they all stuck on the top of each other). there is a [t b f] where the [f] outlet is connected to the traslate-value and [b] is to the gemhead. And a [repeat] is used to sent 10 bangs to [t b f] plus a some function to offset the traslate-values.
- 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...
So I can create 10 squares using just one [square]? If so, how would I make adjustment on each square individually?
- 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 ?
That's correct.
you can do that without [repeat]; you have [until] !!
- 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")
That's what I was thinking.
if you want a dynamically changing number of objects, this might work also, if you have a fixed maximum number of objects.
Isn't maximum number of drawable object depended on how power the machine is?
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.
Ok, I think I am missing something very basic . How do you get the gemList? I tried [print] after [square] to see what happened, but I am obviously wrong. I really have not worked with Gem much......
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