in file null error

[tatecarson]

Hi, i'm having another problem that seems to be at least partly related to atom-sc. This code: https://github.com/tatecarson/Clarinet/blob/d66d9d1fcdc454c194bd23f7d2ad6a1ca61f7779/newcompexper.scd will evaluate in the IDE, but only if the text is selected, it doesn't evaluate if parens are selected. In atom this doesn't evaluate either way. With parens selected i get an in file null error and without i get:
unexpected $end, expecting ELLIPSIS9:30:04.443 buf=0, rate=1, spos=0, freq=440, rq=1, bpfmi

The problem started with the addition of SynthDef(\automaticRecorder, {|thresh= 0.09, time= 0.2, amp= 1| var src= SoundIn.ar*amp; //var src= BPF.ar(SoundIn.ar*amp, 150, 1); //variant with bandpass filter var off= DetectSilence.ar(src, thresh, time); var on= 1-off; //invert on.poll; RecordBuf.ar(src, ~buffer, loop:0, trigger: on); }).add;

and the buffer allocation. So I think it has something to do with that.

I realize it's a lot of code and would take some time to go through but i'm at a loss for what the problem could be and i've already asked the facebook group to no avail. The code works for them in the IDE. Whenever you have time let me know if you can find any problems with it.

thanks!

[crucialfelix]

There are a few strange things going on there. Thanks for the file, I will play with it and see if I can isolate something.

The error is some kind of trailing parse error from something earlier.

It gets lost for me at 258, but it's from something earlier that isn't completed.

[woolgathering]

Having a similar issue. When evaluating the same selection, I get either:

null in file null

or

unexpected $end, expecting '}' sig = LeakDC.a

The same code evaluates fine in the IDE or Sublime Text. Please advise.

[tatecarson]

I still occasionally have this problem but circumvent it by saving code in separate files and then executing them all from one master file. I think in that instance I moved all the synthdefs into one file and it worked fine.

[woolgathering]

That's what I figured I'd have to do. Thanks!

[JoeriBultheel]

I'm having the same problem. Is this really related to the amount of code in one file? Why is there this restriction?

Thank you

[woolgathering]

Yes, I'm fairly certain it is. It happens when atom-supercollider calls SuperColliderJS.interpret. It's been a while since I tried working on it but I found that when I printed the string to a file, it cut at character 8189 every time. The string (code) is passed in it's entirety to SuperColliderJS.interpret in sclang.js but it gets cut inside *interpret. I don't remember all the details.

I think this is related to this: https://github.com/supercollider/supercollider/issues/2569. I have an idea for a workaround but I haven't gotten around to trying it. Again, it's been a long while since I tried to work on it but (tangentially) I found that separating my SC programs out into multiple files has actually been good for organizing. YMMV.

[JoeriBultheel]

Ok, that's a pitty. Funny enough everything works when using thisProcess.interpreter.executeFile("file.scd"); Even if the code in that file is really big and not working when evaluating that code in its own file. So you don't even really need to separate your file in pieces, just call it externally.

[woolgathering]

Ok, so I'm fairly certain I've fixed this.

Basically SC has a hard limit length of String literals at 8188. Since the interpret function in sclang.js passes the code-to-be-evaluated in its entirety to SuperColliderJS.interpret via the stdin where it is actually compiled as a String, if the code-to-be-evaluated is longer than 8188 characters it gets truncated and fails to evaluate. The workaround (for now, at least) is to pass chunks of the code-to-be-evaluated through SuperColliderJS to be concatenated on the other side in sclang as a String that can be greater than 8188 characters. After it's concatenated as a String in sclang, then we call String.compile on it where it evaluates as expected.

I believe this is the exact problem https://github.com/crucialfelix/supercolliderjs/issues/33 was having, as well.

To do this, you'd need the experimental branch of my fork of atom-supercollider, as well as the develop branch of my fork of supercolliderjs. Then use the local version of supercolliderjs to satisfy the dependency in atom-supercollider by putting the path in line 19 of atom-supercollider/package.json (my path is there now), otherwise it'll pull the one from the npm repos.

I've only tested it on scripts that are about 10000 characters so it would be useful for others to try it on really long stuff they've already written. I have some test scripts available that work as a proof of concept.