Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Atte André Jensen wrote:
Frank Barknecht wrote:
Yes, it is. ;)
But slightly more tricky is that send/recieve must have the same "problems", but may be more difficult to spot.
indeed, this problem exists.
that is why you should use explicit connections and [trigger] whenever possible.
Often the execution order is only important in confined, local areas of the code and there direct connections are used anyway. But indeed sends and receives can lead to subtle bugs with execution order, too. But as eveywhere in Pd, many similar situations come up all the time, so with experience it will become easier to spot them.
A typical example which is found in many patches is the global beat counter which counts from 0-15 over and over and sends this to a [s BEAT] receiver. If you want to change e.g. a note pattern every time, the counter restarts from 0, you cannot just use [r BEAT]---[select 0], as that may select the new pattern too late, after the first note has already been played. Here you should use a trigger like
0 ... 15 -- beat counter | [t a a] | | | [s PRE-BEAT] | [s BEAT]
Then use [r PRE-BEAT]---[select 0]---"change pattern".
Same for physical modelling with [pmpd]: Link forces have to be computed before you can set the new positions of the masses, so the global metro to drive the pmpd objects also is decorated with a [t b b].
and since we are there: never use [delay] to enforce a certain execution order (it does work, but usually you will get weird (though totally deterministic) results in more complex setups)
Word!
Ciao
Frank Barknecht _ ______footils.org__