KVR Audio

soundmodel · Post by **soundmodel** » Wed May 23, 2018 9:07 pm

Would it be possible to make VSTs as "polyglot" apps?

https://en.wikipedia.org/wiki/GraalVM

So that it'd be possible to develop VST using multiple languages "mixed together".

yellowmix · Post by **yellowmix** » Wed May 23, 2018 11:04 pm

Yes, of course. But why make it that complicated?

soundmodel · Post by **soundmodel** » Wed May 23, 2018 11:11 pm

yellowmix wrote:Yes, of course. But why make it that complicated?

I don't think polyglot complicates things. On the contrary.

yellowmix · Post by **yellowmix** » Wed May 23, 2018 11:28 pm

More power to you!

Rockatansky · Post by **Rockatansky** » Wed May 23, 2018 11:44 pm

It's already possible. I mainly code in C++ with patterns of C and the occasional ASM block.

Or did you really want to implement machine learning, vocabulary guessing and syntax intelligence into a compressor to avoid having to load one of several .ini files with pre-defined language strings to paint on its GUI?

soundmodel · Post by **soundmodel** » Thu May 24, 2018 12:22 am

Rockatansky wrote:It's already possible. I mainly code in C++ with patterns of C and the occasional ASM block.

Or did you really want to implement machine learning, vocabulary guessing and syntax intelligence into a compressor to avoid having to load one of several .ini files with pre-defined language strings to paint on its GUI?

More like:

Write DSP in C/C++, GUI in Java and then encapsulate the DSP as Python functions in order to carry out "higher level" things with lesser code.

BertKoor · Post by **BertKoor** » Thu May 24, 2018 10:03 am

I was at a presentation by Sam Aaron about his Sonic Pi project, and he mentioned in that project they had mixed at least half a dozen of languages, each used for their strength. So it is possible. For a VST I'd personally keep it simple, it's complicated enough already.

If a language compiles to .dll, it's all good. Otherwise I would strongly advise against it.

BTW: using an interpreted language like Python for DSP (critical inner loop) sounds like a REALLY bad design decision to me. Unless you cross-compile it first with Cython or Pythran ofcourse...

soundmodel · Post by **soundmodel** » Thu May 24, 2018 10:09 am

BertKoor wrote:I was at a presentation by Sam Aaron about his Sonic Pi project, and he mentioned in that project they had mixed at least half a dozen of languages, each used for their strength. So it is possible. For a VST I'd personally keep it simple, it's complicated enough already.

If a language compiles to .dll, it's all good. Otherwise I would strongly advise against it.

BTW: using an interpreted language like Python for DSP (critical inner loop) sounds like a REALLY bad design decision to me. Unless you cross-compile it first with Cython or Pythran ofcourse...

I don't know how they do it, but a lot of homebrew DSP tools, like BlueCat's Plug n' Script or Reapers ReaJS particularly rely on a higher level language to describe the DSP, but they might compile it down then to gain required speed. So the use of a higher level language is mainly because of wanting a more simplistic syntax.

resynthesis · Post by **resynthesis** » Thu May 24, 2018 10:26 am

What about SWIG http://www.swig.org/? I've only used it on Unix boxes (and not for a few years) but I believe the Windows version isn't too bad.

mystran · Post by **mystran** » Thu May 24, 2018 10:37 am

soundmodel wrote: Write DSP in C/C++, GUI in Java and then encapsulate the DSP as Python functions in order to carry out "higher level" things with lesser code.

The question you should be asking is not whether it's "technically possible" (because it certainly is), but rather whether it actually provides you any benefits (eg. in terms of programming time, cost, whatever). This actually applies to every library you add into a project, but it's usually much higher as you try to include larger frameworks or languages.

In general, embedding a "heavy weight VM" into a project is usually requires a non-trivial amount of work. Even if the VM itself is simple to get running (as is the case with something like Lua for example), there is still a fairly large upfront cost in terms of building interfaces between the native and managed worlds. In order to actually come ahead, this work needs to be offset by the savings you get from using the embedded language to implement some actual functionality.

As far as your specific example of using Java to write a GUI for a C++ plugin... I feel like you're probably trying to avoid a relatively simple problem (ie. writing a GUI in C++) by replacing it with a much more complicated problem (ie. getting the Java VM to interoperate with VST). I honestly can't see how this could ever actually end up beneficial, even taking into account the assumption that you might have to learn a new toolkit (or system API) from scratch to do the GUI programming natively.

hibrasil · Post by **hibrasil** » Thu May 24, 2018 2:35 pm

ignore...

hibrasil · Post by **hibrasil** » Thu May 24, 2018 2:35 pm

iPlug2 integrates FAUST and C++ ... coming soon

https://www.youtube.com/watch?v=4flMQB5Eo-k

soundmodel · Post by **soundmodel** » Thu May 24, 2018 4:25 pm

hibrasil wrote:iPlug2 integrates FAUST and C++ ... coming soon

https://www.youtube.com/watch?v=4flMQB5Eo-k

Awesome merging or two very good tools.

I already jumped to the JUCE bandwagon (because they changed the licenses), but might look back to WDL-OL, because of this.

hibrasil · Post by **hibrasil** » Thu May 24, 2018 6:05 pm

also made a JUCE module when i half got on the bandwagon

https://github.com/olilarkin/juce_faustllvm

resynthesis · Post by **resynthesis** » Thu May 24, 2018 9:59 pm

Ooh, have to try that. I played with Faust a while ago but became a little frustrated by the lack of response to queries about bug fixes. Nice work!