#21

I’m not particularly trying to step up to bat for SOUL here, but is there any kind of simple Faust web IDE? Something akin to jsfiddle or your pick of the litter of WebGL playgrounds?

From my perspective, this was one of the most compelling parts of the concept: start in a browser, and when you have something whose sound you like, you easily have a path to plugin/something reusable and portable.

#22

this: https://faust.grame.fr/editor/ ?

1 Like
#23

Gotcha. This is a good start, but clearly has a community building and education problem.

With something like ShaderToy, I can visit the homepage, and wind up on an open source demo that I can see and tweak in one click: https://www.shadertoy.com/view/4tVBDz (on my phone, at that)

Obviously SOUL as a language isn’t going to solve that problem, but the birds-eye observations and goals in the talk seem to be interested in addressing those problems.

#24

Faust can even target LaTeX. Just in case you want your DSP algorithm printed up as a 500-page set of mathematical equations… think holiday presents for in-laws.

So, basically it targets everything :slight_smile:

4 Likes
#25

This might be more what you’re looking for: the Faust Playground. https://faust.grame.fr/tools/playground/

But I totally agree. Faust has for a long time been mostly an academic project. Most of the doc is in the form of academic papers. There’s a lot of obvious work to do to make Faust accessible to a broader audience of developers. But improving the language, doing more with it & taking it to more platforms has been a much bigger priority for the core developers. Academics get rewarded for doing new things, more than for making anything easier. (I’m not sure they get rewarded for code maintenance at all.) And there’s a dearth of usability feedback in such contexts. I really do hope that as Faust finds more applications outside of academia, more resources can be contributed to the project in these areas.

OTOH, the capabilities of Faust are really compelling – to me at least – and the core language is quite solid – and, IMHO, beautiful.

1 Like
#26

FWIW, the “classic” Faust compiler (pre-LLVM) compiles a Faust program into a fairly well-documented C++ class, which you can then freely inspect, use & abuse as desired. (Although you’ll find the inner loop looks more like assembly code.) That’s still the standard behavior when you call the Faust compiler directly.

#27

Lately on the mailing list there’s been buzz around this SHARC port:

2 Likes
#29

SOUL author here :slight_smile:

Really interesting thread - just a couple of points I think need answering:

re: “Faust already does all this stuff”

  • Yep, Faust is a lovely piece of work!

  • Unfortunately, I’ve never been able to get my head around Faust… and that’s a common story. We’d never have attempted this project if it hinged on requiring end-users who are either motivated or capable of learning functional paradigms in order to use it. If openGLSL had been functional (which would have been much more elegant, and arguably a far better design), I strongly doubt whether it’d have taken off like it did.

  • We expect most of the audience for SOUL to be from areas where you don’t get functional thinkers:

    • Casual programmers who aren’t even particularly interested in audio, but who just need to make some sound in an app/game/whatever, and who are just about capable of dealing with basic procedural javascript, C# or java.
    • C++ programmers who are coming from the plugin world.
    • Electronic engineers who write a bit of C for microcontrollers.
    • Beginners and students - we have a lot of experience in JUCE of seeing the thought-patterns that beginners tend to fall into, and have tried to design SOUL to avoid all the usual pitfalls

  • We’ve said all along that SOUL the language is only half the story - the underlying IR and backend API will support any number of front-end languages, and we expect that Faust would be one of the first other languages that would be cross-compiled to run on the SOUL engine tech.

13 Likes
#30

thanks for dropping by @jules !

a burning question: how does hardware factor into SOUL?
since each targeted device has a specific dsp chip or fpga, do you++ intend on supporting a large number of them based on devices folks are using or offering an off-board solution?

2 Likes
#31

We’d obviously like to support as many platforms as possible, but exactly which ones we focus on will depend on partnerships as well as technical factors.

The long-term goal is of course to reach the point where we have enough users and enough hardware support that all the other hardware vendors will need to support it because of user demand and competition. Exactly which platforms we target in the short term to get there is what we’re currently figuring out.

2 Likes
#32

We can think of 2 ways to target the SOUL platform from Faust:

2 Likes
#33

thanks @jules for the info, Im looking forward to getting hold of the early api/demos…
do you think you will use Bela as an example target platform? (as you mentioned it in your talk)

I think it’l be great if other languages like faust can target it - the more developers that can use their exiting knowledge the better.

from a personal point of view (as a C++ developer), if it had been based on the functional paradigm (faust or otherwise) - the extra effort (for me) to learn it, would have meant id have not touched it during the development/testing phase (as I want to now) , rather id have waited until it was established.

