What would it take to hook SC up to this? I can run a Pd patch within VCV Rack, but not a SC script 
https://vcvrack.com/Prototype#manual
hjh
i already implemented it 95% of the way, just haven’t had time to finish it. https://github.com/VCVRack/VCV-Prototype/issues/8
1 Like
Oh great! Actually I just found some evidence in their repository of some work being done on it.
Will pore over it a little more – not sure if my C is up to it, but if I can help in some way, I’m keen.
hjh
thanks! the only remaining work is in the build system integration, it’s spelled out in that ticket thread.
Ah ok, I’m not very knowledgeable there.
I’m curious how it will work with the “auto-reload” feature mentioned in the Prototype documentation – SC’s REPL is different from recompiling static scripts. Or is it sclang processing only (no server routing?).
This could be fun 
hjh
it’s sclang processing only ^^
Oh, hell yes! Maybe my entire class this year can be about making SC-based VCV rack modules?!? Looking forward to playing with this.
Sam
ahhh okay yall i’ll try to take some time and get this finished this weekend.
1 Like
Hmm… sclang processing would be useful for control signals, especially types of sequencing that are not convenient with other modules, but you know that after this is released, it’s going to take about a second and a half before somebody asks how to use UGens with it… don’t get me wrong, this is really cool and it looks like you’ve done the hard part already (which I couldn’t have handled).
Pretty sure that Rack won’t pipe audio to a second SC process… but we do have an internal server. Maybe v2 of the SC engine could boot an internal server and route audio through that.
Because it seems that Rack will rerun the whole script, we might encourage use of Ndefs to replace synths rather than piling up new ones.
hjh
you can use it for audio rate signals, that’s the point! one of the examples i ported is a sine-wave oscillator written in sclang: https://github.com/VCVRack/VCV-Prototype/blob/v1/disabledexamples/vco.scd
i’m not sure exactly what you’re imagining here… are you thinking both a server and sclang instance executing in the same audio thread callback? or setting up some server state from sclang when the script is loaded and then handing off the audio thread callback to the server? to me the simplest and most flexible thing would be to have a separate vcv module for scsynth and supernova and control it from elsewhere, perhaps even a vcv-prototype module.
if i recall, the entire engine is torn down and reset every time a new script is loaded in vcv-prototype. in other words it’s not possible to change the text in the script and keep something running.
the engine runs the whole script once when it’s loaded, and then evaluates whatever’s stored in ~vcv_process in the process callback.
Sure. To do more sophisticated audio processing would require re-implementing UGens as sample-by-sample sclang code. I’m anticipating that this may prove not to be a popular design choice. I’m fairly confident that the overwhelming majority of users interested in VCV integration will expect to be able to leverage SC’s existing DSP features.
Passing audio both to the server and the language would strike me as redundant (and, how to reintegrate the two kinds of processing?). The second option (pass audio into a server) would make more sense to me. Using an internal server would avoid the problems of Rack managing two subprocesses rather than just one.
Looking a bit more at the source code, I do see what the problem is – the current approach needs to pack the audio buffers and the light/button colors into a “block” object. If the audio buffers are coming from a server and the colors are control data coming from the language, it gets a little tricky. One way might be to put the colors into the server: 12 colors x 3 floats could be represented in a 36-frame Buffer, and periodically ask the server to send back a packet of all the data for VCV. But maybe the sclang process needs to be the main interface to VCV (where it’s potentially a sync problem).
to me the simplest and most flexible thing would be to have a separate vcv module for scsynth and supernova and control it from elsewhere, perhaps even a vcv-prototype module.
That’s an interesting idea. I’m not sure how the Prototype+sclang module would find the server module – we could safely assume localhost, but how would it know which port to send messages to? Certainly a solvable problem. Rack itself supports an “extender” feature, where modules that are touching in the Rack interface can share information – the Prototype module probably doesn’t support this directly, but if that could be added as a feature, it would be the easiest way. Worst case would be to reserve Prototype input 6 for the port number and run a cable from a hypothetical scsynth module.
OK, that makes sense.
hjh
this is some good brainstorming for future designs. i’ll wrap up what i’ve worked on and then see how hard it would be to add in a different mode for using UGens / a server.
i think you may have missed that vcv-prototype links with libsclang, there’s no separate subprocess. the plugin manages the sclang interpreter instance internally. a module to drive an audio server would similarly link against libscsynth and libsupernova. interprocess communication in the audio callback would be unnecessary overhead.
another constraint is that the interpreter relies on global state, and so it’s not possible to have more than one vcv-prototype module using the sclang engine at once. a separate module wrapping the audio servers could be useful in that regard.
1 Like
VCV-Prototype now supports SuperCollider scripting – I just pushed the changes tonight.
4 Likes
Excellent! Thanks Brian.
1 Like
This is awesome!! Can’t wait to start interfacing VCV and SC
I tried using it but when I load a .scd script in the prototype module I get the following error: No engine for .scd extension.
I have supercollider installed on my laptop which is working fine. I tried saving the script in different locations. Am I doing something wrong?
Prototype version: v1.3.0; rack version: v1.1.6; SuperCollider version 3.11.2.
Very excited about this!
There hasn’t been a release including this yet, you’ll have to build from source off the v1 branch.
Right, I have no experience doing that to be honest. I found this resource: Building — VCV Rack documentation
Have to confess I’m drawing a blank. I know how to use homebrew, but other than that I’m quite lost I’m affraid…
Is there an easy way to do it or should I just wait till the next release comes out?
Check the readme, that’s usually a good place to start when building any project: VCV-Prototype/README.md at v1 · VCVRack/VCV-Prototype · GitHub
Thank you so much! Looks like I’ll have to wait till the next update 
Any idea when that might be?