Response title
This is preview!
template < typename ... Args> Message createMessage(std::string oscAddress, Args &&... args);
The underlying network that delivers an OSC packet is responsible for delivering both the contents and the size to the OSC application. An OSC packet can be naturally represented by a datagram by a network protocol such as UDP. In a stream-based protocol such as TCP, the stream should begin with an int32 giving the size of the first packet, followed by the contents of the first packet, followed by the size of the second packet, etc.
OSC messages may be sent directly without the need for framing in message oriented protocols such as UDP or MPI. Stream-oriented protocols such as TCP and serial byte streams need a framing mechanism to establish message boundaries. These streams are now required to employ SLIP (RFC1055) with a double END character encoding. This choice has been used extensively for years on the Make Controller board and in our micro-OSC work and we have established its efficiency and superiority over the OSC 1.0 size-count-preamble recommendation when recovering from damaged stream data.This new specification enormously expands the range of protocols and hardware transports that can be used to communicate OSC encoded packets including Firewire, Ethernet, and USB (using TCP/IP); RS232 and RS422 and Serial USB and Serial Bluetooth and Serial Zigbee. USB support is especially important for the NIME community as USB provides power to remote devices and USB is currently the primary for connecting gesture controllers to computers. Serial USB is faster than the USB HID protocol typically used by such devices and with careful jitter management good enough for musical expressivity [15].