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