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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
