Hi,
I have a couple of questions regarding the [pmpd] object. It is not quite clear to me, what the messages to this object mean exactly. Actually I'm very confused about them.
As I see it, there are basically four messages possible to create the dynamic system: mass, link, in, out.
All of these take IDs as arguments. I don't understand the meaning of those IDs. For example to create a mass, one uses messages like:
mass ID MASS X
MASS and X are easy, but what is this "ID" used for?
"link" also takes IDs as argument, but it seems to ignore the ID given to a mass on creation, instead it seems to use its own IDs and it has an ID itself:
link LINK-ID MASS1-ID MASS2-ID K D
Where do I get the mass IDs from? In my experiments, it seems just have to keep track of them myself, and they have nothing to do with the ID I gave to a mass earlier. Or do I get it wrong?
Outlet creation (and inlet creation respectively): As I understand it, the format is:
out OUT-ID OUTLET MASS-ID AMPLITUDE
AMPLITUDE seems to be a scaling factor. OUT-ID I don't understand at all: what use does it have? Am I right to assume that OUTLET is numbered from 0 to max-outlet-number, where max-outlet-number is the second argument of pmpd minus one? And then MASS-ID: Does it start from 0 as well? Or from 1? Where do I get this ID from? In my experiments, it seems to have to be the MASS-ID I used when creating the "link"s.
Sorry for my confusion...
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
Hi Frank,
I'll take a crack at this, Please correct me where needed Cyrille!
Hmmm indeed there is a single object called "pmpd" I am not sure what this does, but sounds like it allows you to make a physical model without having to connect patch-cords and use pmpd component objects. I'm going to guess all these answers are the same in pmpd as in [mass] [link] etc..
The ID in [mass] is used as a receive name so that the render signal can be sent without connecting a cord. Same goes for [link] At the top of most pmpd examples is:
[metro] | [t b b] | | [s m] [s l]
Where the ID of the masses is "m" and the ID for links is "l".
This means you can control the rendering of different structures based on thier ID name.
I'm guessing the In and Out stuff has to do with comunicating from the internal physical model to the outside patch.
Frank, is there a strong reason you are using the pmpd object, and not using [mass] [lia] etc?? Much easier to start here and I think make many things clear...
So Cyrille, what is the [pmpd] object? Why is there no help for it in CVS? What is it for?
Hope I helped a bit Frank.
B>
Frank Barknecht wrote:
Hi,
I have a couple of questions regarding the [pmpd] object. It is not quite clear to me, what the messages to this object mean exactly. Actually I'm very confused about them.
As I see it, there are basically four messages possible to create the dynamic system: mass, link, in, out.
All of these take IDs as arguments. I don't understand the meaning of those IDs. For example to create a mass, one uses messages like:
mass ID MASS X
MASS and X are easy, but what is this "ID" used for?
"link" also takes IDs as argument, but it seems to ignore the ID given to a mass on creation, instead it seems to use its own IDs and it has an ID itself:
link LINK-ID MASS1-ID MASS2-ID K D
Where do I get the mass IDs from? In my experiments, it seems just have to keep track of them myself, and they have nothing to do with the ID I gave to a mass earlier. Or do I get it wrong?
Outlet creation (and inlet creation respectively): As I understand it, the format is:
out OUT-ID OUTLET MASS-ID AMPLITUDE
AMPLITUDE seems to be a scaling factor. OUT-ID I don't understand at all: what use does it have? Am I right to assume that OUTLET is numbered from 0 to max-outlet-number, where max-outlet-number is the second argument of pmpd minus one? And then MASS-ID: Does it start from 0 as well? Or from 1? Where do I get this ID from? In my experiments, it seems to have to be the MASS-ID I used when creating the "link"s.
Sorry for my confusion...
Ciao
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
Frank, is there a strong reason you are using the pmpd object, and not using [mass] [lia] etc?? Much easier to start here and I think make many things clear...
I'm trying to build physical systems programmatically, and that's what pmpd and pmpd~ are better for than using the mass/link objects. (I played with dynamic patching and [dyn] as well. [dyn] is cool for this, but I'd like to explore [pmpd], too.)
Attached is the patch I'm currently working on, which is some scanned synthesis thing done with pmpd. Sorry for it being a bit confusing. I'll explain it:
The patch has a system of 10 masses inside. You can specify your physical network using the toggles in "pd matrixedit". Every toggle set to 1 will create a link between the masses specified by its x/y coordinates. This is a string where mass 0 is connected to mass 1, mass 1 connected to mass 2, 3-4, 4-5, ... and at last 9 to 0:
0123 ... 9 = X +----------+ 0 |..........| 1 |x.........| 2 |.x........| 3 |..x.......| . |...x......| . |....x.....| . |.....x....| |......x...| |.......x..| 9 |x.......x.| +----------+ Y
(This is inspired by Csound).
Clicking the bang "rebuild" will then create this network, which can be set into action with the metro and some forces. So far this seems to work okay, but I'm struggling with doing the outlet-connections. This is done in "pd doouts" (upper right) but regardless of what I do, some of those outlets just seem to receive wrong or no data.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
hello frank,
after a quick look at your patch :
- i'll not say anymore that my patch are a mess :-)
- there is no fixed point. -> the (bad) solution i found to solve this is that masses with
negative id (maybee <= 0, i don't remember) will not move. the structure nead to be linked to one fixed point (at least), otherwise it will go and never came back... -there is no way to delete a link (ok, i add that to my todo list), so you'll not be able to change the structure in real time. -it's a good idea, i don't know what your patch will do... -there are problems on the [pmpd] oject : in and out begin from 0, but masses and link beggin from 1. what is the most logic things to do : everything should beggin at 0 or 1? -sending force 2 1 make some movement on the structure, as expected (force 1 1 does not work because of this 0 or 1 problem i think)
as you're the 1st asking about this object, i think your the 1st triing to use it. so i'll change this 0 or 1 problem as soon as i got some time (i really don't know when).
hope that help cyr
Frank Barknecht wrote:
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
Frank, is there a strong reason you are using the pmpd object, and not using [mass] [lia] etc?? Much easier to start here and I think make many things clear...
I'm trying to build physical systems programmatically, and that's what pmpd and pmpd~ are better for than using the mass/link objects. (I played with dynamic patching and [dyn] as well. [dyn] is cool for this, but I'd like to explore [pmpd], too.)
Attached is the patch I'm currently working on, which is some scanned synthesis thing done with pmpd. Sorry for it being a bit confusing. I'll explain it:
The patch has a system of 10 masses inside. You can specify your physical network using the toggles in "pd matrixedit". Every toggle set to 1 will create a link between the masses specified by its x/y coordinates. This is a string where mass 0 is connected to mass 1, mass 1 connected to mass 2, 3-4, 4-5, ... and at last 9 to 0:
0123 ... 9 = X +----------+ 0 |..........| 1 |x.........| 2 |.x........| 3 |..x.......| . |...x......| . |....x.....| . |.....x....| |......x...| |.......x..| 9 |x.......x.| +----------+ Y
(This is inspired by Csound).
Clicking the bang "rebuild" will then create this network, which can be set into action with the metro and some forces. So far this seems to work okay, but I'm struggling with doing the outlet-connections. This is done in "pd doouts" (upper right) but regardless of what I do, some of those outlets just seem to receive wrong or no data.
Ciao
#N canvas 434 145 566 665 10; #N canvas 821 56 450 300 matrixedit 1; #X obj 10 10 tgl 15 1 m0 m0 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 10 25 tgl 15 1 m1 m1 empty 0 -6 0 8 -262144 -1 -1 1 1; #X obj 10 40 tgl 15 1 m2 m2 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 10 55 tgl 15 1 m3 m3 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 10 70 tgl 15 1 m4 m4 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 10 85 tgl 15 1 m5 m5 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 10 100 tgl 15 1 m6 m6 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 10 115 tgl 15 1 m7 m7 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 10 130 tgl 15 1 m8 m8 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 10 145 tgl 15 1 m9 m9 empty 0 -6 0 8 -262144 -1 -1 1 1; #X obj 25 10 tgl 15 1 m10 m10 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 25 25 tgl 15 1 m11 m11 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 25 40 tgl 15 1 m12 m12 empty 0 -6 0 8 -262144 -1 -1 1 1; #X obj 25 55 tgl 15 1 m13 m13 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 25 70 tgl 15 1 m14 m14 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 25 85 tgl 15 1 m15 m15 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 25 100 tgl 15 1 m16 m16 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 25 115 tgl 15 1 m17 m17 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 25 130 tgl 15 1 m18 m18 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 25 145 tgl 15 1 m19 m19 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 40 10 tgl 15 1 m20 m20 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 40 25 tgl 15 1 m21 m21 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 40 40 tgl 15 1 m22 m22 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 40 55 tgl 15 1 m23 m23 empty 0 -6 0 8 -262144 -1 -1 1 1; #X obj 40 70 tgl 15 1 m24 m24 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 40 85 tgl 15 1 m25 m25 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 40 100 tgl 15 1 m26 m26 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 40 115 tgl 15 1 m27 m27 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 40 130 tgl 15 1 m28 m28 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 40 145 tgl 15 1 m29 m29 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 55 10 tgl 15 1 m30 m30 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 55 25 tgl 15 1 m31 m31 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 55 40 tgl 15 1 m32 m32 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 55 55 tgl 15 1 m33 m33 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 55 70 tgl 15 1 m34 m34 empty 0 -6 0 8 -262144 -1 -1 1 1; #X obj 55 85 tgl 15 1 m35 m35 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 55 100 tgl 15 1 m36 m36 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 55 115 tgl 15 1 m37 m37 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 55 130 tgl 15 1 m38 m38 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 55 145 tgl 15 1 m39 m39 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 70 10 tgl 15 1 m40 m40 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 70 25 tgl 15 1 m41 m41 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 70 40 tgl 15 1 m42 m42 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 70 55 tgl 15 1 m43 m43 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 70 70 tgl 15 1 m44 m44 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 70 85 tgl 15 1 m45 m45 empty 0 -6 0 8 -262144 -1 -1 1 1; #X obj 70 100 tgl 15 1 m46 m46 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 70 115 tgl 15 1 m47 m47 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 70 130 tgl 15 1 m48 m48 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 70 145 tgl 15 1 m49 m49 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 85 10 tgl 15 1 m50 m50 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 85 25 tgl 15 1 m51 m51 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 85 40 tgl 15 1 m52 m52 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 85 55 tgl 15 1 m53 m53 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 85 70 tgl 15 1 m54 m54 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 85 85 tgl 15 1 m55 m55 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 85 100 tgl 15 1 m56 m56 empty 0 -6 0 8 -262144 -1 -1 1 1; #X obj 85 115 tgl 15 1 m57 m57 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 85 130 tgl 15 1 m58 m58 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 85 145 tgl 15 1 m59 m59 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 100 10 tgl 15 1 m60 m60 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 100 25 tgl 15 1 m61 m61 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 100 40 tgl 15 1 m62 m62 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 100 55 tgl 15 1 m63 m63 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 100 70 tgl 15 1 m64 m64 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 100 85 tgl 15 1 m65 m65 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 100 100 tgl 15 1 m66 m66 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 100 115 tgl 15 1 m67 m67 empty 0 -6 0 8 -262144 -1 -1 1 1; #X obj 100 130 tgl 15 1 m68 m68 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 100 145 tgl 15 1 m69 m69 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 115 10 tgl 15 1 m70 m70 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 115 25 tgl 15 1 m71 m71 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 115 40 tgl 15 1 m72 m72 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 115 55 tgl 15 1 m73 m73 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 115 70 tgl 15 1 m74 m74 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 115 85 tgl 15 1 m75 m75 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 115 100 tgl 15 1 m76 m76 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 115 115 tgl 15 1 m77 m77 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 115 130 tgl 15 1 m78 m78 empty 0 -6 0 8 -262144 -1 -1 1 1; #X obj 115 145 tgl 15 1 m79 m79 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 130 10 tgl 15 1 m80 m80 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 130 25 tgl 15 1 m81 m81 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 130 40 tgl 15 1 m82 m82 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 130 55 tgl 15 1 m83 m83 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 130 70 tgl 15 1 m84 m84 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 130 85 tgl 15 1 m85 m85 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 130 100 tgl 15 1 m86 m86 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 130 115 tgl 15 1 m87 m87 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 130 130 tgl 15 1 m88 m88 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 130 145 tgl 15 1 m89 m89 empty 0 -6 0 8 -262144 -1 -1 1 1; #X obj 145 10 tgl 15 1 m90 m90 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 145 25 tgl 15 1 m91 m91 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 145 40 tgl 15 1 m92 m92 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 145 55 tgl 15 1 m93 m93 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 145 70 tgl 15 1 m94 m94 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 145 85 tgl 15 1 m95 m95 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 145 100 tgl 15 1 m96 m96 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 145 115 tgl 15 1 m97 m97 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 145 130 tgl 15 1 m98 m98 empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 145 145 tgl 15 1 m99 m99 empty 0 -6 0 8 -262144 -1 -1 0 1; #X restore 39 49 pd matrixedit; #X msg 305 163 clear; #N canvas 0 0 921 520 addtoggle 0; #X obj 161 382 outlet; #X obj 163 68 inlet; #X obj 342 86 inlet; #X text 173 249 x; #X text 233 241 y; #X text 279 245 id; #X obj 281 215 makefilename m%d; #X obj 280 191 float; #X msg 319 153 50; #X msg 360 152 40; #X msg 398 152 10; #X obj 643 203 div 10; #X floatatom 679 166 5 0 0 0 - - -; #X floatatom 637 240 5 0 0 0 - - -; #X obj 701 201 mod 10; #X floatatom 707 238 5 0 0 0 - - -; #X msg 752 153 12; #X msg 802 151 10; #X text 213 64 numbers; #X obj 165 166 div 10; #X obj 221 160 mod 10; #X obj 163 105 t f f f; #X obj 219 190 f; #X obj 167 188 f; #X obj 160 215 * 15; #X obj 216 223 * 15; #X obj 109 243 + 10; #X obj 189 249 + 10; #X obj 462 421 outlet; #X floatatom 417 399 5 0 0 0 - - -; #X obj 733 376 pmpd; #X obj 162 275 pack 50 40 s 0; #X msg 462 393 obj $1 $2 p-link $3 $4; #X obj 461 372 pack 50 40 s 0; #X obj 394 365 * 100; #X msg 151 327 obj $1 $2 tgl 15 1 $3 $3 empty 0 -6 0 8 -262144 -1 -1 0 1; #X connect 1 0 21 0; #X connect 2 0 19 1; #X connect 2 0 20 1; #X connect 6 0 31 2; #X connect 6 0 33 2; #X connect 7 0 6 0; #X connect 7 0 31 3; #X connect 7 0 33 3; #X connect 11 0 13 0; #X connect 12 0 11 0; #X connect 12 0 14 0; #X connect 14 0 15 0; #X connect 16 0 14 1; #X connect 16 0 11 1; #X connect 17 0 14 1; #X connect 17 0 11 1; #X connect 19 0 23 0; #X connect 20 0 22 0; #X connect 21 0 19 0; #X connect 21 1 20 0; #X connect 21 2 7 0; #X connect 22 0 25 0; #X connect 23 0 24 0; #X connect 23 0 34 0; #X connect 24 0 26 0; #X connect 25 0 27 0; #X connect 26 0 31 0; #X connect 27 0 31 1; #X connect 27 0 33 1; #X connect 29 0 34 1; #X connect 31 0 35 0; #X connect 32 0 28 0; #X connect 33 0 32 0; #X connect 34 0 33 0; #X connect 35 0 0 0; #X restore 190 161 pd addtoggle; #X obj 192 133 f 0; #X obj 226 134 + 1; #X obj 180 38 t b b; #X msg 243 69 0; #X obj 182 16 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 190 103 until; #X obj 177 75 f 2; #X floatatom 246 43 5 0 0 0 - - -; #X obj 89 186 print; #X obj 167 198 s pd-matrixedit; #X floatatom 292 96 5 0 0 0 size - -; #N canvas 700 609 450 300 values 0; #X obj 0 10 p-link m0 0; #X obj 0 25 p-link m1 1; #X obj 0 40 p-link m2 2; #X obj 0 55 p-link m3 3; #X obj 0 70 p-link m4 4; #X obj 0 85 p-link m5 5; #X obj 0 100 p-link m6 6; #X obj 0 115 p-link m7 7; #X obj 0 130 p-link m8 8; #X obj 0 145 p-link m9 9; #X obj 100 10 p-link m10 10; #X obj 100 25 p-link m11 11; #X obj 100 40 p-link m12 12; #X obj 100 55 p-link m13 13; #X obj 100 70 p-link m14 14; #X obj 100 85 p-link m15 15; #X obj 100 100 p-link m16 16; #X obj 100 115 p-link m17 17; #X obj 100 130 p-link m18 18; #X obj 100 145 p-link m19 19; #X obj 200 10 p-link m20 20; #X obj 200 25 p-link m21 21; #X obj 200 40 p-link m22 22; #X obj 200 55 p-link m23 23; #X obj 200 70 p-link m24 24; #X obj 200 85 p-link m25 25; #X obj 200 100 p-link m26 26; #X obj 200 115 p-link m27 27; #X obj 200 130 p-link m28 28; #X obj 200 145 p-link m29 29; #X obj 300 10 p-link m30 30; #X obj 300 25 p-link m31 31; #X obj 300 40 p-link m32 32; #X obj 300 55 p-link m33 33; #X obj 300 70 p-link m34 34; #X obj 300 85 p-link m35 35; #X obj 300 100 p-link m36 36; #X obj 300 115 p-link m37 37; #X obj 300 130 p-link m38 38; #X obj 300 145 p-link m39 39; #X obj 400 10 p-link m40 40; #X obj 400 25 p-link m41 41; #X obj 400 40 p-link m42 42; #X obj 400 55 p-link m43 43; #X obj 400 70 p-link m44 44; #X obj 400 85 p-link m45 45; #X obj 400 100 p-link m46 46; #X obj 400 115 p-link m47 47; #X obj 400 130 p-link m48 48; #X obj 400 145 p-link m49 49; #X obj 500 10 p-link m50 50; #X obj 500 25 p-link m51 51; #X obj 500 40 p-link m52 52; #X obj 500 55 p-link m53 53; #X obj 500 70 p-link m54 54; #X obj 500 85 p-link m55 55; #X obj 500 100 p-link m56 56; #X obj 500 115 p-link m57 57; #X obj 500 130 p-link m58 58; #X obj 500 145 p-link m59 59; #X obj 600 10 p-link m60 60; #X obj 600 25 p-link m61 61; #X obj 600 40 p-link m62 62; #X obj 600 55 p-link m63 63; #X obj 600 70 p-link m64 64; #X obj 600 85 p-link m65 65; #X obj 600 100 p-link m66 66; #X obj 600 115 p-link m67 67; #X obj 600 130 p-link m68 68; #X obj 600 145 p-link m69 69; #X obj 700 10 p-link m70 70; #X obj 700 25 p-link m71 71; #X obj 700 40 p-link m72 72; #X obj 700 55 p-link m73 73; #X obj 700 70 p-link m74 74; #X obj 700 85 p-link m75 75; #X obj 700 100 p-link m76 76; #X obj 700 115 p-link m77 77; #X obj 700 130 p-link m78 78; #X obj 700 145 p-link m79 79; #X obj 800 10 p-link m80 80; #X obj 800 25 p-link m81 81; #X obj 800 40 p-link m82 82; #X obj 800 55 p-link m83 83; #X obj 800 70 p-link m84 84; #X obj 800 85 p-link m85 85; #X obj 800 100 p-link m86 86; #X obj 800 115 p-link m87 87; #X obj 800 130 p-link m88 88; #X obj 800 145 p-link m89 89; #X obj 900 10 p-link m90 90; #X obj 900 25 p-link m91 91; #X obj 900 40 p-link m92 92; #X obj 900 55 p-link m93 93; #X obj 900 70 p-link m94 94; #X obj 900 85 p-link m95 95; #X obj 900 100 p-link m96 96; #X obj 900 115 p-link m97 97; #X obj 900 130 p-link m98 98; #X obj 900 145 p-link m99 99; #X restore 39 77 pd values; #X obj 298 187 s pd-values; #X msg 294 71 10; #X msg 294 35 100; #X obj 347 18 loadbang; #X obj 37 236 r pmpd; #X msg 372 115 reset; #X obj 372 149 s pmpd; #X obj 266 351 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 25 212 print pmpd; #X obj 264 373 s do-masses; #X obj 264 397 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 262 419 s do-links; #X obj 373 383 f $2; #X obj 374 338 r do-masses; #X obj 365 416 until; #X floatatom 480 389 5 0 0 0 size - -; #X msg 482 364 10; #X obj 487 332 loadbang; #X obj 357 491 s pmpd; #X obj 367 442 f 0; #X obj 407 442 + 1; #X obj 376 361 t b b; #X msg 409 418 0; #X obj 41 137 tgl 15 0 empty empty empty 0 -6 0 8 -24198 -1 -1 1 1 ; #X floatatom 82 134 5 0 0 0 - - -; #X msg 436 68 in 1 0 3 1; #X obj 464 483 *~ 10; #X floatatom 464 432 5 0 0 0 - - -; #X obj 464 463 phasor~ 100; #X obj 127 493 Scope~ 146 168 56 3 128 -1 1 0 0 0 0 102 255 51 135 135 135 0; #X floatatom 130 457 5 0 0 0 - - -; #X obj 29 452 print; #X obj 31 166 metro 40; #X obj 20 549 loadbang; #X msg 5 287 0; #X floatatom 175 365 5 0 0 0 - - -; #N canvas 684 316 481 431 doouts 0; #X obj 176 159 until; #X obj 168 393 s pmpd; #X obj 178 185 f 0; #X obj 218 185 + 1; #X obj 187 104 t b b; #X obj 174 320 pack 0 0; #X obj 181 284 t f f; #X obj 184 126 f 10; #X obj 185 81 r do-outs; #X obj 176 252 + 1; #X msg 220 161 0; #X msg 36 315 out 1 0 1 0.1; #X msg 38 337 out 1 0 10 0.1; #X msg 254 163 0; #X text 290 353 id outlet mass amplitude; #X text 262 322 $1: 1-10; #X text 262 310 $2: 0-9; #X msg 166 349 out 1 $2 $2 0.1; #X connect 0 0 2 0; #X connect 2 0 3 0; #X connect 2 0 9 0; #X connect 3 0 2 1; #X connect 4 0 7 0; #X connect 4 1 10 0; #X connect 4 1 13 0; #X connect 5 0 17 0; #X connect 6 0 5 1; #X connect 6 1 5 0; #X connect 7 0 0 0; #X connect 8 0 4 0; #X connect 9 0 6 0; #X connect 10 0 2 1; #X connect 11 0 1 0; #X connect 12 0 1 0; #X connect 13 0 5 1; #X connect 17 0 1 0; #X restore 481 30 pd doouts; #X obj 266 443 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 264 465 s do-outs; #X obj 512 289 bng 24 250 50 0 empty empty rebuild 0 -6 0 8 -24198 -1 -1; #X obj 279 332 t b b b b b; #X floatatom 227 436 5 0 0 0 - - -; #X floatatom 36 303 5 0 0 0 - - -; #X floatatom 74 305 5 0 0 0 - - -; #X floatatom 112 305 5 0 0 0 - - -; #X floatatom 152 303 5 0 0 0 - - -; #X floatatom 196 305 5 0 0 0 - - -; #X floatatom 242 303 5 0 0 0 - - -; #X floatatom 290 299 5 0 0 0 - - -; #X floatatom 334 299 5 0 0 0 - - -; #X floatatom 390 296 5 0 0 0 - - -; #X floatatom 444 294 5 0 0 0 - - -; #X obj 20 602 s $0-scan; #X obj 11 424 send $0-scan; #X obj 433 529 tabread4~ $0-scan; #X msg 380 238 forceX 1; #X obj 434 556 *~ 1; #X obj 483 561 hsl 64 16 0 1 0 0 $0-v $0-v volume -2 -6 0 8 -260818 -123526 -1 0 1; #X msg 222 393 0.5; #X msg 406 204 forceX 4 0.4; #X msg 442 228 forceX 9 0.4; #X obj 17 185 t b b; #X msg 450 160 forceX 1 0; #X msg 226 375 2; #X msg 446 134 forceX 1 1; #X msg 127 420 posX 1 $1; #X msg 20 26 posX 0 $1; #X obj 451 599 dac~; #X obj 19 348 pack 0 0 0 0 0 0 0 0 0 0 0; #N canvas 637 229 450 300 to-tab 0; #X obj 67 65 inlet; #X obj 59 199 outlet; #X msg 52 142 $1 $9 $10 $11 $2 $3 $4 $5 $6 $7 $8 $9 $10 $11 $2 $3 $4; #X connect 0 0 2 0; #X connect 2 0 1 0; #X restore 10 386 pd to-tab; #X obj 8 636 table $0-scan 16; #X msg 19 571 resize 16; #X msg 519 490 2; #X obj 452 509 +~ 2; #X obj 37 261 pmpd 1 10 *******************************; #X msg 440 182 forceX 0 1; #X msg 358 461 mass $1 1 0; #X msg 64 5 0; #X connect 1 0 12 0; #X connect 1 0 15 0; #X connect 2 0 11 0; #X connect 2 0 12 0; #X connect 2 1 15 0; #X connect 3 0 4 0; #X connect 3 0 2 0; #X connect 4 0 3 1; #X connect 5 0 9 0; #X connect 5 1 6 0; #X connect 5 1 1 0; #X connect 5 1 20 0; #X connect 6 0 3 1; #X connect 7 0 5 0; #X connect 8 0 3 0; #X connect 9 0 8 0; #X connect 10 0 9 1; #X connect 13 0 2 1; #X connect 16 0 13 0; #X connect 17 0 10 0; #X connect 18 0 17 0; #X connect 18 0 16 0; #X connect 19 0 23 0; #X connect 19 0 89 0; #X connect 20 0 21 0; #X connect 22 0 24 0; #X connect 25 0 26 0; #X connect 27 0 29 0; #X connect 28 0 36 0; #X connect 29 0 34 0; #X connect 30 0 27 1; #X connect 31 0 30 0; #X connect 32 0 31 0; #X connect 34 0 35 0; #X connect 34 0 91 0; #X connect 35 0 34 1; #X connect 36 0 27 0; #X connect 36 1 37 0; #X connect 37 0 34 1; #X connect 38 0 47 0; #X connect 39 0 47 1; #X connect 40 0 21 0; #X connect 41 0 88 0; #X connect 42 0 43 0; #X connect 43 0 41 0; #X connect 45 0 44 0; #X connect 47 0 76 0; #X connect 48 0 86 0; #X connect 49 0 83 0; #X connect 50 0 80 0; #X connect 52 0 53 0; #X connect 54 0 55 0; #X connect 55 0 52 0; #X connect 55 1 25 0; #X connect 55 2 22 0; #X connect 55 3 20 0; #X connect 56 0 44 1; #X connect 69 0 71 0; #X connect 70 0 89 1; #X connect 71 0 82 0; #X connect 71 0 82 1; #X connect 71 0 44 0; #X connect 72 0 71 1; #X connect 73 0 80 0; #X connect 74 0 89 0; #X connect 75 0 89 0; #X connect 76 0 49 0; #X connect 76 1 89 0; #X connect 77 0 89 0; #X connect 78 0 80 0; #X connect 79 0 89 0; #X connect 80 0 89 0; #X connect 81 0 89 0; #X connect 83 0 84 0; #X connect 84 0 68 0; #X connect 86 0 67 0; #X connect 87 0 88 1; #X connect 88 0 69 0; #X connect 89 0 57 0; #X connect 89 0 83 1; #X connect 89 1 58 0; #X connect 89 1 83 2; #X connect 89 2 59 0; #X connect 89 2 83 3; #X connect 89 3 60 0; #X connect 89 3 83 4; #X connect 89 4 61 0; #X connect 89 4 83 5; #X connect 89 5 62 0; #X connect 89 5 83 6; #X connect 89 6 63 0; #X connect 89 6 83 7; #X connect 89 7 64 0; #X connect 89 7 83 8; #X connect 89 8 65 0; #X connect 89 8 83 9; #X connect 89 9 66 0; #X connect 89 9 83 10; #X connect 90 0 89 0; #X connect 91 0 33 0; #X connect 92 0 81 0;
#N canvas 552 596 585 345 10; #X obj 96 110 r $1; #X obj 114 312 s pmpd; #X obj 80 144 f 0; #X obj 175 64 f $2; #X text 245 242 Id , mass1 , mass2 , K , D; #X obj 173 120 div 10; #X obj 225 120 mod 10; #X floatatom 173 149 5 0 0 0 - - -; #X floatatom 230 156 5 0 0 0 - - -; #X floatatom 220 84 5 0 0 0 - - -; #X obj 88 172 pack 0 0 0; #X obj 44 76 t b b; #X obj 87 204 route 1; #X obj 39 48 r do-links; #X msg 58 279 out 1 $1 $2 1; #X obj 50 226 t a a; #X obj 385 64 r do-masses; #X obj 385 167 div 10; #X obj 437 167 mod 10; #X obj 383 102 f $2; #X obj 353 198 pack 0 0; #X obj 384 128 t f f; #X msg 80 248 link 1 $1 $2 0.01 0.003; #X connect 0 0 2 1; #X connect 2 0 10 0; #X connect 3 0 5 0; #X connect 3 0 6 0; #X connect 5 0 7 0; #X connect 5 0 10 1; #X connect 6 0 8 0; #X connect 6 0 10 2; #X connect 9 0 5 0; #X connect 9 0 6 0; #X connect 10 0 12 0; #X connect 11 0 2 0; #X connect 11 1 3 0; #X connect 12 0 15 0; #X connect 13 0 11 0; #X connect 14 0 1 0; #X connect 15 1 22 0; #X connect 16 0 19 0; #X connect 17 0 20 0; #X connect 18 0 20 1; #X connect 19 0 21 0; #X connect 21 0 17 0; #X connect 21 1 18 0; #X connect 22 0 1 0;
Hallo, cyrille hat gesagt: // cyrille wrote:
after a quick look at your patch :
- i'll not say anymore that my patch are a mess :-)
There's a lot of cruft in it. Attached is the new version, slightly more ordered.
- there is no fixed point.
Okay, I added this now: The first and last masses now are fixed as in your example patch. This allows for models both fixed and free using the matrix editor: The "border" of the editor is used to do connections to "ground" now.
-there is no way to delete a link (ok, i add that to my todo list), so you'll not be able to change the structure in real time.
Yes, this would be nice. I think, Thomas Grill's "dyn" external could be a nice model for this, but I didn't think too deeply about this yet.
-it's a good idea, i don't know what your patch will do...
If you have seen the Csound scansynth tutorial you might get the idea of what I'm trying: http://www.csounds.com/scanned/toot/
My matrix editor is modeled after the matrices used in Csoudn to specify topologies.
-there are problems on the [pmpd] oject : in and out begin from 0, but masses and link beggin from 1. what is the most logic things to do : everything should beggin at 0 or 1?a
I think, in the attached patch I finally got the numbering right. Tomorrow after sleep I will try to understand what exactly I did. ;)
I would suggest to use "programmer's numbering" starting from 0 throughout the whole system. Any personal preferences put aside: The outlet/inlet numbering cannot be changed anymore, as it's starting with 0 everywhere in Pd already, so people probably are used to it already. The same with arrays/tables.
So masses and links starting with 0 would feel natural and it would also make programming easier (for example when using [until]--[counter] loops. Which reminds me: I should have used [repeat] more often.)
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
hello frank,
i did not have lot's of time to look at it, but your new version works...
i have to look a the dyn object, i'm sure i'll find lot's of interesting idea for the future developement of [pmpd].
about the matrix of connection, you can create all the link and change only K and D to create or destroy the link. (if K=D=0 => no link)
i can imagine the result of the diferents structure, but changing the structure in real time can gives inpredictible result (adding or lossing energy...)
ok for the programing numbering of the masses and link. 'ill changes this.
++ Cyr
Frank Barknecht wrote:
Hallo, cyrille hat gesagt: // cyrille wrote:
after a quick look at your patch :
- i'll not say anymore that my patch are a mess :-)
There's a lot of cruft in it. Attached is the new version, slightly more ordered.
- there is no fixed point.
Okay, I added this now: The first and last masses now are fixed as in your example patch. This allows for models both fixed and free using the matrix editor: The "border" of the editor is used to do connections to "ground" now.
-there is no way to delete a link (ok, i add that to my todo list), so you'll not be able to change the structure in real time.
Yes, this would be nice. I think, Thomas Grill's "dyn" external could be a nice model for this, but I didn't think too deeply about this yet.
-it's a good idea, i don't know what your patch will do...
If you have seen the Csound scansynth tutorial you might get the idea of what I'm trying: http://www.csounds.com/scanned/toot/
My matrix editor is modeled after the matrices used in Csoudn to specify topologies.
-there are problems on the [pmpd] oject : in and out begin from 0, but masses and link beggin from 1. what is the most logic things to do : everything should beggin at 0 or 1?a
I think, in the attached patch I finally got the numbering right. Tomorrow after sleep I will try to understand what exactly I did. ;)
I would suggest to use "programmer's numbering" starting from 0 throughout the whole system. Any personal preferences put aside: The outlet/inlet numbering cannot be changed anymore, as it's starting with 0 everywhere in Pd already, so people probably are used to it already. The same with arrays/tables.
So masses and links starting with 0 would feel natural and it would also make programming easier (for example when using [until]--[counter] loops. Which reminds me: I should have used [repeat] more often.)
Ciao
hello frank,
i did not have lot's of time to look at it, but your new version works...
i have to look a the dyn object, i'm sure i'll find lot's of interesting idea for the future developement of [pmpd].
about the matrix of connection, you can create all the link and change only K and D to create or destroy the link. (if K=D=0 => no link)
i can imagine the result of the diferents structure, but changing the structure in real time can gives inpredictible result (adding or lossing energy...)
ok for the programing numbering of the masses and link. 'ill changes this.
++ Cyr
Frank Barknecht wrote:
Hallo, cyrille hat gesagt: // cyrille wrote:
after a quick look at your patch :
- i'll not say anymore that my patch are a mess :-)
There's a lot of cruft in it. Attached is the new version, slightly more ordered.
- there is no fixed point.
Okay, I added this now: The first and last masses now are fixed as in your example patch. This allows for models both fixed and free using the matrix editor: The "border" of the editor is used to do connections to "ground" now.
-there is no way to delete a link (ok, i add that to my todo list), so you'll not be able to change the structure in real time.
Yes, this would be nice. I think, Thomas Grill's "dyn" external could be a nice model for this, but I didn't think too deeply about this yet.
-it's a good idea, i don't know what your patch will do...
If you have seen the Csound scansynth tutorial you might get the idea of what I'm trying: http://www.csounds.com/scanned/toot/
My matrix editor is modeled after the matrices used in Csoudn to specify topologies.
-there are problems on the [pmpd] oject : in and out begin from 0, but masses and link beggin from 1. what is the most logic things to do : everything should beggin at 0 or 1?a
I think, in the attached patch I finally got the numbering right. Tomorrow after sleep I will try to understand what exactly I did. ;)
I would suggest to use "programmer's numbering" starting from 0 throughout the whole system. Any personal preferences put aside: The outlet/inlet numbering cannot be changed anymore, as it's starting with 0 everywhere in Pd already, so people probably are used to it already. The same with arrays/tables.
So masses and links starting with 0 would feel natural and it would also make programming easier (for example when using [until]--[counter] loops. Which reminds me: I should have used [repeat] more often.)
Ciao
Hi Cyrille,
i have to look a the dyn object, i'm sure i'll find lot's of interesting idea for the future developement of [pmpd].
Although there has been some development pause for the dyn library since the first presentation at the pd convention i've been working on it lately and plan to do so for the next future. It is supposed to be a general API for object management in PD, so maybe you would like to use that instead of using code from the dyn~ object. One of the features that i'd like to introduce shortly is the ability to load patches in a click-free manner, made possible by the low-priority callbacks now present in the devel branch (hopefully also in the stable version soon....)
best greetings, Thomas
dear Thomas, with pd devel 0.38 from cvs and your externals from cvs on linux ubuntu i managed to compile dyn, py without any problem but when i try to load them into Pd i get: load_objet: Symbol "py_setup" not found or load_objet: Symbol "dyn_tilde_setup" not found
greetings, vincent
with pd devel 0.38 from cvs and your externals from cvs on linux ubuntu i managed to compile dyn, py without any problem but when i try to load them into Pd i get: load_objet: Symbol "py_setup" not found or load_objet: Symbol "dyn_tilde_setup" not found
matju reported some problems when loading externals on devel_0_38 ... looks similar to me ...
still, i never experienced it, nor do i have any _detailed_ description of this problem ...
please send us a precise description of your setup ... especially, if you are loading any specific externals in advance ...
thanks ... tim
well it is: ubuntu 4.10 gcc 3.3.5 tcl/tk 8.4 pd devel 0.38 from today i only tried with thomas' externals (latest too from cvs) i just launched pd with pd -lib dyn~ otherwise pd seems to work fine
could you tell me what kind of more detailed precisions would you expect?
vincent
Tim Blechmann wrote:
with pd devel 0.38 from cvs and your externals from cvs on linux ubuntu i managed to compile dyn, py without any problem but when i try to load them into Pd i get: load_objet: Symbol "py_setup" not found or load_objet: Symbol "dyn_tilde_setup" not found
matju reported some problems when loading externals on devel_0_38 ... looks similar to me ...
still, i never experienced it, nor do i have any _detailed_ description of this problem ...
please send us a precise description of your setup ... especially, if you are loading any specific externals in advance ...
thanks ... tim
Hi Vincent, did you try to compile and load flext and dyn~ also with Miller's pd version? It would be interesting if that occurs there too.
many thanks, Thomas
Am 02.03.2005 um 13:01 schrieb vincent rioux:
well it is: ubuntu 4.10 gcc 3.3.5 tcl/tk 8.4 pd devel 0.38 from today i only tried with thomas' externals (latest too from cvs) i just launched pd with pd -lib dyn~ otherwise pd seems to work fine
could you tell me what kind of more detailed precisions would you expect?
vincent
Tim Blechmann wrote:
with pd devel 0.38 from cvs and your externals from cvs on linux ubuntu i managed to compile dyn, py without any problem but when i try to load them into Pd i get: load_objet: Symbol "py_setup" not found or load_objet: Symbol "dyn_tilde_setup" not found
matju reported some problems when loading externals on devel_0_38 ... looks similar to me ...
still, i never experienced it, nor do i have any _detailed_ description of this problem ...
please send us a precise description of your setup ... especially, if you are loading any specific externals in advance ...
thanks ... tim
Hi again Thomas,
seems to be much better with 38-4 (no more "object_setup" error message) but i still have this "old" pb with py... grrrr ;-)
pd -lib py Pd: signal 4 pd_gui: pd process exited
Puzzling isn't it ?!
best regards vincent
Thomas Grill wrote:
Hi Vincent, did you try to compile and load flext and dyn~ also with Miller's pd version? It would be interesting if that occurs there too.
many thanks, Thomas
Am 02.03.2005 um 13:01 schrieb vincent rioux:
well it is: ubuntu 4.10 gcc 3.3.5 tcl/tk 8.4 pd devel 0.38 from today i only tried with thomas' externals (latest too from cvs) i just launched pd with pd -lib dyn~ otherwise pd seems to work fine
could you tell me what kind of more detailed precisions would you expect?
vincent
Tim Blechmann wrote:
with pd devel 0.38 from cvs and your externals from cvs on linux ubuntu i managed to compile dyn, py without any problem but when i try to load them into Pd i get: load_objet: Symbol "py_setup" not found or load_objet: Symbol "dyn_tilde_setup" not found
matju reported some problems when loading externals on devel_0_38 ... looks similar to me ...
still, i never experienced it, nor do i have any _detailed_ description of this problem ...
please send us a precise description of your setup ... especially, if you are loading any specific externals in advance ...
thanks ... tim
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hi Vincent, yes, puzzling, because i never encountered this... does -verbose say anything more? Also, did you recompile flext and py for Miller's PD version before loading? (it is necessary)
best greetings, Thomas
vincent rioux schrieb:
Hi again Thomas,
seems to be much better with 38-4 (no more "object_setup" error message) but i still have this "old" pb with py... grrrr ;-)
pd -lib py Pd: signal 4 pd_gui: pd process exited
Puzzling isn't it ?!
best regards vincent
Thomas Grill wrote:
Hi Vincent, did you try to compile and load flext and dyn~ also with Miller's pd version? It would be interesting if that occurs there too.
many thanks, Thomas
Am 02.03.2005 um 13:01 schrieb vincent rioux:
well it is: ubuntu 4.10 gcc 3.3.5 tcl/tk 8.4 pd devel 0.38 from today i only tried with thomas' externals (latest too from cvs) i just launched pd with pd -lib dyn~ otherwise pd seems to work fine
could you tell me what kind of more detailed precisions would you expect?
vincent
Tim Blechmann wrote:
with pd devel 0.38 from cvs and your externals from cvs on linux ubuntu i managed to compile dyn, py without any problem but when i try to load them into Pd i get: load_objet: Symbol "py_setup" not found or load_objet: Symbol "dyn_tilde_setup" not found
matju reported some problems when loading externals on devel_0_38 ... looks similar to me ...
still, i never experienced it, nor do i have any _detailed_ description of this problem ...
please send us a precise description of your setup ... especially, if you are loading any specific externals in advance ...
thanks ... tim
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
yes, puzzling, because i never encountered this... does -verbose say anything more? Also, did you recompile flext and py for Miller's PD version before loading? (it is necessary)
just a guess, but can you try to comment out the line 31 in s_stuff.c to turn of external namespaces?
i'm not really familiar with iohannes's changes to add the namespaces, but it's the difference between devel_ and stable_, that's closest to external loading ...
thanks ... tim
Thomas Grill wrote:
Hi Vincent, yes, puzzling, because i never encountered this... does -verbose say anything more? Also, did you recompile flext and py for Miller's PD version before loading? (it is necessary)
yes i did unfortunately ;-) i know that you did not encounter this pb (we had this discussion a while ago), i am really unsure myself why this happens - it's quite strange (i might have messed up something somewhere). i 'll manage anyway with an older version of py - no worry it's just that i feel a bit frustrated not being able to follow the latest developpement of this really excellent work.
by the way, i just discover recently the send and receive method of "py". this is a really cool feature for changing remotely and in a scripting-manner the configs of a complex Pd patch for example.
Tim, I commented out the line 31 in s_stuff.h // #define QUALIFIED_NAME "/"
rebuilt pd, flext and dyn~ same thing happened.
the puzzle's getting bigger ;-)
cheers vincent
best greetings, Thomas
vincent rioux schrieb:
Hi again Thomas,
seems to be much better with 38-4 (no more "object_setup" error message) but i still have this "old" pb with py... grrrr ;-)
pd -lib py Pd: signal 4 pd_gui: pd process exited
Puzzling isn't it ?!
best regards vincent
Thomas Grill wrote:
Hi Vincent, did you try to compile and load flext and dyn~ also with Miller's pd version? It would be interesting if that occurs there too.
many thanks, Thomas
Am 02.03.2005 um 13:01 schrieb vincent rioux:
well it is: ubuntu 4.10 gcc 3.3.5 tcl/tk 8.4 pd devel 0.38 from today i only tried with thomas' externals (latest too from cvs) i just launched pd with pd -lib dyn~ otherwise pd seems to work fine
could you tell me what kind of more detailed precisions would you expect?
vincent
Tim Blechmann wrote:
with pd devel 0.38 from cvs and your externals from cvs on linux ubuntu i managed to compile dyn, py without any problem but when i try to load them into Pd i get: load_objet: Symbol "py_setup" not found or load_objet: Symbol "dyn_tilde_setup" not found
matju reported some problems when loading externals on devel_0_38 ... looks similar to me ...
still, i never experienced it, nor do i have any _detailed_ description of this problem ...
please send us a precise description of your setup ... especially, if you are loading any specific externals in advance ...
thanks ... tim
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
all right ... what about memory locking ... are you running as root / not as root (please try both), are you running with -rt or without?
can you comment out the #ifdef _POSIX_MEMLOCK block in s_inter.c from line 285 to 299
thanks for the debugging help ... tim
Tim Blechmann wrote:
all right ... what about memory locking ... are you running as root / not as root (please try both), are you running with -rt or without?
no change
can you comment out the #ifdef _POSIX_MEMLOCK block in s_inter.c from line 285 to 299
/* #ifdef _POSIX_MEMLOCK */ /* /* tb: force memlock to physical memory { */ */ /* struct rlimit mlock_limit; */ /* mlock_limit.rlim_cur=0; */ /* /* tb: only if we are really root we can set the hard limit */ */ /* if (getuid()) */ /* mlock_limit.rlim_max=100; */ /* else */ /* mlock_limit.rlim_max=0; */ /* setrlimit(RLIMIT_MEMLOCK,&mlock_limit); */ /* /* } tb */ */
/* if (mlockall(MCL_FUTURE) != -1) */ /* fprintf(stderr, "memory locking enabled.\n"); */ /* #endif */
no change either sorry i am surely not the best person to check for this kind of things, i actually don't quite understand what i am modifying and it is also possible that my system is wrecked somehow
so please don't consider my attempts as rock-solid
i will try to check on an other computer/system when i find time
thanks for the debugging help ... tim
well, thanks for making this exchange possible
vincent
all right ... what about memory locking ... are you running as root / not as root (please try both), are you running with -rt or without?
no change
ok ... slowly i'm running out of ideas ...
i am surely not the best person to check for this kind of things, i actually don't quite understand what i am modifying and it is also possible that my system is wrecked somehow
currently you are the only one who both experiences and debugs this problem ...
the only idea i have at the moment the only idea i have is to make look for older versions of devel_0_38 and try to figure out the date when devel_0_38 started with this behaviour ... i know, this is a lot of work, but you would do the devel_ branch a big favor ... use cvs update -D date to check out a certain date (see man cvs for details) and start a binary search during the last few monthes ...
i'm really sorry, that i can't help you at the moment, but with your help, i'm pretty sure, we can find this bug ...
thanks ... tim
currently you are the only one who both experiences and debugs this problem ...
the only idea i have at the moment the only idea i have is to make look for older versions of devel_0_38 and try to figure out the date when devel_0_38 started with this behaviour ... i know, this is a lot of work, but you would do the devel_ branch a big favor ... use cvs update -D date to check out a certain date (see man cvs for details) and start a binary search during the last few monthes ...
ouch! this sounds quite heavy i might give a try but do you think i should recompile flext and/or externals each time i make a cvs update?
otherwise, Thomas, i finally came back to flext 4.7, dyn and py from your website and everything worked like a charm with pd-038-4 (miller's site) it sounds like i don't manage to use the new system you came with to install flext and your externals on cvs if you wish you can send me your latest py version (tarred), compatible with the previous build system and i will for sure give it a try :-)
vincent
i'm really sorry, that i can't help you at the moment, but with your help, i'm pretty sure, we can find this bug ...
thanks ... tim
Hi Vincent,
currently you are the only one who both experiences and debugs this problem ...
the only idea i have at the moment the only idea i have is to make look for older versions of devel_0_38 and try to figure out the date when devel_0_38 started with this behaviour ... i know, this is a lot of work, but you would do the devel_ branch a big favor ... use cvs update -D date to check out a certain date (see man cvs for details) and start a binary search during the last few monthes ...
ouch! this sounds quite heavy i might give a try but do you think i should recompile flext and/or externals each time i make a cvs update?
you _would_ have to, but honestly, i wouldn't do this either....
i finally came back to flext 4.7, dyn and py from your website and everything worked like a charm with pd-038-4 (miller's site) it sounds like i don't manage to use the new system you came with to install flext and your externals on cvs if you wish you can send me your latest py version (tarred), compatible with the previous build system and i will for sure give it a try :-)
i'll dig into it myself and then try to ask some questions...
many thanks, Thomas
Ok, i can reproduce it now.... obviously i did not test newer devel versions under linux (too many platforms and variations to support.....) Using Miller's version i never had problems.
Tim: i had problems compiling the devel branch: -DUNISTD -DUNIX was missing in the makefile ARCHFLAGS and linking initially failed because -lm -ldl -lpthreads was missing for the PDEXEC linkage
i'll try to find out the source of the missing symbol thing a bit later.
best greetings, Thomas
i finally came back to flext 4.7, dyn and py from your website and everything worked like a charm with pd-038-4 (miller's site) it sounds like i don't manage to use the new system you came with to install flext and your externals on cvs if you wish you can send me your latest py version (tarred), compatible with the previous build system and i will for sure give it a try :-)
i'll dig into it myself and then try to ask some questions...
many thanks, Thomas
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Tim: i had problems compiling the devel branch: -DUNISTD -DUNIX was missing in the makefile ARCHFLAGS and linking initially failed because -lm -ldl -lpthreads was missing for the PDEXEC linkage
thomas:
- did the configure script run correctly? there were problems with some
version of autoconf ... 2. which build system have you been using? the autobuild system or miller's autoconf script?
thanks ... tim
Hi Tim,
- which build system have you been using? the autobuild system or
miller's autoconf script?
good point... there were both the old makefile (Miller's) and the new Makefile (autoconf) in the same folder and surprisingly, makefile was chosen. I should have realized that the makefile had a strange format for having been autocreated..... Apart from some strange misconfiguration in my system everything works well now.
thanks, Thomas
the only idea i have at the moment the only idea i have is to make look for older versions of devel_0_38 and try to figure out the date when devel_0_38 started with this behaviour ... i know, this is a lot of work, but you would do the devel_ branch a big favor ... use cvs update -D date to check out a certain date (see man cvs for details) and start a binary search during the last few monthes ...
ouch! this sounds quite heavy i might give a try but do you think i should recompile flext and/or externals each time i make a cvs update?
i know, thomas started to use the idle callbacks about a month ago ... i doubt you'll have to recompile flext for any other change than that ... if so, you'd see some undefined symbols on the console ...
still, i think, you could also try it with any other non-flext external that doesn't require any of the devel features and thus won't have to be recompiled ...
cheers ... tim
Hi all, that could turn out to be one of the meanest bugs in pd history. Vincent, Ian, Ben, did you also "make install" your built pd, or just run it from the bin folder? The thing is that with the preferred autoconf build method, the pd binary resides in the _src_ folder after compilation. So, most probably, you linked your externals (flext-based, but also others) against the new version (in src), but ran it with an old one in bin. This produces the described error for me, too.
best greetings, Thomas
vincent rioux schrieb:
currently you are the only one who both experiences and debugs this problem ...
the only idea i have at the moment the only idea i have is to make look for older versions of devel_0_38 and try to figure out the date when devel_0_38 started with this behaviour ... i know, this is a lot of work, but you would do the devel_ branch a big favor ... use cvs update -D date to check out a certain date (see man cvs for details) and start a binary search during the last few monthes ...
ouch! this sounds quite heavy i might give a try but do you think i should recompile flext and/or externals each time i make a cvs update?
otherwise, Thomas, i finally came back to flext 4.7, dyn and py from your website and everything worked like a charm with pd-038-4 (miller's site) it sounds like i don't manage to use the new system you came with to install flext and your externals on cvs if you wish you can send me your latest py version (tarred), compatible with the previous build system and i will for sure give it a try :-)
vincent
i'm really sorry, that i can't help you at the moment, but with your help, i'm pretty sure, we can find this bug ...
thanks ... tim
Thomas Grill wrote:
Hi all, that could turn out to be one of the meanest bugs in pd history.
great! happy to know that my name will appear in some kind of relevant entomological history... :-)
Vincent, Ian, Ben, did you also "make install" your built pd, or just run it from the bin folder?
i did use autoconf then make install for sure
The thing is that with the preferred autoconf build method, the pd binary resides in the _src_ folder after compilation.
strange isn't it?
So, most probably, you linked your externals (flext-based, but also others) against the new version (in src), but ran it with an old one in bin. This produces the described error for me, too.
do you mean that "make install" does not install this fresh pd in /usr/local/bin ? then is there a way to automatically install it in its expected place?
anyway thanks a lot thomas this was a nice straight-bug-chase!
best, vincent
yes! I've gotten just that error when recompiling an external with the wrong source/bin configuration. And I did use make install.
Thomas Grill wrote:
Hi all, that could turn out to be one of the meanest bugs in pd history. Vincent, Ian, Ben, did you also "make install" your built pd, or just run it from the bin folder? The thing is that with the preferred autoconf build method, the pd binary resides in the _src_ folder after compilation. So, most probably, you linked your externals (flext-based, but also others) against the new version (in src), but ran it with an old one in bin. This produces the described error for me, too.
best greetings, Thomas
vincent rioux schrieb:
currently you are the only one who both experiences and debugs this problem ...
the only idea i have at the moment the only idea i have is to make look for older versions of devel_0_38 and try to figure out the date when devel_0_38 started with this behaviour ... i know, this is a lot of work, but you would do the devel_ branch a big favor ... use cvs update -D date to check out a certain date (see man cvs for details) and start a binary search during the last few monthes ...
ouch! this sounds quite heavy i might give a try but do you think i should recompile flext and/or externals each time i make a cvs update?
otherwise, Thomas, i finally came back to flext 4.7, dyn and py from your website and everything worked like a charm with pd-038-4 (miller's site) it sounds like i don't manage to use the new system you came with to install flext and your externals on cvs if you wish you can send me your latest py version (tarred), compatible with the previous build system and i will for sure give it a try :-)
vincent
i'm really sorry, that i can't help you at the moment, but with your help, i'm pretty sure, we can find this bug ...
thanks ... tim
f work, but you would do the devel_ branch a big
favor ... use cvs update -D date to check out a certain date (see man cvs for details) and start a binary search during the last few monthes ...
I was getting this error about a month ago, so look further back than that.
i'm really sorry, that i can't help you at the moment, but with your help, i'm pretty sure, we can find this bug ...
thanks ... tim
i 'll manage anyway with an older version of py - no worry it's just that i feel a bit frustrated not being able to follow the latest developpement of this really excellent work.
the frustration is on my side since i wanted to release a new version these days (which is just the cvs version). Not a clever thing to do as long as there are unresolved issues like this one.
best greetings, Thomas
I had a problem compiling devel_0_38 a while back, where every external compiled fine but wouldn't load with the same error Vincent gave. At the time I was too busy to isolate the bug and report it since I had a performance the next day, so I just recompiled CVS _stable_0_38 and it worked again. I'm sorry I don't have more information and I don't have time to go looking for it right now, so I guess you may as well ignore this message ;)
-Ian
Thomas Grill wrote:
i 'll manage anyway with an older version of py - no worry it's just that i feel a bit frustrated not being able to follow the latest developpement of this really excellent work.
the frustration is on my side since i wanted to release a new version these days (which is just the cvs version). Not a clever thing to do as long as there are unresolved issues like this one.
best greetings, Thomas
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Are you on linux or OSX?
I am having similar problems on my OSX box, with Miller's 38-3. Specifically with flext externals compiled from CVS myself, not from those I got from Thomas Grill.
I tried both pool and xsample and they both will not load, have not tried py yet.
My PD exits as yours when I use xgroove. (signal 4)
I ran: % gdb pd (gdb) run -lib xsample
and when pd quits I see that its trapped in an illegal instruction, caused by the symbol Z19xgroove_titlde_setupv.eh
Pool does a similar thing but dies with an unrsolved symbol of: _ZN12flext_single10VersionStrEv.eh
Could you run gdb and tell us what is causing pd to bail?
I'd be curious to hear if we're having the same problem... (with flext!) I've had no issues with other externals.
B, vincent rioux wrote:
Hi again Thomas,
seems to be much better with 38-4 (no more "object_setup" error message) but i still have this "old" pb with py... grrrr ;-)
pd -lib py Pd: signal 4 pd_gui: pd process exited
Puzzling isn't it ?!
best regards vincent
Thomas Grill wrote:
Hi Vincent, did you try to compile and load flext and dyn~ also with Miller's pd version? It would be interesting if that occurs there too.
many thanks, Thomas
Am 02.03.2005 um 13:01 schrieb vincent rioux:
well it is: ubuntu 4.10 gcc 3.3.5 tcl/tk 8.4 pd devel 0.38 from today i only tried with thomas' externals (latest too from cvs) i just launched pd with pd -lib dyn~ otherwise pd seems to work fine
could you tell me what kind of more detailed precisions would you expect?
vincent
Tim Blechmann wrote:
with pd devel 0.38 from cvs and your externals from cvs on linux ubuntu i managed to compile dyn, py without any problem but when i try to load them into Pd i get: load_objet: Symbol "py_setup" not found or load_objet: Symbol "dyn_tilde_setup" not found
matju reported some problems when loading externals on devel_0_38 ... looks similar to me ...
still, i never experienced it, nor do i have any _detailed_ description of this problem ...
please send us a precise description of your setup ... especially, if you are loading any specific externals in advance ...
thanks ... tim
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
I am having similar problems on my OSX box, with Miller's 38-3. Specifically with flext externals compiled from CVS myself, not from those I got from Thomas Grill.
I tried both pool and xsample and they both will not load, have not tried py yet.
hm ... i suppose, there are two different problems ... one flext problem and one pd problem ...
i'd love to get some feedback from matju on his problems with devel ..
cheers .. tim
hello ben,
B. Bogart wrote:
Hi Frank,
I'll take a crack at this, Please correct me where needed Cyrille!
ok
Hmmm indeed there is a single object called "pmpd" I am not sure what this does, but sounds like it allows you to make a physical model without having to connect patch-cords and use pmpd component objects. I'm going to guess all these answers are the same in pmpd as in [mass] [link] etc..
you're right!
The ID in [mass] is used as a receive name so that the render signal can be sent without connecting a cord. Same goes for [link] At the top of most pmpd examples is:
[metro] | [t b b] | | [s m] [s l]
Where the ID of the masses is "m" and the ID for links is "l".
This means you can control the rendering of different structures based on thier ID name.
exept that the t b b is internal of the [pmpd] object. so you do not "nead" the id. it's just usefull if you wish to change the rigidity of a link etc...
I'm guessing the In and Out stuff has to do with comunicating from the internal physical model to the outside patch.
yes
Frank, is there a strong reason you are using the pmpd object, and not using [mass] [lia] etc?? Much easier to start here and I think make many things clear...
So Cyrille, what is the [pmpd] object? Why is there no help for it in CVS? What is it for?
i send an announce for this few mounth ago. every thing i got is on the cvs (3 exemples are the only avalable help)
i made this for diferents reasons : it's a way to improve automatic structure creation. but the 1st goal was to be able to do audio objects. the 2nd goal (thanks to frank) is to make things simpler for data structure connection.
as frank say yesterday about data structure, mouse handling mead to be improve befor i can port pmpd exemple with data structure, but i would really love to have some bouncing structure replacing some boring fader to control an audio synthesis.
anyway, there is no real doc because they are not really finished. i commited them to the cvs in order to collect idea from user.
0.07 could not be compatible with 0.06 : use it at you own risk!
cyrille
Hope I helped a bit Frank.
B>
Frank Barknecht wrote:
Hi,
I have a couple of questions regarding the [pmpd] object. It is not quite clear to me, what the messages to this object mean exactly. Actually I'm very confused about them.
As I see it, there are basically four messages possible to create the dynamic system: mass, link, in, out. All of these take IDs as arguments. I don't understand the meaning of those IDs. For example to create a mass, one uses messages like: mass ID MASS X
MASS and X are easy, but what is this "ID" used for? "link" also takes IDs as argument, but it seems to ignore the ID given to a mass on creation, instead it seems to use its own IDs and it has an ID itself:
link LINK-ID MASS1-ID MASS2-ID K D
Where do I get the mass IDs from? In my experiments, it seems just have to keep track of them myself, and they have nothing to do with the ID I gave to a mass earlier. Or do I get it wrong? Outlet creation (and inlet creation respectively): As I understand it, the format is: out OUT-ID OUTLET MASS-ID AMPLITUDE
AMPLITUDE seems to be a scaling factor. OUT-ID I don't understand at all: what use does it have? Am I right to assume that OUTLET is numbered from 0 to max-outlet-number, where max-outlet-number is the second argument of pmpd minus one? And then MASS-ID: Does it start from 0 as well? Or from 1? Where do I get this ID from? In my experiments, it seems to have to be the MASS-ID I used when creating the "link"s. Sorry for my confusion... Ciao
hello frank,
thanks for trying this object.
Frank Barknecht wrote:
Hi,
I have a couple of questions regarding the [pmpd] object. It is not quite clear to me, what the messages to this object mean exactly. Actually I'm very confused about them.
i'm also very confused. ;-) the aim of pmpd version 0.06 was only to make a prototype and think about it.
the thing that is clear for me now is that is not really usefull to have pmpd and pmpd~ object with exactly the same option (like it is now).
i think in the future i'll split pmpd~ on diferents object (modal~, scan~ and pmpd~)
As I see it, there are basically four messages possible to create the dynamic system: mass, link, in, out.
All of these take IDs as arguments. I don't understand the meaning of those IDs. For example to create a mass, one uses messages like:
mass ID MASS X
MASS and X are easy, but what is this "ID" used for?
id is an identifiant for the masses. (and for the link)
with old pmpd version : when you create a mass object, the parametter are a name, masse and position : the identifiant (id) is here to replace the name of the mass.
you can set the position of a mass at any time by sending a message addressing to the id. this allow you to set position of 1 or more mass in the same time regarding to the stucture...
id is not very really usefull yet. i would like to have a string as id, but a float was faster to code for this prototype.
"link" also takes IDs as argument, but it seems to ignore the ID given to a mass on creation, instead it seems to use its own IDs and it has an ID itself:
link LINK-ID MASS1-ID MASS2-ID K D
in fact it's : link LINK-ID MASS1-creation_number MASS2-creation_number K D
creation_number is 0 for the 1st mass, 1 for the next etc...
2 mass can have the same id (mabee that will change). so link use the creation order of the mass.
i know it's not a very good solution, and i'll be very happy if you have sugestion...
the performances are better this way than with the old way, but i'm not satisfied with usability...
Where do I get the mass IDs from? In my experiments, it seems just have to keep track of them myself, and they have nothing to do with the ID I gave to a mass earlier. Or do I get it wrong?
your right.
Outlet creation (and inlet creation respectively): As I understand it, the format is:
out OUT-ID OUTLET MASS-ID AMPLITUDE
AMPLITUDE seems to be a scaling factor.
yep, scale is a better word. (it's a problem with my bad english)
OUT-ID I don't understand at all: what use does it have?
no one yet. but if you would change the scale factor, then you have to send a message to this specific "out" object. id is the way to address this "out"
if you are familiar with modal synthesis, you'll understand the way is is now.
Am I right to assume that OUTLET is numbered from 0 to max-outlet-number, where max-outlet-number is the second argument of pmpd minus one?
yes : [pmpd 3 4] will create an object with 3 inlet and 4 outlet. so you can create any number of "out" you wish, but they have to be connected to the outlet 0 to 3. (4 outlet)
And then MASS-ID: Does it start from 0 as well? Or from 1? Where do I get this ID from?
you have to choose the id you wish (i think negative id is only for mass that should not move (fixed)).
In my experiments, it seems to have to be the MASS-ID I used when creating the "link"s.
Sorry for my confusion...
well, there is no good documentation, so it's my fault.
i did not make anythig new since 0.06, but new developement should be done befor this summer. so pmpd and pmpd~ will change, and i'm not sure compatibility will be a priority, so use this 2 object at your own risk. (sorry, i'm not happy with the way they are now).
cyr
Ciao
Hallo, cyrille hat gesagt: // cyrille wrote:
in fact it's : link LINK-ID MASS1-creation_number MASS2-creation_number K D
creation_number is 0 for the 1st mass, 1 for the next etc...
Ah, so I basically got that one right. ;)
if you are familiar with modal synthesis, you'll understand the way is is now.
You're always giving me ideas for new stuff to read. So little time ... ;)
Am I right to assume that OUTLET is numbered from 0 to max-outlet-number, where max-outlet-number is the second argument of pmpd minus one?
yes : [pmpd 3 4] will create an object with 3 inlet and 4 outlet. so you can create any number of "out" you wish, but they have to be connected to the outlet 0 to 3. (4 outlet)
And then MASS-ID: Does it start from 0 as well? Or from 1? Where do I get this ID from?
you have to choose the id you wish (i think negative id is only for mass that should not move (fixed)).
Just to really get this into my head: If I use a mass-id of "2" in an "out"-message like "out 1 0 2 0.3" , what will come out of the outlet 0:
- the position of a mass (or all masses) created with id==2 as in
"mass 2 m0 x0" or
the pos. of the mass created as the second mass in the system or
the pos. of the mass created as the third mass?
i did not make anythig new since 0.06, but new developement should be done befor this summer. so pmpd and pmpd~ will change, and i'm not sure compatibility will be a priority, so use this 2 object at your own risk. (sorry, i'm not happy with the way they are now).
This is no problem. I'm actually just playing around with these objects to get a feel for them, some cool sounds and maybe some ideas for improvement. Thanks for providing them!
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
hello,
Frank Barknecht wrote:
...
Just to really get this into my head: If I use a mass-id of "2" in an "out"-message like "out 1 0 2 0.3" , what will come out of the outlet 0:
- the position of a mass (or all masses) created with id==2 as in
"mass 2 m0 x0" or
the pos. of the mass created as the second mass in the system or
the pos. of the mass created as the third mass?
you'll have 3).
i have to add diferents messages to dump all masses (or all masses with the same id) to a specific outlet. so 1) is not yet possible, but in my todo list.
i did not make anythig new since 0.06, but new developement should be done befor this summer. so pmpd and pmpd~ will change, and i'm not sure compatibility will be a priority, so use this 2 object at your own risk. (sorry, i'm not happy with the way they are now).
This is no problem. I'm actually just playing around with these objects to get a feel for them, some cool sounds and maybe some ideas for improvement. Thanks for providing them!
give me all your ideas for improvement please!
thanks for using them cyr
Ciao
Hallo, cyrille hat gesagt: // cyrille wrote:
Frank Barknecht wrote:
Just to really get this into my head: If I use a mass-id of "2" in an "out"-message like "out 1 0 2 0.3" , what will come out of the outlet 0:
- the position of a mass (or all masses) created with id==2 as in
"mass 2 m0 x0" or
the pos. of the mass created as the second mass in the system or
the pos. of the mass created as the third mass?
you'll have 3).
Okay, got it. ;)
But then I suppose there is a bug or something somewhere in the patch I posted in my reply to Ben's mail. Somehow the first two outlets of pmpd don't get any data and stay at 0 or at the position, I set them to with posX messages. I really wonder why this is so. The messages sent to [pmpd] suggest, that even those first two masses should receive forces and change position. Here is a full log:
pmpd: reset pmpd: mass 0 1 0 pmpd: mass 1 1 1 pmpd: mass 2 1 2 pmpd: mass 3 1 3 pmpd: mass 4 1 4 pmpd: mass 5 1 5 pmpd: mass 6 1 6 pmpd: mass 7 1 7 pmpd: mass 8 1 8 pmpd: mass 9 1 9 pmpd: link 1 8 9 0.01 0.003 pmpd: link 1 7 8 0.01 0.003 pmpd: link 1 6 7 0.01 0.003 pmpd: link 1 5 6 0.01 0.003 pmpd: link 1 4 5 0.01 0.003 pmpd: link 1 3 4 0.01 0.003 pmpd: link 1 2 3 0.01 0.003 pmpd: link 1 1 2 0.01 0.003 pmpd: link 1 0 1 0.01 0.003 pmpd: out 1 0 0 0.1 pmpd: out 1 1 1 0.1 pmpd: out 1 2 2 0.1 pmpd: out 1 3 3 0.1 pmpd: out 1 4 4 0.1 pmpd: out 1 5 5 0.1 pmpd: out 1 6 6 0.1 pmpd: out 1 7 7 0.1 pmpd: out 1 8 8 0.1 pmpd: out 1 9 9 0.1
As you see, I create 10 masses, then 10 links with every mass connected to the next mass. Then every mass is connected to its own outlet. Still the outlets 0 and 1 stay silent when the system is set into motion. They also don't seem to react to "forceX 0 0.4" messages. Do you have any idea why this could be so?
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
-
B. Bogart -
cyrille -
Frank Barknecht -
Ian Smith-Heisters -
Thomas Grill -
Tim Blechmann -
vincent rioux