OSC 1.1, TCP, and SLIP Compatibility

[cbrews]

Hey @hoijui and team!

I found this library as a potential solution for transmission of OSC messages from a Java client to an OSC compatible application and am working on a lightweight client for that application. However, upon reviewing that client's protocol, they use a OSC 1.1-compatible TCP connection that uses a SLIP wrapper for communication.

As per the OSC 1.1 specs:

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.

My questions are:

• Is this library intended to be compatible with OSC 1.1 specification?
• Has anyone started development of the SLIP protocol or recommend an approach (note--my initial investigations seem to suggest that separate implementations of the parser and serializer interfaces loaded by OSCSerializerAndParserBuilder would be required, perhaps an OSCSerialParser and OSCSerialSerializer or something similar)?

I know that the TCP client was just recently implemented by @daveyarwood in #52, and understand that TCP compatibility is net-new in this library anyway, so I am definitely open to helping to develop this implementation.

Thanks again for your hard work on this project.

References:

• OSC 1.1 whitepaper: https://cnmat.org/files/attachments/Nime09OSCfinal.pdf
• Full RFC for SLIP: https://tools.ietf.org/html/rfc1055

[daveyarwood]

Hello!

@hoijui Speaking of my TCP support PR that you merged a couple months ago, it appears that there isn't yet a release that includes it. Could you please deploy a new release?

@cbrews Let me know if you have any questions about the TCP implementation. It's been a year, but I still remember the details fairly well and hopefully I could be of some help if anything comes up.

[daveyarwood]

@hoijui Could you please deploy a new release that includes my TCP support? 🙏

I've been deploying my fork of JavaOSC to JCenter as a workaround, but they just announced that they'll be shutting down JCenter: https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

If JavaOSC TCP support is released, I won't need to use JCenter anymore, which would get me out of this problematic situation. I'm not sure where else I can deploy my fork besides deploying it to Maven Central directly, which is a bit of a nightmare.

[daveyarwood]

@hoijui I'm begging you - please deploy a new release! 🙏

I spent 2 hours tonight attempting to publish my fork of JavaOSC to an alternative Maven repo, and got nowhere. This is so painful to deal with. Since you've been deploying JavaOSC to Maven Central already, I imagine you have it automated at this point to where you could easily deploy a release, right?

[hoijui]

@daveyarwood sorry!
I did deploy a new release now.
... I just used master for it. is that ok?

sorry... no time, no time!

The release procedure is in the README (I could never remember it):
https://github.com/hoijui/JavaOSC/blob/master/README.markdown#release-devs-only

[hoijui]

NOTE: might take up to 4h till 0.8 is available on maven central.
if it is not available tomorrow, give me a note.

[daveyarwood]

That's awesome, thanks a lot! I'll give it a test drive soon.

[daveyarwood]

I just tried JavaOSC 0.8 and it works like a charm. Thanks again!

[hoijui]

ahh good!
thanks for the feedback! :-)

[hoijui]

So TCP is done now, but we are still missing SLIP for reoslving this issue, right, @cbrews ?
I imagine you found an other way for you by now, but if not, and you feel like implementing it.. we'd (sometimes) be around to help with questions!
(I do not have the time to do it myself)

[cbrews]

I did find another way for now and was able to fallback on UDP. I may circle back on this in the future, but I also don't have time to work on this now!