Hello,
I have a problem with MSD (exactly [MSD2D]). When i send [bang, get massesPos mamasse( to [MSD2D], the output order of the positions of the masses is not the same that the one which was given during the creation.
I'm not sure to be clear, so it is better to see an example ;) (see the attach patch) :
If i create 3 masses in this order : [mass mamasse 1 100 0 1(, [mass mamasse 1 100 2 3( and [mass mamasse 1 100 4 5(. Then if i send [bang, get massesPos mamasse(, i can get from the first outlet of [MSD2D] : [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( [massesPosId mamasse 4 5( Or [massesPosId mamasse 4 5( [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( Or ...
This is not really easy for me because i need to conserve this order :/ It would be better to always get : [massesPosId mamasse 0 1( [massesPosId mamasse 2 3( [massesPosId mamasse 4 5(
Is there a solution with MSD ? With PMPD and dynamic patching, i have no problem, but it is too slow. Number of mass > 10000. ++
Jack
Hi,
On Thu, Jul 08, 2010 at 02:13:34AM +0200, Jack wrote:
I have a problem with MSD (exactly [MSD2D]). When i send [bang, get massesPos mamasse( to [MSD2D], the output order of the positions of the masses is not the same that the one which was given during the creation.
Maybe you'd like to test my [physigs] abstraction? It's a pure vanilla particle simulation that uses dsp objects to drive the mechanics and stores everything in tables, so you always know the particle order. And if you only need the order to be able to store positions in tables, well, they are already in tables, so you don't need to do any copying.
[physigs] has shown comparable speeds with pmpd in my tests. It's a bit thwarted by the calculation of links which has to fall back to message computations, but maybe you don't use links? :)
Get it at http://github.com/footils/physigs and read my paper on the LAC2010 site: http://lac.linuxaudio.org/2010/?page=program
Frank
hello FRanck,
i haven't tested physigs yet (i probably missed the announcement), but it look great.
but why would link has to be computed in message? it is look very unoptimized...
Cyrille
Le 08/07/2010 09:35, Frank Barknecht a écrit :
Hi,
On Thu, Jul 08, 2010 at 02:13:34AM +0200, Jack wrote:
I have a problem with MSD (exactly [MSD2D]). When i send [bang, get massesPos mamasse( to [MSD2D], the output order of the positions of the masses is not the same that the one which was given during the creation.
Maybe you'd like to test my [physigs] abstraction? It's a pure vanilla particle simulation that uses dsp objects to drive the mechanics and stores everything in tables, so you always know the particle order. And if you only need the order to be able to store positions in tables, well, they are already in tables, so you don't need to do any copying.
[physigs] has shown comparable speeds with pmpd in my tests. It's a bit thwarted by the calculation of links which has to fall back to message computations, but maybe you don't use links? :)
Get it at http://github.com/footils/physigs and read my paper on the LAC2010 site: http://lac.linuxaudio.org/2010/?page=program
Ciao
Hi,
On Thu, Jul 08, 2010 at 10:21:52AM +0200, cyrille henry wrote:
i haven't tested physigs yet (i probably missed the announcement), but it look great.
but why would link has to be computed in message? it is look very unoptimized...
Yeah, it's the main drawback. Without this fallback, [physigs] would beat pmpd to pieces and be as fast as MSD. ;-)
But I really hammered by head to my table many hours to find a way to compute links in DSP using only vanilla objects, and I could just not find one. I would love any suggestion how to fix that.
The main problem is the execution order of DSP objects per block. It is not possible to refer to samples calculated later in the DSP chain in earlier objects. ([rpole~] is an object that became necessary because of this restriction in Pd and systems with a similar architecture.)
As links may connect more than one mass point, the forces of all links on a particle have to be accumulated to the table holding the accumulated particle forces. Currently all links forces are calculated with DSP (or "BSP" as I call this process in the paper) and their forces are stored in a table "link-forces". The index there refers to the link, the value is the force.
Other tables map all links to masses on both ends. Tables link-m1 and link-m2 hold mass-ids as values, the indexes into the table (x-value) again refer to the link-id.
To add up all link forces for a single mass, I would have to walk through these links-table, lookup all link-forces connected to this mass, and sum these forces. I didn't manage to do this in a single DSP block so I did it with messages. :(
I my paper I still hoped to be able to solve this with a [tabwriteat~] or [tabpoke~] object that is the signal-equivalent to [tabwrite] for messages, but I later found that it wouldn't help.
Again, any suggestions to optimize this are more than welcome!
Frank
hello,
a MSD link in pure vanila pd, that would be awesome!
i had the same problem when doing the PM on a GPU shader. the solution was to hard coded the link topology in the shader. so it does not help you to create a generic solution...
for physigs i think the solution is the look at the problem the other way around. do not have link oriented table, but mass oriented. i.e : if you wish to connect masse 22 and mass 33 , you have to create a conection1 table that could have 33 in the index 22 and 33 in the index 22. then sending connection1 to a code that compute the link.
you can have an other table to compute a 2nd link with other parameter. all of the links contribution will then be summed with a simple "+~"
of course this is very inefficient if you have 10000 masses and 2 links, since you have to compute forces for all masses. but if all mass n are connected to mass n+1, then all link can be computed in only 2 times. the only optimisation you're missing is that F(1->2) = -F(2->1), so you have to compute 2 time the same link. but this is negligible regarding to the performance boost you'll get...
do you understand my point, and do you think it can be done?
Cyrille
Le 09/07/2010 18:32, Frank Barknecht a écrit :
Hi,
On Thu, Jul 08, 2010 at 10:21:52AM +0200, cyrille henry wrote:
i haven't tested physigs yet (i probably missed the announcement), but it look great.
but why would link has to be computed in message? it is look very unoptimized...
Yeah, it's the main drawback. Without this fallback, [physigs] would beat pmpd to pieces and be as fast as MSD. ;-)
But I really hammered by head to my table many hours to find a way to compute links in DSP using only vanilla objects, and I could just not find one. I would love any suggestion how to fix that.
The main problem is the execution order of DSP objects per block. It is not possible to refer to samples calculated later in the DSP chain in earlier objects. ([rpole~] is an object that became necessary because of this restriction in Pd and systems with a similar architecture.)
As links may connect more than one mass point, the forces of all links on a particle have to be accumulated to the table holding the accumulated particle forces. Currently all links forces are calculated with DSP (or "BSP" as I call this process in the paper) and their forces are stored in a table "link-forces". The index there refers to the link, the value is the force.
Other tables map all links to masses on both ends. Tables link-m1 and link-m2 hold mass-ids as values, the indexes into the table (x-value) again refer to the link-id.
To add up all link forces for a single mass, I would have to walk through these links-table, lookup all link-forces connected to this mass, and sum these forces. I didn't manage to do this in a single DSP block so I did it with messages. :(
I my paper I still hoped to be able to solve this with a [tabwriteat~] or [tabpoke~] object that is the signal-equivalent to [tabwrite] for messages, but I later found that it wouldn't help.
Again, any suggestions to optimize this are more than welcome!
Ciao
Hi,
On Fri, Jul 09, 2010 at 07:18:22PM +0200, cyrille henry wrote:
a MSD link in pure vanila pd, that would be awesome!
I did run [physigs] on the iPhone with RjDj already and even with the link-force-distribution made with messages, it's no problem to run a chain for scanned synthesis that is 256 points long or longer.
i had the same problem when doing the PM on a GPU shader. the solution was to hard coded the link topology in the shader. so it does not help you to create a generic solution...
for physigs i think the solution is the look at the problem the other way around. do not have link oriented table, but mass oriented. i.e : if you wish to connect masse 22 and mass 33 , you have to create a conection1 table that could have 33 in the index 22 and 33 in the index 22. then sending connection1 to a code that compute the link.
you can have an other table to compute a 2nd link with other parameter. all of the links contribution will then be summed with a simple "+~"
of course this is very inefficient if you have 10000 masses and 2 links, since you have to compute forces for all masses. but if all mass n are connected to mass n+1, then all link can be computed in only 2 times. the only optimisation you're missing is that F(1->2) = -F(2->1), so you have to compute 2 time the same link. but this is negligible regarding to the performance boost you'll get...
do you understand my point, and do you think it can be done?
It's a good idea, I will try this. When I hit the wall with my current approach, I already thought that probably I'd need to try some different approaches on the level of the basic data structures used. Actually that's the nice thing about the BSP idiom described in my paper: It is all patched in Pd without any compiled externals used, so it's very easy to try out different optimizations or algorithms for a "normal" user. It's also possible to design "un-physical" modelling systems that violate the usual Newtonian rules or to get specific meta-information like center-of-gravity of link-forces or so very efficiently and use these meta-infos to drive other processes. The latter made me start a little feature extraction library similar to William Brent's timbreID/tabletool objects, but with a vanilla taste to use in RjDj or similar environments.
I also started to clone your pm-mapping objects, see attachment, which probably uses some list-abs and rj objects (http://github.com/rjdj/rjlib) IIRC.
Frank
Hi Frank,
physigs looks awesome. And it even comes with a video presentation & a
paper. Wow.
Am 10.07.2010 um 10:36 schrieb Frank Barknecht:
I also started to clone your pm-mapping objects, see attachment, which probably uses some list-abs and rj objects (http://github.com/rjdj/rjlib ) IIRC.
I seem to be missing "gem-display-fixmob". Is it a missing abstraction
or due to my probably older gem version?
I'm trying with 0.41.4-extended on 10.5.8.
Regarding the rjdj example in the video, am I right in assuming its
just a matter of filling the force-x /y tables with const (accel
value) before each link bang?
Thanks,
g.
Hi Georg,
On Sat, Jul 10, 2010 at 01:13:52PM +0200, Georg Bosch wrote:
physigs looks awesome. And it even comes with a video presentation & a paper. Wow.
Thanks a lot - I welcome any feedback.
Am 10.07.2010 um 10:36 schrieb Frank Barknecht:
I also started to clone your pm-mapping objects, see attachment, which probably uses some list-abs and rj objects (http://github.com/rjdj/rjlib) IIRC.
I seem to be missing "gem-display-fixmob". Is it a missing abstraction or due to my probably older gem version? I'm trying with 0.41.4-extended on 10.5.8.
I attached it. It's still a bit rough, but should be workable.
Regarding the rjdj example in the video, am I right in assuming its just a matter of filling the force-x /y tables with const (accel value) before each link bang?
I can't check currently how I did it in the RjDj scene, but in general you apply external forces to masses simply by manipulating the internal force tables. You can either do this by directly using the internal table name which is made up from the $arg1-tag and the respective state-table suffix (i.e. MYNAME-force-x, MYNAME-force-y, ...) or use the special "table" method of the last inlet. To set all y-forces for one world step to 10, use "table force-y const 10" for example. For the RjDj accelerometer, you can directly feed the accel values like this.
Looking forward to a "Multi-Bouncy.rj" :) Unfortunatly the graphics in RjDj are too slow to animate more than a handful of particles.
Frank
Hello Frank,
Thanks for your answer. I will take a look at your [physigs] abstraction. For information, i have 10000 mobiles masses + 10000 immovables masses + 10000 links. So a lot of links ;) ++
Jack
Le jeudi 08 juillet 2010 à 09:35 +0200, Frank Barknecht a écrit :
Hi,
On Thu, Jul 08, 2010 at 02:13:34AM +0200, Jack wrote:
I have a problem with MSD (exactly [MSD2D]). When i send [bang, get massesPos mamasse( to [MSD2D], the output order of the positions of the masses is not the same that the one which was given during the creation.
Maybe you'd like to test my [physigs] abstraction? It's a pure vanilla particle simulation that uses dsp objects to drive the mechanics and stores everything in tables, so you always know the particle order. And if you only need the order to be able to store positions in tables, well, they are already in tables, so you don't need to do any copying.
[physigs] has shown comparable speeds with pmpd in my tests. It's a bit thwarted by the calculation of links which has to fall back to message computations, but maybe you don't use links? :)
Get it at http://github.com/footils/physigs and read my paper on the LAC2010 site: http://lac.linuxaudio.org/2010/?page=program
Ciao
Very interresting examples in your movie. One bang, one switch and everything is compute in one block ;) [physigs] seems impressive (though there is some problems with links, if i understand) ! Nice job. ++
Jack
Le jeudi 08 juillet 2010 à 09:35 +0200, Frank Barknecht a écrit :
Hi,
On Thu, Jul 08, 2010 at 02:13:34AM +0200, Jack wrote:
I have a problem with MSD (exactly [MSD2D]). When i send [bang, get massesPos mamasse( to [MSD2D], the output order of the positions of the masses is not the same that the one which was given during the creation.
Maybe you'd like to test my [physigs] abstraction? It's a pure vanilla particle simulation that uses dsp objects to drive the mechanics and stores everything in tables, so you always know the particle order. And if you only need the order to be able to store positions in tables, well, they are already in tables, so you don't need to do any copying.
[physigs] has shown comparable speeds with pmpd in my tests. It's a bit thwarted by the calculation of links which has to fall back to message computations, but maybe you don't use links? :)
Get it at http://github.com/footils/physigs and read my paper on the LAC2010 site: http://lac.linuxaudio.org/2010/?page=program
Ciao
did the massesPosL message could help you?
otherwise, you have the solution to use frank trick : use the output of the get message to write in a table, and then read the table...
c
Le 08/07/2010 02:13, Jack a écrit :
Hello,
I have a problem with MSD (exactly [MSD2D]). When i send [bang, get massesPos mamasse( to [MSD2D], the output order of the positions of the masses is not the same that the one which was given during the creation.
I'm not sure to be clear, so it is better to see an example ;) (see the attach patch) :
If i create 3 masses in this order : [mass mamasse 1 100 0 1(, [mass mamasse 1 100 2 3( and [mass mamasse 1 100 4 5(. Then if i send [bang, get massesPos mamasse(, i can get from the first outlet of [MSD2D] : [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( [massesPosId mamasse 4 5( Or [massesPosId mamasse 4 5( [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( Or ...
This is not really easy for me because i need to conserve this order :/ It would be better to always get : [massesPosId mamasse 0 1( [massesPosId mamasse 2 3( [massesPosId mamasse 4 5(
Is there a solution with MSD ? With PMPD and dynamic patching, i have no problem, but it is too slow. Number of mass> 10000. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello Cyrille,
Thanks for your answer. My system has 10000 mobiles masses, 10000 immovables masses and 10000 links. I tried with [massesPosL( message. But the problem is i got the position of the immovables masses. Maybe i can start to create the 10000 immovables masses, then the 10000 mobiles masses and split the list at 10000 (the list is obtained with [massesPosL(). Or i can split 4 elements then split 2 elements. I will try... ++
Jack
Le jeudi 08 juillet 2010 à 09:46 +0200, cyrille henry a écrit :
did the massesPosL message could help you?
otherwise, you have the solution to use frank trick : use the output of the get message to write in a table, and then read the table...
c
Le 08/07/2010 02:13, Jack a écrit :
Hello,
I have a problem with MSD (exactly [MSD2D]). When i send [bang, get massesPos mamasse( to [MSD2D], the output order of the positions of the masses is not the same that the one which was given during the creation.
I'm not sure to be clear, so it is better to see an example ;) (see the attach patch) :
If i create 3 masses in this order : [mass mamasse 1 100 0 1(, [mass mamasse 1 100 2 3( and [mass mamasse 1 100 4 5(. Then if i send [bang, get massesPos mamasse(, i can get from the first outlet of [MSD2D] : [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( [massesPosId mamasse 4 5( Or [massesPosId mamasse 4 5( [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( Or ...
This is not really easy for me because i need to conserve this order :/ It would be better to always get : [massesPosId mamasse 0 1( [massesPosId mamasse 2 3( [massesPosId mamasse 4 5(
Is there a solution with MSD ? With PMPD and dynamic patching, i have no problem, but it is too slow. Number of mass> 10000. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Super ! It is working fine with [massesPosL(, a [until], a [list split 4] and a [unpack f f]. Thanx a lot ! ++
Jack
Le jeudi 08 juillet 2010 à 13:24 +0200, Jack a écrit :
Hello Cyrille,
Thanks for your answer. My system has 10000 mobiles masses, 10000 immovables masses and 10000 links. I tried with [massesPosL( message. But the problem is i got the position of the immovables masses. Maybe i can start to create the 10000 immovables masses, then the 10000 mobiles masses and split the list at 10000 (the list is obtained with [massesPosL(). Or i can split 4 elements then split 2 elements. I will try... ++
Jack
Le jeudi 08 juillet 2010 à 09:46 +0200, cyrille henry a écrit :
did the massesPosL message could help you?
otherwise, you have the solution to use frank trick : use the output of the get message to write in a table, and then read the table...
c
Le 08/07/2010 02:13, Jack a écrit :
Hello,
I have a problem with MSD (exactly [MSD2D]). When i send [bang, get massesPos mamasse( to [MSD2D], the output order of the positions of the masses is not the same that the one which was given during the creation.
I'm not sure to be clear, so it is better to see an example ;) (see the attach patch) :
If i create 3 masses in this order : [mass mamasse 1 100 0 1(, [mass mamasse 1 100 2 3( and [mass mamasse 1 100 4 5(. Then if i send [bang, get massesPos mamasse(, i can get from the first outlet of [MSD2D] : [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( [massesPosId mamasse 4 5( Or [massesPosId mamasse 4 5( [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( Or ...
This is not really easy for me because i need to conserve this order :/ It would be better to always get : [massesPosId mamasse 0 1( [massesPosId mamasse 2 3( [massesPosId mamasse 4 5(
Is there a solution with MSD ? With PMPD and dynamic patching, i have no problem, but it is too slow. Number of mass> 10000. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hmm, in fact, this system is as slow as PMPD (even more !) even using [get massesPos mamasse(. The problem could come that i have 10000 times : mobile mass <-> link <-> immovable mass ? Is it preferable to have this system managed by PMPD instead of MSD ? ++
Jack
Le jeudi 08 juillet 2010 à 13:31 +0200, Jack a écrit :
Super ! It is working fine with [massesPosL(, a [until], a [list split 4] and a [unpack f f]. Thanx a lot ! ++
Jack
Le jeudi 08 juillet 2010 à 13:24 +0200, Jack a écrit :
Hello Cyrille,
Thanks for your answer. My system has 10000 mobiles masses, 10000 immovables masses and 10000 links. I tried with [massesPosL( message. But the problem is i got the position of the immovables masses. Maybe i can start to create the 10000 immovables masses, then the 10000 mobiles masses and split the list at 10000 (the list is obtained with [massesPosL(). Or i can split 4 elements then split 2 elements. I will try... ++
Jack
Le jeudi 08 juillet 2010 à 09:46 +0200, cyrille henry a écrit :
did the massesPosL message could help you?
otherwise, you have the solution to use frank trick : use the output of the get message to write in a table, and then read the table...
c
Le 08/07/2010 02:13, Jack a écrit :
Hello,
I have a problem with MSD (exactly [MSD2D]). When i send [bang, get massesPos mamasse( to [MSD2D], the output order of the positions of the masses is not the same that the one which was given during the creation.
I'm not sure to be clear, so it is better to see an example ;) (see the attach patch) :
If i create 3 masses in this order : [mass mamasse 1 100 0 1(, [mass mamasse 1 100 2 3( and [mass mamasse 1 100 4 5(. Then if i send [bang, get massesPos mamasse(, i can get from the first outlet of [MSD2D] : [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( [massesPosId mamasse 4 5( Or [massesPosId mamasse 4 5( [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( Or ...
This is not really easy for me because i need to conserve this order :/ It would be better to always get : [massesPosId mamasse 0 1( [massesPosId mamasse 2 3( [massesPosId mamasse 4 5(
Is there a solution with MSD ? With PMPD and dynamic patching, i have no problem, but it is too slow. Number of mass> 10000. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
could you try to create the mobil masses, then the fixed masses, and use a list split 10000?
couls you check what is the slow part of your patch : i bet msd use about 10% cpu, everything else is used by the use of the data. c
Le 08/07/2010 14:53, Jack a écrit :
Hmm, in fact, this system is as slow as PMPD (even more !) even using [get massesPos mamasse(. The problem could come that i have 10000 times : mobile mass<-> link <-> immovable mass ? Is it preferable to have this system managed by PMPD instead of MSD ? ++
Jack
Le jeudi 08 juillet 2010 à 13:31 +0200, Jack a écrit :
Super ! It is working fine with [massesPosL(, a [until], a [list split 4] and a [unpack f f]. Thanx a lot ! ++
Jack
Le jeudi 08 juillet 2010 à 13:24 +0200, Jack a écrit :
Hello Cyrille,
Thanks for your answer. My system has 10000 mobiles masses, 10000 immovables masses and 10000 links. I tried with [massesPosL( message. But the problem is i got the position of the immovables masses. Maybe i can start to create the 10000 immovables masses, then the 10000 mobiles masses and split the list at 10000 (the list is obtained with [massesPosL(). Or i can split 4 elements then split 2 elements. I will try... ++
Jack
Le jeudi 08 juillet 2010 à 09:46 +0200, cyrille henry a écrit :
did the massesPosL message could help you?
otherwise, you have the solution to use frank trick : use the output of the get message to write in a table, and then read the table...
c
Le 08/07/2010 02:13, Jack a écrit :
Hello,
I have a problem with MSD (exactly [MSD2D]). When i send [bang, get massesPos mamasse( to [MSD2D], the output order of the positions of the masses is not the same that the one which was given during the creation.
I'm not sure to be clear, so it is better to see an example ;) (see the attach patch) :
If i create 3 masses in this order : [mass mamasse 1 100 0 1(, [mass mamasse 1 100 2 3( and [mass mamasse 1 100 4 5(. Then if i send [bang, get massesPos mamasse(, i can get from the first outlet of [MSD2D] : [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( [massesPosId mamasse 4 5( Or [massesPosId mamasse 4 5( [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( Or ...
This is not really easy for me because i need to conserve this order :/ It would be better to always get : [massesPosId mamasse 0 1( [massesPosId mamasse 2 3( [massesPosId mamasse 4 5(
Is there a solution with MSD ? With PMPD and dynamic patching, i have no problem, but it is too slow. Number of mass> 10000. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le jeudi 08 juillet 2010 à 17:03 +0200, cyrille henry a écrit :
could you try to create the mobil masses, then the fixed masses, and use a list split 10000?
OK, done. In fact, with 10000 mobiles masses and 10000 fixed masses, if i want position of the mobiles masses, i need to use a list split with 10000*2=20000 (for X and Y).
So i have something like this :
[MSD2D]
|
[route massesPosL]
|
[list split 20000]
|
[t l l]
|
[list length]
|
[until]
|
[list append]
| /
[list split 2]
|
[unpack f f]
|
etc. with gemhead
Maybe i miss something, but even with a structure with 2500 mobiles masses, this is slow. Thanx for your help. ++
Jack
couls you check what is the slow part of your patch : i bet msd use about 10% cpu, everything else is used by the use of the data. c
Le 08/07/2010 14:53, Jack a écrit :
Hmm, in fact, this system is as slow as PMPD (even more !) even using [get massesPos mamasse(. The problem could come that i have 10000 times : mobile mass<-> link <-> immovable mass ? Is it preferable to have this system managed by PMPD instead of MSD ? ++
Jack
Le jeudi 08 juillet 2010 à 13:31 +0200, Jack a écrit :
Super ! It is working fine with [massesPosL(, a [until], a [list split 4] and a [unpack f f]. Thanx a lot ! ++
Jack
Le jeudi 08 juillet 2010 à 13:24 +0200, Jack a écrit :
Hello Cyrille,
Thanks for your answer. My system has 10000 mobiles masses, 10000 immovables masses and 10000 links. I tried with [massesPosL( message. But the problem is i got the position of the immovables masses. Maybe i can start to create the 10000 immovables masses, then the 10000 mobiles masses and split the list at 10000 (the list is obtained with [massesPosL(). Or i can split 4 elements then split 2 elements. I will try... ++
Jack
Le jeudi 08 juillet 2010 à 09:46 +0200, cyrille henry a écrit :
did the massesPosL message could help you?
otherwise, you have the solution to use frank trick : use the output of the get message to write in a table, and then read the table...
c
Le 08/07/2010 02:13, Jack a écrit :
Hello,
I have a problem with MSD (exactly [MSD2D]). When i send [bang, get massesPos mamasse( to [MSD2D], the output order of the positions of the masses is not the same that the one which was given during the creation.
I'm not sure to be clear, so it is better to see an example ;) (see the attach patch) :
If i create 3 masses in this order : [mass mamasse 1 100 0 1(, [mass mamasse 1 100 2 3( and [mass mamasse 1 100 4 5(. Then if i send [bang, get massesPos mamasse(, i can get from the first outlet of [MSD2D] : [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( [massesPosId mamasse 4 5( Or [massesPosId mamasse 4 5( [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( Or ...
This is not really easy for me because i need to conserve this order :/ It would be better to always get : [massesPosId mamasse 0 1( [massesPosId mamasse 2 3( [massesPosId mamasse 4 5(
Is there a solution with MSD ? With PMPD and dynamic patching, i have no problem, but it is too slow. Number of mass> 10000. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
ok. could you try to remove the gemhead, and check that the slow part is Gem, not MSD?
do you use the double gemhead technics, or the repeat technic? c
Le 08/07/2010 18:50, Jack a écrit :
Le jeudi 08 juillet 2010 à 17:03 +0200, cyrille henry a écrit :
could you try to create the mobil masses, then the fixed masses, and use a list split 10000?
OK, done. In fact, with 10000 mobiles masses and 10000 fixed masses, if i want position of the mobiles masses, i need to use a list split with 10000*2=20000 (for X and Y).
So i have something like this : [MSD2D] | [route massesPosL] | [list split 20000] | [t l l] |
[list length] |
[until]
|
[list append] | / [list split 2] | [unpack f f] | etc. with gemheadMaybe i miss something, but even with a structure with 2500 mobiles masses, this is slow. Thanx for your help. ++
Jack
couls you check what is the slow part of your patch : i bet msd use about 10% cpu, everything else is used by the use of the data. c
Le 08/07/2010 14:53, Jack a écrit :
Hmm, in fact, this system is as slow as PMPD (even more !) even using [get massesPos mamasse(. The problem could come that i have 10000 times : mobile mass<-> link <-> immovable mass ? Is it preferable to have this system managed by PMPD instead of MSD ? ++
Jack
Le jeudi 08 juillet 2010 à 13:31 +0200, Jack a écrit :
Super ! It is working fine with [massesPosL(, a [until], a [list split 4] and a [unpack f f]. Thanx a lot ! ++
Jack
Le jeudi 08 juillet 2010 à 13:24 +0200, Jack a écrit :
Hello Cyrille,
Thanks for your answer. My system has 10000 mobiles masses, 10000 immovables masses and 10000 links. I tried with [massesPosL( message. But the problem is i got the position of the immovables masses. Maybe i can start to create the 10000 immovables masses, then the 10000 mobiles masses and split the list at 10000 (the list is obtained with [massesPosL(). Or i can split 4 elements then split 2 elements. I will try... ++
Jack
Le jeudi 08 juillet 2010 à 09:46 +0200, cyrille henry a écrit :
did the massesPosL message could help you?
otherwise, you have the solution to use frank trick : use the output of the get message to write in a table, and then read the table...
c
Le 08/07/2010 02:13, Jack a écrit : > Hello, > > I have a problem with MSD (exactly [MSD2D]). When i send [bang, get > massesPos mamasse( to [MSD2D], the output order of the positions of the > masses is not the same that the one which was given during the creation. > > I'm not sure to be clear, so it is better to see an example ;) (see the > attach patch) : > > If i create 3 masses in this order : [mass mamasse 1 100 0 1(, [mass > mamasse 1 100 2 3( and [mass mamasse 1 100 4 5(. > Then if i send [bang, get massesPos mamasse(, i can get from the first > outlet of [MSD2D] : > [massesPosId mamasse 2 3( > [massesPosId mamasse 0 1( > [massesPosId mamasse 4 5( > Or > [massesPosId mamasse 4 5( > [massesPosId mamasse 2 3( > [massesPosId mamasse 0 1( > Or > ... > > This is not really easy for me because i need to conserve this order :/ > It would be better to always get : > [massesPosId mamasse 0 1( > [massesPosId mamasse 2 3( > [massesPosId mamasse 4 5( > > Is there a solution with MSD ? > With PMPD and dynamic patching, i have no problem, but it is too slow. > Number of mass> 10000. > ++ > > Jack > > > > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Better and faster with a [drip] and [spigot]s ! :) Inteads of :
[t l l]
|
[list length]
|
[until]
|
[list append]
| /
[list split 2]
|
[unpack f f]
++
Jack
Le jeudi 08 juillet 2010 à 19:16 +0200, cyrille henry a écrit :
ok. could you try to remove the gemhead, and check that the slow part is Gem, not MSD?
do you use the double gemhead technics, or the repeat technic? c
Le 08/07/2010 18:50, Jack a écrit :
Le jeudi 08 juillet 2010 à 17:03 +0200, cyrille henry a écrit :
could you try to create the mobil masses, then the fixed masses, and use a list split 10000?
OK, done. In fact, with 10000 mobiles masses and 10000 fixed masses, if i want position of the mobiles masses, i need to use a list split with 10000*2=20000 (for X and Y).
So i have something like this : [MSD2D] | [route massesPosL] | [list split 20000] | [t l l] |
[list length] |
[until]
|
[list append] | / [list split 2] | [unpack f f] | etc. with gemheadMaybe i miss something, but even with a structure with 2500 mobiles masses, this is slow. Thanx for your help. ++
Jack
couls you check what is the slow part of your patch : i bet msd use about 10% cpu, everything else is used by the use of the data. c
Le 08/07/2010 14:53, Jack a écrit :
Hmm, in fact, this system is as slow as PMPD (even more !) even using [get massesPos mamasse(. The problem could come that i have 10000 times : mobile mass<-> link <-> immovable mass ? Is it preferable to have this system managed by PMPD instead of MSD ? ++
Jack
Le jeudi 08 juillet 2010 à 13:31 +0200, Jack a écrit :
Super ! It is working fine with [massesPosL(, a [until], a [list split 4] and a [unpack f f]. Thanx a lot ! ++
Jack
Le jeudi 08 juillet 2010 à 13:24 +0200, Jack a écrit :
Hello Cyrille,
Thanks for your answer. My system has 10000 mobiles masses, 10000 immovables masses and 10000 links. I tried with [massesPosL( message. But the problem is i got the position of the immovables masses. Maybe i can start to create the 10000 immovables masses, then the 10000 mobiles masses and split the list at 10000 (the list is obtained with [massesPosL(). Or i can split 4 elements then split 2 elements. I will try... ++
Jack
Le jeudi 08 juillet 2010 à 09:46 +0200, cyrille henry a écrit : > did the massesPosL message could help you? > > otherwise, you have the solution to use frank trick : > use the output of the get message to write in a table, and then read the table... > > c > > Le 08/07/2010 02:13, Jack a écrit : >> Hello, >> >> I have a problem with MSD (exactly [MSD2D]). When i send [bang, get >> massesPos mamasse( to [MSD2D], the output order of the positions of the >> masses is not the same that the one which was given during the creation. >> >> I'm not sure to be clear, so it is better to see an example ;) (see the >> attach patch) : >> >> If i create 3 masses in this order : [mass mamasse 1 100 0 1(, [mass >> mamasse 1 100 2 3( and [mass mamasse 1 100 4 5(. >> Then if i send [bang, get massesPos mamasse(, i can get from the first >> outlet of [MSD2D] : >> [massesPosId mamasse 2 3( >> [massesPosId mamasse 0 1( >> [massesPosId mamasse 4 5( >> Or >> [massesPosId mamasse 4 5( >> [massesPosId mamasse 2 3( >> [massesPosId mamasse 0 1( >> Or >> ... >> >> This is not really easy for me because i need to conserve this order :/ >> It would be better to always get : >> [massesPosId mamasse 0 1( >> [massesPosId mamasse 2 3( >> [massesPosId mamasse 4 5( >> >> Is there a solution with MSD ? >> With PMPD and dynamic patching, i have no problem, but it is too slow. >> Number of mass> 10000. >> ++ >> >> Jack >> >> >> >> >> >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 08/07/2010 13:24, Jack a écrit :
Hello Cyrille,
Thanks for your answer. My system has 10000 mobiles masses, 10000 immovables masses and 10000 links. I tried with [massesPosL( message. But the problem is i got the position of the immovables masses. Maybe i can start to create the 10000 immovables masses, then the 10000 mobiles masses and split the list at 10000 (the list is obtained with [massesPosL().
yes, that's what i usually do.
Or i can split 4 elements then split 2 elements.
this will create more list operation...
C
I will try... ++
Jack
Le jeudi 08 juillet 2010 à 09:46 +0200, cyrille henry a écrit :
did the massesPosL message could help you?
otherwise, you have the solution to use frank trick : use the output of the get message to write in a table, and then read the table...
c
Le 08/07/2010 02:13, Jack a écrit :
Hello,
I have a problem with MSD (exactly [MSD2D]). When i send [bang, get massesPos mamasse( to [MSD2D], the output order of the positions of the masses is not the same that the one which was given during the creation.
I'm not sure to be clear, so it is better to see an example ;) (see the attach patch) :
If i create 3 masses in this order : [mass mamasse 1 100 0 1(, [mass mamasse 1 100 2 3( and [mass mamasse 1 100 4 5(. Then if i send [bang, get massesPos mamasse(, i can get from the first outlet of [MSD2D] : [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( [massesPosId mamasse 4 5( Or [massesPosId mamasse 4 5( [massesPosId mamasse 2 3( [massesPosId mamasse 0 1( Or ...
This is not really easy for me because i need to conserve this order :/ It would be better to always get : [massesPosId mamasse 0 1( [massesPosId mamasse 2 3( [massesPosId mamasse 4 5(
Is there a solution with MSD ? With PMPD and dynamic patching, i have no problem, but it is too slow. Number of mass> 10000. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list