I also thought - if you still got some capacity for trying to recreate the issue - that it would be best if you try with the actual patch, which is here: https://krzysztofcybulski.com/netsend_issue.pd

It should produce three high "ring" tones, followed by a lower one and again a high one, then it's only some low frequency pulse wave. When I run it on the Bela mini and there's no network around, the patch restarts during the lower "ring" tone (which is supposed to indicate a succesful connection).

[connect 255.255.255.255 52000(
really?

What does your network configuration look like for that to be a valid address?

I'm not really sure what seems to be invalid with this address, althoug I know next to nothing about networking, honestly - 255.255.255.255 is for broadcasting to any other stuff (i.e. instruments) connected to the same network, 52000 is just an arbitrary number - I was advised to pick a high number at som point trying to resolve the issue.

Well I have never seen it used before, but I see how it may work...

Hmmm can you try broadcasting to a specific network instead (Directed Broadcast)? That normally is the address of the device on the network
but replacing the last value with 255. E.g..: if your device has address 192.168.1.10 on the wifi netwrok, try sending to 192.168.1.255
More generally, it's the broadcast address shown for a specific netwrok when you do ip a

So - switching to Directed Broadcast doesn't seem to change anything.

I was trying to get Pd on a laptop to behave in the same way (i.e. crash when the network is not present) and [netsend] doesn't indicate that it's disconnected even when it actually is (i.e. router turned off). Which seemed puzzling, but I've found this info on pd.iem.sh website:

"As of 0.51, Pd supports IPv6 addresses, netsend -u (UDP) is fully “connectionless” and no longer closes if no one receives a UDP message"

which seems to explain it. However, shouldn't it behave the same way on Bela, as the pd version I have now is 0.51.4?

And also, Isn't UDP supposed to work that way anyway?

And most of the above doens't make much sense, as I've just realised that for the IPv6 to work, the address would have to be in a different format.

ok I can reproduce now. I think the bigger issue is about sending out messages faster than they can be sent out of the socket. This eventually leads to output buffer to fill up and cause that crash. It shouldn't actually crash, but you should be able to reduce that issue right now if you wait for a few seconds after startup before you start to send out the messages: when running at boot, the system will be very busy doing other things and won't process the outgoing queue fast enough. Also, possibly reduce the rate at which you send them in order to avoid mid-performance crashes.

I am working on a fix but it may take a while. In the meantime, download this on the board and install it with dpkg -i libpd-xenomai-3-dev_0.13.2-14-g0d05bb3-dirty-1_armhf.deb and at least it should stop the hard crash (not sure if that's helpful or not).

    Thanks

    giuliomoro you should be able to reduce that issue right now if you wait for a few seconds after startup before you start to send out the messages: when running at boot, the system will be very busy doing other things and won't process the outgoing queue fast enough. Also, possibly reduce the rate at which you send them

    I'm waiting 6 seconds before I send anything, but I'll increase this value and see if it helps. Also, I'm sending very modest amount of data - only midi note and gate signals from a monophonic keyboard, so really only a couple of OSC messages per second at most.

    giuliomoro In the meantime, download this on the board and install it

    On it!