Probably your code needs to be amended tobe compatible with the code on the board. There was an API change which is what makes the example work but your project doesn't

It should be as easy as replacing

void on_receive(oscpkt::Message* msg, void*)

with

void on_receive(oscpkt::Message* msg, const char*, void*)

@giuliomoro that worked, the program now compiles! thanks!

however, i'm still getting this error (both my program and the example project) when PD responds to Bela with osc-setup-reply: send: No route to host (65). when i ping 192.168.7.2 from my computer, the Bela responds, so the IP seems to be correct...

any other ideas?

Can you run ifconfig on the board (in the console at the bottom of the IDE) and show the results here? Also, run ping -c 1 192.168.7.1 in there and see what comes back

    giuliomoro OK, this is what was returned:

    root@bela ~/Bela# ifconfig
    bash: line 6: ifconfig: command not found

    and

    root@bela ~/Bela# ping -c 1 192.168.7.1
PING 192.168.7.1 (192.168.7.1) 56(84) bytes of data.
64 bytes from 192.168.7.1: icmp_seq=1 ttl=64 time=1.09 ms
--- 192.168.7.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.099/1.099/1.099/0.000 ms

      giuliomoro

      root@bela ~/Bela# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 4c:3f:d3:19:7a:91 brd ff:ff:ff:ff:ff:ff
3: wlan0:  mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 1c:bf:ce:65:1a:fd brd ff:ff:ff:ff:ff:ff
4: usb0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether be:1a:d3:19:7a:93 brd ff:ff:ff:ff:ff:ff
    inet 192.168.6.2/24 brd 192.168.6.255 scope global usb0
       valid_lft forever preferred_lft forever
    inet6 fe80::bc1a:d3ff:fe19:7a93/64 scope link 
       valid_lft forever preferred_lft forever
5: usb1:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether be:1a:d3:19:7a:96 brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.2/24 brd 192.168.7.255 scope global usb1
       valid_lft forever preferred_lft forever
    inet6 fe80::bc1a:d3ff:fe19:7a96/64 scope link 
       valid_lft forever preferred_lft forever

        violapwr if i run \example Communication/OSC-pipe/render.cpp the code runs & i'm able to receive 'osc-setup' in PD, but the 'osc-setup-reply' is not received on the Bela, with PD reporting this error send: No route to host (65)

        also can you show the Pd patch?

          @"giuliomoro"#p27136

          PD:

          this code is inside pd handshake (shown in the 2nd image):

          in pd can you use "find last error" and see where it points to?

            giuliomoro PD does not seem to be able to identify the error source, strangely:

            (in the back of my mind, I keep wondering if I messed up the system when trying to fix the git segmentation fault and need to flash the emmc (since flashing the SSD has not yet fixed it).... )

              I don't think it's a bela problem though ...
              can you try a simpler patch:

              [connect 192.168.7.2 7562(
|
| [1 2 3 4(
|/
[netsend -u -b]

              do you get the same "no route to host" error?

                giuliomoro Yes, same error. I received a successful connect (1) when clicking connect 192.168.7.2 7562. Clicking 1 2 3 4 resulted in the same error and a disconnect (0)

                  giuliomoro No... I also tried to turn off my macOS firewall, and received the same error in PD

                  I just tried the same experiment with my Bela Mini (and the simplified PD patch), and had the same result, which leads me to agree that the issue is perhaps not with the the Bela but on the computer end... I recently updated my macOS to 15.4... could it be a macOS issue?

                  Update:
                  I re-tried our PD test patch on my school computer & it worked without error (screenshot below). Also, more complex program (from a year back, above) is working as well. The school machine is macOS 14.7.5. So perhaps it's a macOS thing?

                      violapwr I just tried the same experiment with my Bela Mini (and the simplified PD patch), and had the same result, which leads me to agree that the issue is perhaps not with the the Bela but on the computer end... I recently updated my macOS to 15.4... could it be a macOS issue?

                      I don't know what they are doing that makes this stop working ... can you access the Bela IDE at 192.168.7.2?