supercolliderjs

supercolliderjs copied to clipboard

This PR still needs some testing but seems functional. The two main parts are:

1. Now uses a separate socket for getting sending back the result of an interpret call from SCLang. This way you can rely on getting the data back intact even if there's other stuff going over STDOUT. For example, if you're printing OSC debugging info while at the same time requesting data to use for auto-complete in the editor.
2. Reworks the STDOUT handling state machine to work line-by-line. I wasn't planning on doing this as part of this PR but I ran into trouble where sometimes the state machine wasn't grabbing the CAPTURE:END blocks. IMO this setup is easier to read and no longer makes any assumptions about alignment of the callback data.

I still need to walk through the state machine to verify it's correctly handling all the cases that the old one did before this is ready for full review, but I figured I'd post progress in case you wanted to take a glance.

You will want to use the test suite. Once you turn on jest it runs those tests before you can even blink.

I'm not sure what the address in use error is in here: https://travis-ci.org/crucialfelix/supercolliderjs/jobs/280304528

Looks great so far !

OK, it's passing all the tests. I've done a little refactoring (I moved the socket stuff into sclang.js from sclang-io.js, and made sure the connection is cleaned up on quit. I also confirmed that this fixes #34.

Also closes #35.

I've tested it a bit running from node directly and also playing around in Atom, and AFAICT it seems to be working fine. Definitely kick the tires and let me know if there are issues.

I will definitely kick tires and do code review. Great work !

I haven't yet had a chance to test this. I will probably want to merge it to develop, but then there are some issues that need to be solved before a release.

Currently you could only run one supercollider.js at the same time. I often run many.

So the socket should be able to use unix domain sockets like /var/run/supercolliderjs_{PID} (id of the node.js process) and pass that through to supercollider. That would guarantee a unique, secure and easily configurable channel of communication.

But we should also support open TCP connections. It would be fun (and possibly not entirely useless) to connect to an sclang running on a beagleboard.

Thanks for taking the time to look at this, and sorry the PR co-mingled too many different things.

A bit after working on this PR I switched back to using the main SC IDE, so unfortunately I don't think I'll have the time to work on this any time in the near future. I won't be offended if you want to close the PR, or rip out any bits that might be useful if you still want to switch to TCP transport.

I'm definitely going to transplant the TCP transport and make that work. I will try to cherry pick it in if I can, but definitely give you the credit. Thanks!