That allows bi-directional communication to my Behringer X32 console. Explanation:
A JavaOSC Client application uses e.g. IP address 192.168.0.1 with UDP port 1234 as local port, and IP address 192.168.0.2 with UDP port 10023 as remote port on the X32
Once X32 receives the packet on port 10023, the response will immediately sent back to the exact sender, that means 192.168.0.1:1234
JavaOSC must then read from the exact same socket the it used for sending. Otherwise the datagram will not be accessible by JavaOSC.
With the original implementation, it was of couse possible to use the same input UDP port as the output UDP port, but unfortunately, at least on OSX, it is not possible to create two UDP sockets for sending and receiving on the same port. Therefore I extended the OSCPortOut to accept a "Transport" object in its constructor, which can be retrieved from the OSCPortIn object. Additionally, UDPTransport had to be changed to use two ByteBuffers, one for sending, the other one for receiving. Otherwise we will corrupt receive/response data on the fly. This should not make any issues, as the
var out = new OSCPortOut(new OSCSerializerAndParserBuilder(), new InetSocketAddress("x32-ip", 10023));var in = new OSCPortIn(out.getTransport());in.startListening();out.send(new OSCMessage("/info"));
At least this PR works for me since for a few months now. Hope it will meet the quality standards. Please let me know!
This extension addresses the following issue: https://github.com/hoijui/JavaOSC/issues/40
That allows bi-directional communication to my Behringer X32 console. Explanation:
With the original implementation, it was of couse possible to use the same input UDP port as the output UDP port, but unfortunately, at least on OSX, it is not possible to create two UDP sockets for sending and receiving on the same port. Therefore I extended the OSCPortOut to accept a "Transport" object in its constructor, which can be retrieved from the OSCPortIn object. Additionally, UDPTransport had to be changed to use two ByteBuffers, one for sending, the other one for receiving. Otherwise we will corrupt receive/response data on the fly. This should not make any issues, as the
var out = new OSCPortOut(new OSCSerializerAndParserBuilder(), new InetSocketAddress("x32-ip", 10023));var in = new OSCPortIn(out.getTransport());in.startListening();out.send(new OSCMessage("/info"));At least this PR works for me since for a few months now. Hope it will meet the quality standards. Please let me know!