@ddw_music Tap upvote again? No rant necessary...

@raynovich You can also open a patch with

[;
pd open abstraction.pd /usr/local/lib/pd/doc/7.stuff/additional/pd-msg/2.msg_and_pd(

Maybe this helps?

@cfry plus.zip

@FFW Yes, the thing is that when the callback is there, the bang from the trigger is long gone. So my idea was to just use the bang from [netreceive], as this will exactly arrive at the right time. Another option would be a send from the current active callback, like you mentioned. But this is very very close to the linear structure i mentioned earlier in this thread, because instead of a global activityEnd you could just call the next node and wouldn't need the triggers or any bookkeeping.

@FFW So finally i came up with something:

wait.zip

The bangs from the triggers have to run through without pause. Then the checkpoints will only fire when they receive a simulated signal from netreceive in the order they received the initial bangs.

So the actual process after the initial bang is completely detached and asynchronous. It does depend on receiving the simulated netreceive. This can be replaced by an actual [netreceive].

I am not sure if this is reliable or stable or anything, more like a prove of concept.

@FFW Haha, hacking is of course fine. For the record, i spend some hours trying to find a way counting up a kind of filter abstraction that would receive [netreceive] and only the next one leaves the bang through.

I could not find a way that would satisfy me.

@FFW Here is a thread about if a busy wait is possible: https://forum.pdpatchrepo.info/topic/13043/can-pd-busy-wait/ (tl;dr: not really). I think the question is somewhat similar to yours. It is just not the Pd way...

@FFW Does it know when an object ends? If there is still a trigger to compute, the code is not finished...

Just to mention: As far as i know there are no "states" in Pd, with which you could put parts of the code to sleep or wake them up. Pd is just running continuously, waiting for input, then calculating everything. The same with [netreceive]: It just puts something out, when it receives something, so generating a bang.

You could define a state "received" and check for that state with a metro in other parts of the code. But this is not only ineffincient, the state would still have to be changed by [netreceive], so this could just trigger the next part of the code.

@FFW said:

with the waitings for [netreceive] inbetween.

It's really what I'm looking to remove

Now i am confused. Maybe i am on the wrong track?