@timothyschoen Thanks for the great work! I tried it with Bitwig 3.2.8 on Windows 10, opened a patch and heard sound.

Some observations:

Selecting help from the right-click menu worked on some objects, but not others. For example, list and netreceive showed the help file, but metro and phasor~ gave message "Couldn't find help file."

Arrays were retained in my opened patch, but editing the values with the mouse was inconsistent, sometimes values would move to the cursor position and then jump back to their previous position. One array showed the dots for values and the other showed nothing but seemed to have correct values being played. Names of the arrays weren't shown, and I couldn't find a way to edit the array properties.

I probably shouldn't expect to receive OSC data from my Android phone, but I tried sending a "listen 8000" message to netreceive and got the error "netreceive: listen failed: The operation completed successfully."

I find this an exciting project and hope it continues to develop.

@ludnny You can send [send pd dsp 1(
and in the receiver.......
[netreceive]
|
[route pd]
|
[s pd]

As ";" is simply a local shortcut for [s] that allows a message to be sent to an address from within a message....... see my next post.

OR.....
Send the message [send addsemi, send add2 pd, send add2 dsp, send add2 1, send bang, send set(
and attach an empty message box to the outlet of [netreceive].
Of course you could use [list prepend send] to shorten that message (the list will still need to be comma separated for it to work...!).
Something has to be attached to [netreceive] for the message to take effect at the receiving end.
In the screenshot below I have turned DSP on in Pd Extended by sending that message from a Vanilla instance.
David.

@nicnut 2nd question first.
You need to know the ip address of the computer you will send to....... so really, if you want your patch to work next year it will need a static address.
However, I think you might be able to replace the ip address with the host name.
Anyway, there is an example here........... https://forum.pdpatchrepo.info/topic/10136/netsend-netreceive-os-x-pd-0-47-0/2 with [netsend] in udp mode.
But you can broadcast also with [netsend].... see below.

1st question.
[udpsend] is available for Pd but you need to install either the MrPeach library or the iemnet library or the net library.
It has multicast but for broadcast you can use the reserved broadcast address for your network.
And you can do the same with [netsend].......... https://forum.pdpatchrepo.info/topic/11062/cannot-connect-to-broadcast-ip-on-linux-via-netsend
David.

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

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.

@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

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

@suppervieira No, but you can use [netreceive] with a specific port.
The computer Pd is running on will have an IP address and you can connect to "IP(of the computer):port(specified in netreceive)"
David.

@Harlekin If you want TouchOSC to control OBS you don't need Pd....... just connect TouchOSC directly to the ports of osc4obs and make your remote.touchosc layout file.

If you want to do some other processing in Pd then connect TouchOSC to Pd directly (in and out)...... and then connect your processed control from PD to osc4obs directly (in and out).
osc4obs facilitates that by creating separate OSC in and out ports.
You will have to do that also if you want to use TouchOSC and Pd in an either/or situation as osc4obs only has one set of osc ports and is making a tcp connection with OBS.

OBS websocket is a tcp connection and so it is possible that osc4obs is requiring tcp for the OSC connections...... in which case remove the -u flag from [netsend] and [netreceive] in my examples below.
It could also be expecting ascii instead of binary in which case remove the -b flag (but I doubt that)....

Externals for Pd are written in C so if you are adept there is some help in Pd/doc/6.externs .....
Basically you need to make a websocket client that replicates osc4obs with outlets and inlets instead of the osc ports.

BUT... you could try the iemnet [tcpclient] first (NOT the [udpclient]...!).... and that should work.
Just replace both [netsend] and [netreceive] with the one [tcpclient]...... connect it to OBS and look at the output using a [print] object.
If OBS is on the same computer the connect message will be [connect 127.0.0.1 4444(
Remove the password from the OBS websocket unless you find that a password can be added to the [connect( message for [tcpclient]...... before or after the port number? preceded by "password" or "passwd"?...... guesswork...... and [tcpclient] might well not accept a password as it is not mentioned in the help file.
Once you are looking at a print of the received messages the problem will be to decode the proprietary message format (it will not be OSC)....... it might be easy.... or not.
If lucky there will probably be the ascii strings you are looking for or a decimal representation of them somewhere in the message.

If you go the osc4obs route then it is quite easy to use [oscformat] and [oscparse] in vanilla instead of creating an external.......
...... vanilla osc.zip

P.S. try to avoid integers within the OSC address (header) as they arrive in Pd as symbols at the output of [oscparse] ....... and are then difficult to route. So what/ever/6 data is best avoided if possible and what/ever/six data is easier to deal with in Pd...... but I have included a solution in the zip file above.

Be careful in TouchOSC to avoid message feedback (much like midi feedback)......... and the same applies in Pd. In Pd you can include "set" at the start of a message (without the quote marks)...... which will set a message in the next object or message box but not send it onward until that object or message is banged.
David.

@lgarcial I have never seen [dumpOSC] complain about the message address before.
And the float number arriving is not formatted as a float or a symbol.
So the incoming message from Grasshopper 3D is not in the correct OSC format.
It looks as though the header and the float have been formatted as a string.

Would you please close your patch and make a new one containing the object [netreceive 6000 1] connected to a [print] and then post an example of the messages printed to the terminal when Grasshopper 3D is sending OSC.....

You might also be lucky if you try using [netreceive -u -b] and [oscparse] ...... (both in later versions of Pd Vanilla though)..... but I doubt it......
David.