SOUL: A New Efficient, Portable, Low-Latency Audio Programming Language

Re:SOUL: A New Efficient, Portable, Low-Latency Audio Progra... by CyberDildonics on Friday December 07, 2018 @04:23PM (#18631820)

I really like what the Juce people have done but I still question most approaches to problems take the path of creating a new language. It seems to me something that could just as easily be a library is now constrained into sandbox where it can't be used nearly as easily or flexibly.

[ Parent | on HN ]

Re:SOUL: A New Efficient, Portable, Low-Latency Audio Progra... by teilo on Friday December 07, 2018 @04:40PM (#18631958)

This is not something that can be replaced with a library, anymore than a library can replace OpenGL itself.

Keep in mind that this is more analagous to a GL shader. It is not a general purpose language.

[ Parent | on HN ]

Re:SOUL: A New Efficient, Portable, Low-Latency Audio Progra... by CyberDildonics on Friday December 07, 2018 @05:59PM (#18632491)

There are already shading languages and DSLs that work on buffers like Halide. Halide especially seems very good at transformations on buffers.

[ Parent | on HN ]

Re:SOUL: A New Efficient, Portable, Low-Latency Audio Progra... by stabbles on Friday December 07, 2018 @04:41PM (#18631963)

Maybe a better approach is to take an existing language and build a DSL for it

[ Parent | on HN ]

Re:SOUL: A New Efficient, Portable, Low-Latency Audio Progra... by kjeetgill on Friday December 07, 2018 @05:59PM (#18632487)

Respectfully disagree. DSLs embedded into another language are doubly terrible. Independent DSLs like GLSL or SQL are tricky to get right, but work; but they're just their own languages.

With embedded DSLs you don't get the portability of a library and reusability of a library, but instead get a horribly crooked, compromised, limited grammar based on the meta-programming limitations of the hosting language (looking at you gradle!).

[ Parent | on HN ]