so I agree this approach will help for more widespread adoption, which is i think critical for its success beyond being just another language/toolkit

really looking forward to hearing more over the coming months, where we get to see the meat on the bones :slight_smile:

#34

Thanks!

Yes - we’ve already been testing our code on a Bela board for about the last year! And the Bela guys are just down the road from us in London, which is handy :slight_smile:

1 Like
#35

Opening the platform to already established Domain Specific Languages (DSP) like the ones presented here at PAW http://faust.grame.fr/paw/, Kronos, Faust, Gen~, Csound, or the other well-known SuperCollider, Chuck, PureData…etc… will certainly contribute to its success.

#36

Absolutely. If we can create a platform that makes it easy to run all these front-ends, that’ll be awesome!

#37

Thanks :slight_smile:

#38

i finally watched the video (it is v. cool, thank you), it also made me think about gen~, maybe more than Faust. (not just technically but in the sense of explicitly wanting to target different off-board use cases with different partnerships…, um, this is just my guess/understanding of course.)

but agree in both of those environments one does seem to often run into edge cases and whatnot that are just easier to address with imperative programming. it feels difficult to make a complete “typical” DSP chain in Faust (as opposed to building blocks) which is too bad b/c it seems like the compiler would really shine with access to the entire graph from source to sink.

also, i hope that SOUL can operate in the frequency domain or have some kind of general multirate abstraction. it’s my favorite thing in gen~ and my least favorite lack in Faust.

#39

@jules Do you have a plan for supporting BLAS-like ( or Eigen like ) linear algebra methods and libraries ?
I see this as a key requirement for people to port the more involved designs and something that is non trivial to reimplement with optimal performance,

1 Like
#40

You can always use Faust to build the DSP components, and assemble them with some C++ glue (we provide some code to do that in the “architecture” part). This is the approach used in GeoShred for instance (the guitar model is one Faust DSP, as well as each effect in the effect chain) : http://www.wizdommusic.com/products/geoshred.html.

And yes, mutirate support for frequency domain processing is the next big thing to work on, and is currently a work in progress on our side.

1 Like
#41

hi @sletz, thanks for the response!

here’s just to say that i use faust in exactly this way for corporate clients - build a custom architecture “template” and UI class, and generate blocks for a larger c++ application as part of a build step. it has been a tremendously helpful tool esp in a rapid iteration/r+d context, when i can use other architecture files to e.g. generate matlab data for the same .dsp.

but there various issues large and small which prevent the wider use of the language in the application development process in my case [*]. a large-ish one is multirate support; i understand that it is WIP and am very grateful for the effort. but (for example) for super-low-groupdelay requirements i have to use weird non-uniform polyphase filters which are just a total mess or impossible to implement in Faust.

a minor but kinda expansive issue is the amount of post-processing that stilll seems inevitably necessary and has led to some ugly tooling after the faust compilation step. for (just one) example with small buffer sizes i end up having to factor out virtual for performance. i haven’t had the bandwidth to make deeper changes than using a custom UI class and a custom architecture template.

and finally a kinda blue-sky wish is to incorporate better leverage of SIMD instruction sets in the output. currently as i understand it the output is pretty generic (which is great for other reasons) set of like: add, sub, div, mul, load, store, and a few std function calls like powf (which i end up having to post-process or redefine with approximations appropriate to the variable range in question.) it adds up to a lot of faff after the cpp generation step.

but really, my complaint isn’t that it’s impossible or unfeasible to use faust for the building blocks (it’s great for that) - but, i always have a nagging feeling that the graph analysis stuff would do an even better job if it could “see” all the blocks at once. but when i try and factor some complicated routing/logic structure into Faust i just fail. because my brain is not good enough? functional paradigm is only a good match up to a point? a combination? :slight_smile:

this and the last post are my extremely long-winded way of agreeing that any environment that completely forbids imperative/procedural programming is a hard sell for purely pragmatic reasons.

anyways sorry this is rather OT in a way but in another way it seems maybe valuable to compare/contrast existing approaches for JIT-compiled domain-specific DSP languages. i happen to be using Faust pretty frequently these days for different applications than academic/creative, so hope my thoughts are at least a little useful.

gen~ i find helpful for kinda other applications, like when it already makes sense to use max, but also it’s more immediate as a scratch/playground area and nice that it can work transparently in a phase vocoder.

[*] to be more specific: i’m working in the hearing-enhancement / hearing-aid area. the DSP has to run on processors ranging from x86, to minimal ARM with NEON, to webASM, and its great to have something that at least gets me 75% there. (there are proprietary DSP targets too, but thankfully my responsibilities end before that point.)

4 Likes