• ingox

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

    posted in this forum read more
  • ingox

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

    posted in technical issues read more
  • ingox

    @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. ;)

    posted in technical issues read more
  • ingox

    @FFW So finally i came up with something:

    wait.zip

    Bildschirmfoto vom 2021-10-13 13-33-21.png

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

    posted in technical issues read more
  • ingox

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

    Bildschirmfoto vom 2021-10-13 12-01-58.png

    posted in technical issues read more
  • ingox

    @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... :grimacing:

    posted in technical issues read more
  • ingox

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

    posted in technical issues read more
  • ingox

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

    posted in technical issues read more
  • ingox

    @FFW said:

    with the waitings for [netreceive] inbetween.

    It's really what I'm looking to remove :stuck_out_tongue_closed_eyes:

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

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!