SCLang -> JS communications over socket? #35
Comments
|
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. |
|
I think we could get away with just a SC->JS socket and continue to provide input via It looks like we could create a 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. |
|
also - no shame on a hack that works! supercolliderjs is super-cool and I'm grateful you made it. |
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 someSTDOUTparsing 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 toJSON.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
Taskthat prints to the screen, or you have MIDI/OSC debugging output, basically anything that might print toSTDOUT- 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:
over and over again (for example by selecting them and holding down shift-enter), you'll see the output periodically dumps
SUPERCOLLIDERJSlines.The text was updated successfully, but these errors were encountered: