Hello HN - thanks for giving our website a proper stress-test! I'm the developer of SOUL - happy to answer any questions you guys have.. :)
Hi julesrms, Some quick 2-second feedback - I tried running the default example in Brave, it failed, and then as a good user I wanted to report the bug to the community, but that requires finding the ROLI forum and signing up (providing DOB!) etc. I think it would be great if it were a bit easier to submit bug reports without as much hassle.
I've just tried and it worked for me on OSX with Brave.
We pre-emptively answered this inevitable question in the overview doc: https://github.com/soul-lang/SOUL/blob/master/docs/SOUL_Over... The main TL;DRs are: - this needs to get JITed to compete with C++ performance, so dynamic and interpreted languages are out. - it needs to stop people doing anything which is real-time unsafe, so any language which involves a heap or GC is out - it needs to be secure enough to not p…
> - it needs to strongly enforce and represent a graph structure at a syntactic level, so.. pretty much all existing languages are out. ... except languages designed for real-time signal processing based on dataflow graphs such as Kronos ( https://www.mitpressjournals.org/doi/pdfplus/10.1162/COMJ_a_... ), Céu ( http://www.ceu-lang.org/chico/ceumedia_webmedia16_pre.pdf ), Antescofo ( https://hal.inria.fr/hal-01585489…
OK, fair point! Maybe a better way for me to phrase what I meant there would have been "pretty much all mainstream languages are out"
I recall seeing Soul pop up on HN before, and at the time I was critical of it for being announced way too early (no working examples or even any indication of what the code might look like). This is much better, and it's good to see that it's actually progressing instead of being yet another case of vaporware. That said, still disappointing that there doesn't appear to be any info on an actual compiler or runtime or…
Thanks for the spot of the monaco bug - that's a regression that we'd previously fixed. It's been patched and re-deployed and should work now.
Confirmed; still doesn't scroll smoothly (or at least as smoothly as most other things in Firefox), but it at least does scroll now, so that's good enough for me. Thanks!
I recall seeing Soul pop up on HN before, and at the time I was critical of it for being announced way too early (no working examples or even any indication of what the code might look like). This is much better, and it's good to see that it's actually progressing instead of being yet another case of vaporware. That said, still disappointing that there doesn't appear to be any info on an actual compiler or runtime or…
There'll actually be many ways of using it.. Javascript in a browser is just one of those ways. The real API is written in C++ and we'll be offering a C binding in many languages, which you'll use in a pretty similar way to how you'd use the openGL API to run a shader. We'll publish that C API soon-ish, hopefully within a few months.
Okay, but what about the stuff behind that API? If OpenGL is the model, then is the expectation that audio device/driver vendors implement their own Soul backends? Will there be a reference implementation? Is that reference implementation going to be released under a free software license?
Concerning Faust-to-SOUL support, it is still reserved for people not afraid of installing and compiling Faust from github: https://github.com/grame-cncm/faust
> Our long-term goal with plugins is to make them much easier to write in SOUL without needing to actually compile anything natively could you offer to compile/package SOUL code into a VST as a service?
Yes, we already have a prototype C++ generator as a command-line tool, so mixing that with some boilerplate to build a plugin will be something we do soon. And yes, the same thing would also work nicely if hosted as a web-service
I'm excited that audio-programming-in-the-browser is becoming a thing. It means more people are likely to fall down this exquisite rabbit hole. I'm totally in this field so I'll list a few websites that let you program music in the browser, and my rough opinion on them: - http://wavepot.com/ is just built on top of Javascript. The code tends to be long since the library is pretty bare-bones right now, but it's really…
But is a browser-based audio environment ever going to have the low latency and robustness requirements for something like live performance?
Low-Latency is one thing (now much better with AudioWorklet model), real-time rendering is another thing. With AudioWorklet the audio code now runs in a dedicated thread, but without real-time priority for now.