SCLang -> JS communications over socket?

[ssfrr]

In investigating #34 it occurred to me that it might simplify things if the return communication from the sclang process to javascript were in a separate stream rather than interleaved with STDOUT. There'd still need to be some STDOUT parsing for monitoring interpreter initialization and capturing errors, but for the success case we could just send a stream of null-separated JSON objects over a socket. On the JS side you just accumulate data from the stream until you see a null and then send the received string to JSON.parse. That way you don't make any assumptions about alignment between the data callbacks and the messages.

Another case I thought of where the current system could have problems is if the code you send to the interpreter starts a SC Task that prints to the screen, or you have MIDI/OSC debugging output, basically anything that might print to STDOUT - that could corrupt data that you're trying to send between SC and JS.

I'd be willing to take a crack at this sort of arrangement if it's something you're likely to accept as a PR, and of course I welcome feedback and discussion about the right design.

edit:
As an example of confusing the parser state machine, if you run these two lines:

{100.do {".".post; 0.0001.wait}}.fork;
(1..100).pyramid

over and over again (for example by selecting them and holding down shift-enter), you'll see the output periodically dumps SUPERCOLLIDERJS lines.

[crucialfelix]

That is if you can get a properly working bidirectional socket in sclang. AFAI remember there are some issues. It isn't built to just make TCP sockets. It is quite connected to the specific case of connecting with the server. That's just my memory though; check it yourself to see if I'm right about that.

If you did get a working socket then for catching errors you could also dump directly rather than use the stdout posting system.

It might be possible to get corrupted output in STDOUT. sclang code is a bit ancient and wasn't designed to be multi-threaded and performant.

What I'm doing with the in/out system is totally a hack. The specific transport system could be easily replaced though if you came up with something better. But think carefully if you want to spend your time on it. The win isn't that huge. But don't let me stop you ! If you want to try something then by all means go for it.

btw. I've been intending to strip out flowtype and convert the project to typescript. It's much better to work with. Typing is pretty essential with a complex project like this.

[ssfrr]

I think we could get away with just a SC->JS socket and continue to provide input via STDIN. We control what goes in over STDIN so that should be fine.

It looks like we could create a NetAddr and use the connect method to create a TCP socket that we can write to with sendRaw. Null-terminating strings doesn't seem to work (supercollider drops the null byte when you try to append it), but we could use 0xff.asAscii as the separator - 0xff is not a valid UTF-8 character so it should be OK even if there's unicode going over the pipe.

The win for me is that it would make it easier to solve #34, so I could keep adding autocomplete-plus support, so I could make music in Atom. :)

I don't have any opinion on typescript/flow, I'm not much of a javascript programmer, much more C/Julia/Python. I'll probably get to this in the next week or so, so I'll just do it in the current system unless you end up swapping to TypeScript first.

[ssfrr]

also - no shame on a hack that works! supercolliderjs is super-cool and I'm grateful you made it.