Hi list, I just had a look at chuns editor patch because I want to try getting multiple geos. The attached test patch I created shortly before was my early starting point. As far as I know I have to create single gemheads to have inidividually transformations on each geo, right? Because I want to create a dynamically changing number of objects I stucked building the patch ...
does somebody know how to get further? Thanks in advance, regards christian
Christian Klotz Kunsthochschule Kassel / School of Arts Kassel ::digitalpool
I just thought that ir would be more imaginable if I explain what I want to do - my idea was to have depending on the volume of some spund a number of geos which will be aligned in a circle with the same distance from each other which will be calculated by 360!/number of geos. And later there will be more transformation to each geo ... well, maybe it helps :) ... cheers christian
Christian Klotz Kunsthochschule Kassel / School of Arts Kassel ::digitalpool
Hi list, I just had a look at chuns editor patch because I want to try getting multiple geos. The attached test patch I created shortly before was my early starting point. As far as I know I have to create single gemheads to have inidividually transformations on each geo, right? Because I want to create a dynamically changing number of objects I stucked building the patch ...
does somebody know how to get further? Thanks in advance, regards christian
hello,
I remember that Iohannes send a mail with this kind of exemple long time ago. it should be on the archive (I don't know if attachement are on the archive). i also made an exemple that could help and send it to the list the 29 september. if you can't find it, i'll send it back to you.
cheers Cyrille
Christian Klotz a écrit :
I just thought that ir would be more imaginable if I explain what I want to do - my idea was to have depending on the volume of some spund a number of geos which will be aligned in a circle with the same distance from each other which will be calculated by 360!/number of geos. And later there will be more transformation to each geo ... well, maybe it helps :) ... cheers christian
Christian Klotz Kunsthochschule Kassel / School of Arts Kassel ::digitalpool
Hi list, I just had a look at chuns editor patch because I want to try getting multiple geos. The attached test patch I created shortly before was my early starting point. As far as I know I have to create single gemheads to have inidividually transformations on each geo, right? Because I want to create a dynamically changing number of objects I stucked building the patch ...
does somebody know how to get further? Thanks in advance, regards christian
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
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.
- to create 10 squares, from what I understand, you need 10 sets of
[translateXYZ]->[square] but can do with just one gem head depending on how much control you want over the rendering order.
- 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.
- 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.
Cheers
CHUN
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.
- 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, 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] !!
- 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
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
Hi there:
Just found an example on the Pd list from the "[pd][Gem]Iterating geos tricks" thread.
You can ignore my previous reply as I think this example patch explains a lot of my questions.
Cheers
CHUN
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
On Nov 26, 2004, at 9:22 PM, chun lee wrote:
Hi there:
I think I begin to understand the gemList concept. Anyway, please take a look your patch that I have modified. It now creates n number of cubes dynamically.
Peace
CHUN
<02_main(chun).pd.zip>
Christian Klotz Kunsthochschule Kassel / School of Arts Kassel ::digitalpool
Christian Klotz Kunsthochschule Kassel / School of Arts Kassel ::digitalpool
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
Hi pete,
just tried your patch and it seemed not to work... at all... should the "a" in the trigger be connected to something?
pete
===== ________________________________ http://www.140worthing.karoo.net ++++++++++++++++++++++++++++++++
___________________________________________________________ Win a castle for NYE with your mates and Yahoo! Messenger http://uk.messenger.yahoo.com
pete mcpartlan wrote:
Hi pete,
just tried your patch and it seemed not to work... at all... should the "a" in the trigger be connected to something?
you need [any] (from iemlib)
basically both using [repeat] and [uzi]+[any] impose an external dependency (zexy vs. iemlib) which is a bad thing; unfortunately [pack p p] doesn't work with gem-pointer. probably i'll ahve a look at this sometimes...
mfg.as.dr IOhannes
Derek Holzer and Aymeric Mansoux are giving a series of workshops on Linux and Pure Data in the UK during the months of November and Decemeber. For full info, please visit:
http://electric-boogaloo.goto10.org/pdzilla/
This email is to announce that the workshop from Tuesday 14 Dec - Saturday 18 Dec at Lighthouse in Brighton is CANCELLED!
The London workshop, hosted by Mute Magazine, has been moved one week earlier to take its place. The new dates for this workshop are Monday 13 Dec - Tuesday 14. There is still space in this workshop, so contact services@metamute.com to sign up.
There will also be a PD Demo Party featuring ourselves and OpenLab at an unconfirmed venue on the evening of Tuesday 14 Dec. Check the following pages for further info:
http://electric-boogaloo.goto10.org/pdzilla/ http://3d.openmute.org/
hope to see some of you there! derek
--- IOhannes m zmoelnig zmoelnig@iem.at wrote:
pete mcpartlan wrote:
Hi pete,
just tried your patch and it seemed not to work...
at
all... should the "a" in the trigger be connected
to
something?
you need [any] (from iemlib)
it's working fine now, it was as i suspected and the [t b a] wasnt connected into the [any]...
thanks for the hep though,
pete
===== ________________________________ http://www.140worthing.karoo.net ++++++++++++++++++++++++++++++++
___________________________________________________________ Win a castle for NYE with your mates and Yahoo! Messenger http://uk.messenger.yahoo.com
-
Christian Klotz -
chun lee -
cyrille henry -
derek＠x-i.net -
IOhannes m zmoelnig -
Johannes M Zmoelnig
-
pete mcpartlan -
Peter Todd