OSC XML changes to current Bonsai?

[nghess]

Hi,
After a fresh install of Bonsai, I'm no longer able to connect to Bonsai from Bpod in Matlab. For simplicity, I am using the demo included in the Bpod install, using all the defaults. The connection worked fine before the reinstall, but now SendMessage is producing the error "There is an error in XML document (2, 2)."

Any tips?

Many thanks,
Nate

Below is the Osc.config. In Bonsai, SendMessage is directed to Address: "/" and Connection "MATLAB".

<?xml version="1.0" encoding="utf-8"?>
<TransportConfigurationSettings xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <TransportConfiguration xsi:type="TcpClientConfiguration">
    <Name>MyPort</Name>
    <HostName>localhost</HostName>
    <Port>11235</Port>
  </TransportConfiguration>
  <TransportConfiguration xsi:type="TcpClientConfiguration">
    <Name>MATLAB</Name>
    <HostName>localhost</HostName>
    <Port>11235</Port>
  </TransportConfiguration>
</TransportConfigurationSettings>

Could it be that the issue has something to do with Visual Studio, .NET, SQL etc. versions being mismatched?

EDIT: Here's the full error:

Bonsai.WorkflowRuntimeException: There is an error in XML document (2, 2). ---> System.InvalidOperationException: There is an error in XML document (2, 2). ---> System.InvalidOperationException: <TransportConfigurationSettings xmlns=''> was not expected.
   at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderTransportConfigurationCollection.Read6_ArrayOfTransportConfiguration()
   --- End of inner exception stack trace ---
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
   at Bonsai.Osc.Net.TransportManager.LoadConfiguration()
   at Bonsai.Osc.Net.TransportManager.ReserveConnection(String name, TransportConfiguration transportConfiguration)
   at Bonsai.Osc.SendMessage.<>c__DisplayClass10_0`1.<Process>b__0()
   at System.Reactive.Linq.ObservableImpl.Using`2._.Run()
   --- End of inner exception stack trace ---

Edit 2: I'm running into the same error when I try and run Goncalo's UdpClient example file from here: https://groups.google.com/g/bonsai-users/c/j-SImKsTJiY/m/ZJ_Fyk77CAAJ

Has something perhaps changed in the Osc library that would make the names in the .config file obsolete? Or is this more likely an issue with my machine/installation?

[bruno-f-cruz]

the Osc.config has indeed been deprecated afaik. I don't have a bpod or matlab, but the second script you sent works for me when I try to send osc messages to a python client. Can you try it again but have it in a folder without any osc.cofig file? Additionally, what version of the OSC library do you have installed?

[nghess]

Hi Bruno,
Thanks for responding! You got me on the right track. By eliminating the Osc.config file, then setting up a CreateTcpClient before my SendMessage node, I was able to get everything working.

Thanks so much for your help!

[mhuy26]

Hi Bruno, I had the same error as nghess. So I tried your suggestion and no longer had it. Instead, I ran in this this: "The specified connection name has no matching configuration".

Here is the Python script I used:
from pythonosc import dispatcher, osc_server

def print_handler(address, *args):
print(f"Received on {address}: {args}")

dispatcher = dispatcher.Dispatcher()
dispatcher.map("/test", print_handler)

ip = "127.0.0.1" # localhost
port = 11235 # must match what Bonsai is sending to

server = osc_server.ThreadingOSCUDPServer((ip, port), dispatcher)
print(f"Listening on {ip}:{port}")
server.serve_forever()

I also attached a screenshot from my Bonsai workflow:

I believed I had the correct "Address" as well as the correct "Connection" (matching with Python script). So how come this is an issue?

Looking forward to your suggestions!
THANK YOU!
Huy

[bruno-f-cruz]

Can you include your full project directory?

[nghess]

@mhuy26 I should mention that eventually I moved to the USB softcode system in Bpod and found it vastly more reliable than the tcp/ip approach.