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