The same possible one-tick delay happens with throw~/catch. There's no way around such a delay when the reading object comes before the writing one - it's a fundamental limitation of digital signal processing.

Pd ought to offer a better way to force order of execution than the ones that are available, but that's an ongoing question for me :)

Miller

On Mon, Sep 12, 2016 at 11:58:33PM +0200, oliver wrote:

jlistshit wrote:

...

Use throw~ and catch~ instead of send~ and receive~.

hi,

sorry, not possible. only one catch~ for multiple throw~ objects

i need it the other way round ...

btw: is there a technical difference between send~ and throw~ ?

thanks anyway

oliver

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

On 09/13/2016 08:24 PM, oliver wrote:

i'm not really sure i implemented everything the right way, but in my tests i came to the conclusion, that the send~ object has to be created AFTER the corresponding receives~ (regardless of subpatches) to work correctly in this setup.

can you confirm this ?

oh no, please don't do this. never. ever. it's a sure way to call the wrath of the gods upon you.

depending on the creation order is the signal domain equivalent of the dreaded fan-out in the message domain. in the message domain use [trigger]. in the signal domain, use connections.

it's quite simple: if you have two subpatches/abstractions that are connected via a signal-connection, then the "upper" subpatch will always be evaluated before the "lower" subpatch; simply because the lower one is waiting for the upper one to produce data - even if the connection is really just a dummy one.

gfmrdsa IOhannes

On 2016-09-13 23:51, oliver wrote:

but what i was looking for was a sure way to get the desired result WITHOUT direct connections, but with send~/receive~ combinations.

but you *are* using direct connections already, e.g. to hook up a signal into [send~]. this might sound a bit trivial, but in reality it is not.

my point is, that - in order to guarantee the correct execution order - you *must* use signal connections. even if you just use it for the order forcing.

in practice this means, that you can put a single [send~] into a subpatch "source", and multiple [receive~]s into a subpatch "sink", and then signal-connect "source" with "sink". this guarantees that each and every [receive~] object (within "sink") will be executed after the [send~] (in "source"). so if you have 1000 [r~], you still need only a single order-forcing connection between the two subpatches.

there's a border case when you have only a single [receive~], in which case the entire order-forcing thing becomes a bit of whacky: there's little point in having one dummy signal-connection for a single implicit (s~/r~) connection - the overhead is just too big. but as soon as you have more [r~], the overhead becomes smaller and smaller.

("overhead" here is mainly "patching overhead" (between chair and keyboard) rather than "processing overhead" (in terms of CPU/memory/...)

...

it's quite simple: if you have two subpatches/abstractions that are connected via a signal-connection, then the "upper" subpatch will always be evaluated before the "lower" subpatch; simply because the lower one is waiting for the upper one to produce data - even if the connection is really just a dummy one.

thanks for clarification.

what about the signals in the main patch in this situation ?

is it then: "MAIN PATCH" before "UPPER SUBPATCH" before "LOWER SUBPATCH" ?

hmm, no: "UPPER" and "LOWER" subpatches are part of the "MAIN PATCH" processing. maybe my nomenclature was a bit misleading.

lemma A: the dsp graph is grouped by canvases (a subpatch is one canvas, an abstraction is one canvas; the main patch is one canvas). from the outside, each canvas is processed atomically (e.g. from the main patch's POV, either all objects within the (e.g.) "upper" subpatch have been processed or none).

lemma B: a sink object (one with signal inlet~s) can only be processed after all its source objects (with signal outlet~s connected the sink's inlet~s)) have been processed,

since a subpatch is just an ordinary object (from the parent's POV), this means that each object in the the "source" subpatch (which i called "UPPER") will be processed before any object in the "sink" subpatch (which i called "LOWER").

if the MAIN patch has an object (e.g. [osc~ 440]) connected to the UPPER subpatch, then this [osc~] will be executed *before* UPPER. if the MAIN patch (also) has an object (e.g. [dac~]) that gets signal data from the LOWER subpatch, then this [dac~] will be executed *after* LOWER. if the MAIN patch (also) has an object (e.g. [*~]) that is connected to an outlet~ of UPPER and to an inlet~ of LOWER, then it will be executed after UPPER and before LOWER. if the MAIN patch (also) has an object (e.g. [*~]) that is connected to an outlet~ of LOWER and to an inlet~ of UPPER, then it will be executed before UPPER and after LOWER. since LOWER must be executed before UPPER (because they are connected as well), you have a contradicition (you cannot have both UPPER>LOWER *and* LOWER<UPPER), and Pd will not process any of them, giving you a "signal loop detected" error. this is true even if the [inlet~] and [outlet~] objects within the subpatches are not connected at all (due to lemma A)

hope this helps.

fgmasdr IOhannes