[PD] problem with send~ instead of patchcord

[IOhannes m zmoelnig]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160914/e6b56321/attachment.sig>