Hi,
I'm facing an issue with [netsend] [netreceive].
I'm sending messages to a python server and like to wait for computation before PD continues.
I currently have an abstraction like

[inlet]
|
[some stuff]
|
[netsend]

[netreceive]
|
[other stuff]
|
[outlet]

with this

[bang(
|
[t b b]
|      |
|      [myAbstraction]
|          |
[print a] [print b]

[print a] is triggered before [print b]

So my question:
Is there a way to stop PD computation to trigger [print b] BEFORE [print a]?

@FFW You can hold it in [f] on its right inlet if it's a float.
Or [symbol] or [list].
And then bang it through from a trigger at the output of the abstraction....
[t b a]...... left to float..... right to [print b].
David.

@whale-av : I currently use this but I was hoping a simplest way.
Some of my abstractions have 4 inlets and I have to store and bang each 4 values. Other ones outputs lists I sequence to two inlets, it's a headache to got them in the good order.

@FFW It is like @whale-av said.

The chain has to be restarted by the [netreceive].

Maybe like that:

[bang(
|
[myAbstraction]
|
[t b b]
|       \
[print a] [print b]

You can use [f], [symbol] and [list] to store values. You can use [send] and [receive] to detach parts of the code. [receive]s of the same name will get the bang in the order they where created.

@ingox It's quite more complicate than my simple example.
Here is my main communication patch:

Messages are sent throw this [fc_process]:

And I'm in trouble with this (each [fc_…] and [ik/…] have a [fc_process] inside):

It may be easier to update all my objects with a bang-to-process inlet and a bang-when-done outlet.

@FFW Yes, but if i see it correctly, your code is structured in parallel by triggers: First the right thread, then the next to right thread and so on.

It should be possible to organize it linearly: The next to right thread could just follow after the right thread. Just like in the code i gave above.

@ingox It could work if the hot first inlet is always set by the previous abstraction but it's not the case.

With an "activity" chain, it's great:

@FFW This must be a misunderstanding as Pd code is always computed in a strict deterministic way.

So there is no real difference between

[bang(
|
[t b b]
|       \
[code b] [code a]

and

[bang(
|
[code a]
|
[code b] 

This means you can untangle all triggers and bring the code in a spaghetti like linear form – with the waitings for [netreceive] inbetween.

Or maybe i am just not getting the problem.

@ingox The problem is in

[bang(
|
[t b b]
|       \
[code b] [code a]
|        |
[code c  ]

if it has a [netreceive] in [code a], [code c] is computed before [code a] returns a value.

And as [code b] doesn't need [code a] output I can't chain [code a] to [code b] without the mentioned "bang-when-done".

with the waitings for [netreceive] inbetween.

It's really what I'm looking to remove

@FFW In this example you could chain the blocks like this:

[bang(
|
[code a]
|       \
[code b] |
|        |
[code c  ]

The values do not matter, you can put them away to some cold inlets and store them. You just have to force the order of execution.

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

@ingox I know how to store value and get it later, see fourth message but I'm looking for a simplest way.

As in my original question, if it was possible to stop the PD computation during the external ones it could be great. But it seems it can't be done despite PD knows when an object ends.

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 Does it know when an object ends? If there is still a trigger to compute, the code is not finished...

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

@ingox said:

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

To add to this, I often have to stop and think about whether my abstraction is outputting values before it has updated its internal state to reflect that output. I would argue that abstractions that don't do that aren't reentrant (if that term applies to a data flow languages) because some enclosing patch could cause message feedback due to Pd's depth-first evaluation. But this is just pedantry that doesn't address the OP's issue

If you aren't opposed to using externals:

Prints "nowResult 1000" immediately, then a second later:

1000msResult: 1000
afterBuddyB: 1000
afterBuddyA: 1000

... in the order you'd expect.

hjh

A few other thoughts:

In just about every programming environment, if you have a mix of synchronous and asynchronous operations (@FFW your "a" is synchronous and "b" is asynchronous), then there is no alternative but to structure the code to handle the asynchronicity. Period.

The question is "Isn't there a way so that I don't have to handle the asynchronicity?"

AFAIK the answer to that question is no. You don't have a choice -- you have to structure the patch accordingly.

"But it seems it can't be done despite PD knows when an object ends."

No, actually, it doesn't. If you have [t b b], and the right outlet includes a [delay] or polls some external result and the result is asynchronous, then the upstream [t] object has no idea when that asynchronous result has completed. (This isn't a Pd limitation -- SuperCollider also requires code to wait explicitly for asynchronous results.)

There are two ways to handle it:

• Put [t . .] before both A and B. B initiates but does not complete. A finishes, and then saves its result in a storage object (cold inlet). Then, when B finishes, it has its own [t] to forward its result and "bang" the storage object.
• Or, put the input into a storage object synchronously, then trigger only B. B's completion then initiates A.

[buddy] just does this for you, in a more general way -- by doing it for you, it's more transparent, easier to read, easier to maintain etc.

"Some of my abstractions have 4 inlets and I have to store and bang each 4 values. Other ones outputs lists I sequence to two inlets, it's a headache to got them in the good order."

If I understand you correctly, that's exactly what Max/cyclone [buddy] is for. Buddy will scale easily up to any 'n' inputs.

hjh

Thank you everybody!

@ingox @jameslo : I understand it's better to deal with PD specification than to try to hack

@ddw_music It could be a solution but in certain case I don't need all the inputs so it can't be generalized.
For a vanilla version replace [iemlib/any] per [float] or [symbol]:

(print b then a even if you click a before b )

Finally I think the "activity chain" is the easiest and clearest, let's modify all my objects…

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