I'm new to PD. Wondering if I can do parallel processing within PD itself. For example: can I take a simple float object and somehow output it to three separate objects simultaneously?

I understand that, normally, sending out a signal from a common output port will proceed according to the sequence in which the outputs were created; also understand that I could sequence in another order with "trigger". But what if I want to output simultaneously to three objects, with no sequencing?

Maybe every procedure in PD is in some sequential queue, and never runs in parallel with another process, which would be a real restriction for my current project.

It would be nice to be able to run some processes in true parallel. Is this possible?

If so, how would I push a float to three objects at the same "TIME?"

I don't think there is any appreciable delay when using [t f f f] so effectively they are in sequential parallel

The outputs go from right to left obviously but that shouldn't pose a problem. Its better than jut using one output whereby the data will reach its destination 'sometime'

Proof is in the pudding - try this

[bang(
|
[t b b]
\/
/\
[timer]
|
[print] -look at the console

what are you doing that requires this?

as far as i know, pd is a 'dataflow' language, and the data will always flow in the order it is created or triggered in.

but like boonier, i'd ask what process you need to trigger where the 0.0001ms or whatever it takes between triggered processes is important?

Trying to create a two-way scattering junction, combined with digital delay lines, ala Kelly Lockbaum, Julius Smith, Perry Cook, et al. The "junction" will be either a subpatch or an abstraction, which will be replicated multiple times in the main patch. So, delays will add up--it is intended to be a realtime audio app.

Also, some of the processes within the "scattering junction" happen in parallel, mathematically speaking (presuming my own understanding is correct.) Anyway, I'll try to figure out a fudge that will minimize any errors that delays introduce within the junction.

Thanks for the clarification. Wish it weren't so that ALL dataflo in pd is sequential, but thought it probably was. At least I know what I have to deal with!

By the way, what about MAXLIB's,REMOTE CONTROL object called
dist. which is used to send to list of receive objects? I presume that, as with trigger, data is sent according to the order of the list?

ok sounds pretty interesting.

just one question now? are you talking about parallel processing of audio, or control signals?

because audio WILL be parallel processed as far as i know.

Will definitely be parallel processing audio signals, but possibly some control data as well. Haven't worked out the details of the latter yet, though.

Pd works with a logical clock - all messages happen in 0 logical time unless you have delays.

Audio works similarly, the delay from [adc~]--[dac~] is exactly the same as the delay from [adc~]--[some complicated process]--[dac~] (unless you use audio delay lines).

However, the difference between Pd's message and audio is thus: messages are triggered depth-first, with only one thread of execution, whereas audio has a "dsp graph" that ensures that things are executed in an order that makes objects get their inputs when needed.

For example:

[adc~]
| \
| \
| \
| \
[*~ 0.5] [lop~ 1000]
|\ /\
| \____/ \
| / \ \
| / \ \
[+~ ] [-~ ]
| /
| /
| /
| /
[dac~]

The order of execution is determined by the graph topology, where numbers indicate absolute order, and letters indicate that the objects might execute in any order:

1. [adc~]
2a: [*~]
2b: [lop~]
3a: [+~]
3b: [-~]
4: [dac~]

But this doesn't matter so much, it's conceptually as if they were executing simultaneously. You only notice there is a dsp graph when you get "dsp loop detected" errors.

The keyword you are looking for regarding 'delay' is "latency", I suspect, and latency depends on the spikyness of CPU load.

For example, for low-latency audio/visual stuff, you generally want to have the audio flat load (lots of computation but roughly constant load) in "pd -rt", and do spiky-load (lots of computation in bursts of 40ms or so) video processing in another instance of "pd -nrt", communicating over local network.

ClaudiusMaximus,

Thanks to your definitive answer, I think I've now got a clearer idea of what's gong on. Also, your advice on how to avoid latency will be heeded. Considering all the above, my project looks like a good candidate for pd. Will be moving forward.

Much thanks to you--and the other posts!!