Hello everyone,
I am new to this forum and Pd is rather new to me..
I already had some contact with another free modular system called "StudioFactory" which is rather analog. This means there is only one signal-type, connection-order is not (so) important and so on ...pretty CPU-intensive anyways, but that's another story...
So now I have some "problems" with the data-flow in PD. I read and watched some tutorials but something is missing or seems to be wrong there..

1. Cable- or Connection-order:
   When connecting one outlet to multiple inlets/objects the order has to be watched..
   But the order is different with data- and audio-outlets!!!
   Data-Connection: -Placed: 1st -> A, 2nd -> B, 3rd -> C
   -Processed: A -> B -> C
   Audio-Connection: -Placed: 1st -> A, 2nd -> B, 3rd -> C
   -Processed: C -> B -> A
   (Is this correct?!?)

2. [delwrite~], [delread~]/[vd~] -order:
   To get minimum delaylength of "0", it is said to place the [delwrite~] after [delread~]. but that didn't work for me..
   I found out, that one has to place the first object in the audio-line (e.g. the [adc~] that goes into the [delwrite~]) after the [delread~]. The same for [tabread~]/[tabwrite~], and i guess for any (audio-) object...
   Can someone please confirm this?!?
   For further questions just ask..
   Bye Flipp

Sorry Flipp, I really don't understand. but if this helps:

delwrite~ and delread~ shouldn't be connected together, by any cable. they are two separate streams.

if you get help (right/control-click) delread~ you'll see a working example. note that [sig~] can just as happly be exchanged for adc~ and snapshot~ can happily be exchanged for dac~. again get help on the individual objects to learn their function.

Flipp, here's a youtube video on the order of operation in Pd.
Hope it helps. Watch from 1:50

Control objects fanning out to other objects are executed in the order you connect them. You can always ensure that the execute in the order you want them to by using the [trigger] object.

As for the delay lines, as arif said, you can't actually connect them to get one to follow the other. The trick to doing that is to place the [delwrite~] in one subpatch with and [outlet~] and the [delread~] in another with an [inlet~]. The [inlet~] and [outlet~] are just dummies here; you don't need to connect anything to them within the subpatches. Then, connect those two subpatches, and they'll be in the right order.

Take a look at G05.execution.order in the help browser to get a clearer picture of that. If you ever need to enforce the order of audio processing (which I have found to be much rarer than control processing), that's how you do it.

you can tell I don't really use pure data any more... I'm becoming so redundant on this forum!!

Thanks for the replies!
Okay lets take the "G05.execution.order" patch as an example.
Just duplicate the "pd pulse"- subpatch and connect it to the same outputs as the original, delete the original..
Now both versions should work correctly.
This is my explanation:
Since the "pd pulse" is placed at last, and is the first object in the "audio-line" (or "audio-path"), this line will be processed at first (this is what I mean with placed: ABC -> processed: CBA, where C is the "pd pulse"-object).
So the [delwrite~] will get a signal from the "pd pulse" and after that one inlet of the [+~] will get a signal (not so important, but this is the case if you first connect the [+~] and then the [delwrite~] (again ABC->CBA, but for audio-cables) ).
Here another effect comes up: The [+~] will only output its signal, after it has received all incomming audio-signals. As far as I tested, this goes for all audio-objects! (I think this makes sense in terms of processing parallel "realtime"-audio-streams)
So to cut it short: the one inlet of the [+~] is the end of the first audio-line (or audio-path)! After this the next path, containing the [vd~] is processed. So the [vd~] in all is processed after the [delread~] and you have the right order.
I hope I could clarify this...

Could anyone plz try this and present his/her results, in order to clarify that I'm not crazy...

I don't understand your explanation, but, yeah, it works. Of course, the whole point of G05.execution.order is so you don't have to remember that stuff. If it matters, just do what's in the example. And it only really matters with cordless connections like delays and [send~]/[receive~] pairs.

Hey,
plz save this as a *.pd file:

#N canvas 283 218 450 300 10;
#X obj 150 162 print~ a;
#X obj 211 162 print~ b;
#X obj 110 130 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X obj 211 138 +~;
#X obj 150 94 osc~ 440;
#X obj 211 94 osc~ 440;
#X obj 271 94 osc~ 440;
#X connect 2 0 1 0;
#X connect 2 0 0 0;
#X connect 3 0 1 0;
#X connect 4 0 0 0;
#X connect 5 0 3 0;
#X connect 6 0 3 1;

It should show a simple patch with 3 [osc~], 1 [+~] and 2 [print~ a/b] to analyze the whole thing. Each [osc~] is the start of an audio-line/ -path!!
(The order in which you connect the [Bng]-button to the [print~]'s is unimportant since all data (from data-objects) is computed before, or rather between, each audio-cycle.)
Now to get this clear:

1. Delete & recreate the most left [osc~] "A". Hit the bang-button. Watch the console, it first should read "a: ..." then "b: ..."
2. now do the same with the second [osc~] "B" in the middle... Hit bang & watch the console: first "a: ..." then "b: ..."
3. and once more: del & recreate the third [osc~] "C" and so on. Now the console should read first "b: ..." then "a: ..." !

to "1)": the last (most recent) [osc~] created is "A", so the audio-path, lets call it "pA", is run at first. So [print~ a] is processed first, then [print~ b].

to "2)": last [osc~] is "B". Now we have an order from first (oldest) to last (most recent) [osc~] : C,A,B !!
So now fist "B" & "pB" then "A" & "pA" then "C" & "pC" is processed. But "pB" ends at the [+~], because the [+~] waits for the 2nd input ("C") until it can put out something. Since "C" still comes after "A" you again get printed first "a: ..." then "b: ..." in the console!

to "3)": last [osc~] is "C", so the order is like "A,B,C". So at first "C" & "pC" is processed, then "B" & "pB", this makes [+~] put out a signal to [print~ b]. Then "A" & "pA" is processed and the [print~ a] as well. -> first "b: ..." then "a: ..."

This works for "cables" too. Just connect one single [osc~ ] to both (or more) [print~]'s. Hit bang and watch the console, then change the order you connect the [osc~] to the [print~]'s..

That's why the example works if you just recreate the 1st object in an audio-path to make it being processed at first. And that's why I'd like to have some numbers (according to the order of creation) at the objects and cables to determine the order of processing.
But anyways, I hope this helps.
And plz comment if there is something wrong.