colinbdclark
no way to disable slip ENCODING
The useSLIP value disables or enables SLIP decoding only. Should it not also disable SLIP encoding?
You might be right, yes. Out of curiosity, what is your use case where you need to disable SLIP encoding using one of the existing transports?
The situation where a 3rd party piece of software doesn't use/support SLIP so while I can receive OSC from that piece of software (by setting useSLIP to false) sending will still encode using SLIP.
That's a bit vague, but ok. Which transport are you using? What's the third party software in this case?
I was testing using TCPSocketPort and a thrid party app called Show Cue Systems that I noticed happened to not use SLIP over TCP. I think in general if software is using stream based protocols (TCP, serial, etc.) they should use SLIP as recommended by OSC 1.1. My issue was just, in general, was it the intention that useSLIP, since it does exist in this library, only effect decoding.
That helps, thanks. I've heard of a few others like this. As you say, the SLIP encoding should be better parameterized in osc.js to support these cases. Thanks for pointing this issue out. I can't quite tell from their documentation, but does Show Cue Systems support UDP instead? That might be a good workaround in the interim.
It doesn't even officially support OSC yet. I'm currently working off beta builds I get nightly from the developer. I'm also trying to nudge them to just support SLIP when using TCP. I'm not really worried about my integration with this particular piece of software (was just looking at adding it to an existing project that uses this osc library) and ran into this SLIP dilemma. In a pinch I would just drop back to regular TCP socket and hand craft/decode OSC packets in whatever way pleased this software.
That makes sense. Easy to do with the lower-level osc.js API if you need to roll your own transport. Thanks for sharing all the background information, it's very interesting!
Not sure I've explored enough of osc.js API yet, but I'll take a look. The amount of bespoke OSC implementations that exist make it a hard thing to accommodate.