[PD] get the position of the mass in the same order than the creation with MSD

[Frank Barknecht]

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
-- 
Frank