In your first posting in this thread you mentioned LuaJIT, and later you proposed the echo example, which I did, so I think it is on topic for this thread. Might not be the best Lua code, and the ringbuffer could be outsourced in an external Lua class and file to make it shorter and easier to read, but this is how it looks like with my Lua module:
Just ignore the input/output UI element creation code that you don’t want 
I also tried to do a FFT, using this pure Lua implementation:
but this was really slow, unusable within the process function. But the code is not optimized. I think a proper Lua module should use Numeric Lua:
http://numlua.luaforge.net
This uses highly optimized C code from the Netlib library and BLAS and LAPACK for matrix operations, FFT etc., so it would be nearly as fast as everything written in C.
I guess it would be faster than Lua for heavy computational implementations inside Lua as well, if it doesn’t use the generic table for float arrays. @modlfo used in his tests, where he measured only 15% slower speed than C++, a special native double array as well.
Some examples in ChucK, for FFT/IFFT and Karplus-Strong see http://chuck.cs.princeton.edu/doc/examples
// attenuator
inputs[0] => outputs[0];
while (true) {
1::sample => now;
params[0] => outputs[0].gain;
}
// integrator
inputs[0] => blackhole;
Step step => outputs[0];
0.0 => float y;
now + delta => time later;
while (now < later) {
y += inputs[0].last();
}
y => step.next;
// lfo
SinOsc osc => outputs[0];
440.0 => osc.freq;
SinOsc lfo1 => blackhole;
1.0/1::minute => lfo1.freq;
0.2 => lfo1.gain;
TriOsc lfo2 => blackhole;
1.0/3::minute => lfo2.freq;
0.1 => lfo2.gain;
while (true) {
1::sample => now;
lfo1.last() + osc.freq() => osc.freq;
lfo2.last() + osc.phase() => osc.phase;
}
// filter
inputs[0] => HPF hpf => outputs[0];
4400.0 => hpf.freq;
0.9 => hpf.Q;
// echo
inputs[0] => Delay delay => outputs[0];
1::second => delay.max;
1::second => delay.delay;
Just when I was about to write a Faust prototype for Rack, I ran across this thread. I took a few of your hints and proudly present my take on this: https://github.com/mzuther/ProtoFaust. 
I had no time to write a README, yet, but I hope things are self-explaining. Just install a recent version of Faust, download the latest VCV Rack SDK and edit src/faust/main.dsp (the default is a simple three-oscillator synth with resonant filter). Then, hit make run and keep your fingers crossed…
Martin
Edit: updated link to match the renamed Git repository.
The name will be confusing if you release this and in 4-6 months there will be a “VCV Prototype”.
We’re waiting on @sempervirent to design a panel for this.
Hijack.
@sempervirent, I have a cat I would like to volunteer for your feline space program. Where can I sign her up?? One-way trips are OK.
I think your project is significantly different than the idea of this thread. It’s interesting that it works by compiling the Faust directly into the plugin. Could be used by people who can write C++ but would prefer a higher level language for DSP.
Hi Martin, testing this out. Pretty cool. Got the basic demo running. Any chance of showing how to change the Faust to run something like the “Guitar Effects Chain” on the Faust documentation site instead of or in addition to the resonant filter in the demo?
Thanks in advance.
Seems like I’ve somehow managed to miss the word “interpreted”. 
My idea was to prototype and test by sending the file main.dsp to other people. In any case, it’s fun to using the project, and maybe it’s useful to someone.
Regarding the project’s name, I will change it as soon as I can think of a different one. Nobody is helped if people get confused.
I will be away for the week-end and still have to pack, so here’s a very short primer. The main process is
process(in1 , in2 , in3 , in4 , in5 , in6 , in7 , in8) = internal_processor
{ ... };
and you can simply put the guitar chain (or any other DSP process) in there:
internal_processor = (in1 : gui_attacher) : guitar_chain : _ , in2 , in3 , in4 , in5 , in6 , in7 , in8 : si.bus(8);
Or in stereo:
internal_processor = (in1 : gui_attacher) , in2 : guitar_chain : _ , _ , in3 , in4 , in5 , in6 , in7 , in8 : si.bus(8);
Just make sure that you add gui_attacher – this will attach the parameters and simply copy the mono input signal to its output. If you fail to do so, the Prototype module will not find any of the knobs, buttons and LEDs (they will be thought as superfluous and optimized out) and probably crash.
Good luck! 
Legend. Thanks.
How about Crossroads in reference to Robert Johnson’s supposed Faustian deal with the devil at the Crossroads, and your module is kind of a crossroads between c and Faust?
That’s really clever.
I agree! However, potential users might have difficulties in connecting the name with the module’s actual function.
As I like the theme of Mephisto, I have renamed the module to ProtoFaust (a reminiscence to Goethes “Urfaust”). Here’s the updated link: https://github.com/mzuther/ProtoFaust.
I was so hoping for „Poodle“ 
@Vortico, @mzuther ; Flying back in for a moment to say that some family medical difficulties have stalled my dev efforts on this (and other things) and while I’d be interested in contributing if the timing works out, I don’t want to hold space that someone else could more productively fill. I got far enough to see that an approach like Martin’s would lay the groundwork for a more JIT-y version.
ooh - it runs JS! Does it use Google’s V8 runtime?
The first engine will be Duktape, due to its simplicity, while I design the ScriptEngine API.
Source at https://github.com/VCVRack/VCV-Prototype. Also released to the VCV Library at https://vcvrack.com/plugins.html#VCV%20Prototype.
Currently only JavaScript via Duktape is supported, so audio generators and processors will consume a lot of CPU. Faster languages like Julia and LuaJIT may be added later.
If anyone’s interested in adding other interpreted languages such as Faust, Lua, Julia, libpd, etc., just let me know in this thread or send a pull request on GitHub. The instructions should be straightforward at https://github.com/VCVRack/VCV-Prototype#adding-a-script-engine.
lol, my MBPr13 CPU can’t handle this vco.js 
While the rainbow.js example takes ~1.5% on my notebook, the vco.js example takes ~50%. As mentioned in the docs and examples, this Javascript interpreter is too slow for realtime audio computation. More than good enough for control signals though.