[PD] problem with send~ instead of patchcord

[oliver]

sorry, IOhannes. was meant to go to the list...

IOhannes m zmölnig wrote:
> 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.

i heard your warning loud and clear :-)

>
> 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.


i know that my suggestion is by no means a solid or reliable method, 
even worse when abstractions come into play.

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

the main goal was to produce a read-out signal for multiple players (in 
abstractions with receive~ objects) that reliably and in sync play back 
long tables. but of course this time-critical task can be done in a 
better and more stable ways with 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.

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" ?

best

oliver