Frank Barknecht wrote:

As far as I see it, here you may have an execution order problem, at least the first tim you bang that ascii art. ;)

Is that because of "depth first", which would mean that / sees the 1 at hot inlet first and then carries out 1/0 before the 10 arrives at cold inlet?

Hallo, Atte André Jensen hat gesagt: // Atte André Jensen wrote:

Frank Barknecht wrote:

...

As far as I see it, here you may have an execution order problem, at least the first tim you bang that ascii art. ;)

Is that because of "depth first", which would mean that / sees the 1 at hot inlet first and then carries out 1/0 before the 10 arrives at cold inlet?

Yes: Everytime you have connections fanning out of a message outlet, the order the connections "fire" is not specified. It's practically undefined.

The current implementation of Pd uses the creation order to sort the patch cords, but that's an implementation detail which might change anytime without further notice. So don't rely on it! Instead you have to use a [trigger] to sort the execution order as needed. That's why patches by Pd "pros" use tons of [t b b a b a ...] objects. ;)

See attached example patch which exploits the current implementation to make the issue visible.

Ciao

Frank Barknecht _ ______footils.org__

Atte André Jensen wrote:

I'm a little confused about loadbang, then.

Or maybe not. I guess it's exactly the same...

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.

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__

On Wed, 9 Jul 2008, PSPunch wrote:

I've never noticed send/receive causing unpredictable execution order. Can someone show me an example of under what circumstances this occurs so I can avoid future head aches?

all cases. the receivers are ordered in the order that they are created. if you are currently editing a patch, this is likely to be different from the order that it will be when you will reload the patch. the only way to change the order is to recreate the receivers in the correct order, but really, you should seek a more transparent way of doing things. For example, if [r $0-stuff] has to be received in two distinct phases, make a splitter that uses a [t a a] from [r $0-stuff] to [s $0-stuff-1] and [s $0-stuff-2] so that all receivers that need the information early use $0-stuff-1 and the ones that need it late use $0-stuff-2.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

On Wed, 9 Jul 2008, PSPunch wrote:

I was imagining rather a single send/receive pair messing around with execution order of data entering at once.

This does not happen except for the confusion that is caused by creating those invisible wires across parts of the programme that are presumed to not communicate just because one expects everything to go through [inlet]s and [outlet]s. Even when everything goes through [inlet]s and [outlet]s, there's a fair chance of getting confused on some things sometimes, because visible connections aren't always so visible. Sometimes a connection looks like an actual togetherness, and sometimes it just looks like a line among too many. It's a matter of obfuscation.

I'd rather use almost exclusively [inlet] and [outlet] as means of organising patches, instead of [s]/[r] all over the place, and then I'd use [s]/[r] only in simple patterns that are made as local as possible. This is because it makes programs more obvious.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

yes, [t ....] triggers right to left, that's just a typo