Faust is here...

[lalalandsynth]

@Christoph-Hart This is crazy !

[sletz]

@etXzat and @Christoph-Hart did most of the hard work of "inside HISE" integration and they have to be thanked for that.

On the Faust side, the project adds to the existing ecosystem (https://faust.grame.fr/community/made-with-faust/) and we are quite happy with that :beaming_face_with_smiling_eyes:

@etXzat or @Christoph-Hart do you have a nice screenshot we could add on the https://faust.grame.fr/community/made-with-faust/ page?

[ps]

What an awesome addition! Thanks for all the effort.
So I compiled Hise with Faust enabled and made a Faust node in Scriptnode using the reverb example (in a dry/wet split node) - it compiled inside scriptnode like a charm and sounds just great :)
To make sure everything works as expected in a compiled plugin I at first compiled as an FX Plugin with leaving the network "open" - it compiled without errors. (AU Mac M1) but inside the DAW the test plugin showed but the reverb was not audible, like if the node was bypassed.
So I tried compiling the network as .dll first. Once I hit the compile button HISE instantly crashed and also the HISE preset crashes instantly now when I try to open it again.
Did I miss something?
Thanks for the help!

[Christoph Hart]

but inside the DAW the test plugin showed but the reverb was not audible, like if the node was bypassed.

This is expected behavior - the faust JIT compiler is not part of an exported plugin, so it will be replaced by a dummy node. However I can add an error message that will complain if you trying to export a plugin with a non-compiled faust node (I have a system for this in place for other nodes like SNEX nodes and expression nodes so it shouldn't be too much effort).

Once I hit the compile button HISE instantly crashed and also the HISE preset crashes instantly now when I try to open it again.

This isn't expected behaviour :)

Can you run a debug build of HISE to see the stack trace where it crashes? Run HISE with the Xcode debugger which should point you to the stack location causing the crash.

[Goodflow]

@Christoph-Hart not op but having the same problem on an Intel Mac ( OSX 12.5.1/ Xcode 13.1), so hopefully this helps. I printed a full stack trace after replicating the error in Xcode debug and found this:

* thread #32, name = 'Compile DSP networks', stop reason = EXC_BAD_ACCESS (code=2, address=0x70000e940ce0)
  
  frame #0: 0x0000000121179549 libfaust.2.dylib`SignalPromotion::transformation(CTree*) + 25

and this

* frame #289: 0x0000000110679c6b HISE Debug`faust::generateAuxFilesFromFile(filename="/Users/me/vstproject/DspNetworks/CodeLibrary/faust/freverb.dsp", argc=17, argv=0x0000600000b2f810, error_msg="") at libfaust.cpp:15:10

First time debugging, so apologies if this isn't the needed info. Loving the results of Faust in Scriptnode, can't wait to start implementing hardcoded effects!

[Christoph Hart]

Hmmm, actually I can reproduce that here too (with the re.jpverb example I posted above) and it crashes inside the Faust dll. I wrote this on Windows where it didn't crash, but it seems to reliably bring down macOS.

It's also always in SignalPromotion::transformation(CTree*), and it crashes whenever generateAuxFilesFromFile() is called (so it also crashes when clicking on the SVG graph popup button)

@sletz is this a known issue in Faust?

Also for the sake of readability I would suggest to create seperate topics about these kind of technical issues and leave this thread to rather generic discussions about Faust - remember we have a new subforum for Faust :)

[sletz]

@Christoph-Hart This is not a known problem. What is the DSP code? Do you have the full log? (possibly with a debug version of libfaust to get the precise crash line number?)

[Christoph Hart]

@sletz The exact code I posted above (the example that takes the jpreverb and wraps a few parameters around it.

https://forum.hise.audio/topic/6505/faust-is-here/9

If I load that in HISE, the reverb loads and the JIT compiler works perfectly, but anytime I call generateAuxFilesFromFile (so either when creating the SVG images or when exporting to C++ during the DLL compilation) it always crashes at said location.

I haven't build the libfaust Debug build yet so the stack trace only gives me the last function (might be a good idea going forward though), but it's super easily reproducible on macOS (on Windows it works fine).

• Load up HISE
• create a scriptnode patch
• create a faust node
• paste in the example code, compile

Click on the eye icon which opens the SVG popup. It will create the SVG files for a few seconds, then crash in the method above.

[ps]

@Christoph-Hart just a quick confirmation from my side - same error in Xcode - I just compiled the compressor demo without problems so it’s def related to```

generateAuxFilesFromFile

[sletz]

@ps I cannot reproduce the error here with latest Faust GitHub master-dev branch, on Intel and macOS 10.13 :

• compiled libfaust in shared mode (so make all && sudo make install)
• had to add -lfaust and /use/local/lib in Xcode generated project to properly link the library
• then create a new project ScripNodeFX, faust, copied the jpverb DSP code
• compile so I see the GUI with buttons
• opened the SVG file
• no crash...

[sletz]

BTW libfaust can be compiled in debug mode editing this Makefile here: https://github.com/grame-cncm/faust/blob/master-dev/build/Makefile#L52

Having a proper crash log will possibly help.

[Christoph Hart]

Alright I‘ll try to build the debug version later and check if I can get a stacktrace.

[ps]

@sletz hi sletz - compiling the node inside scriptnode works here as well - exporting the node crashes hise. Just to double check - that works on your side as well?

[sletz]

@ps Not tried export for now. Which kind of crash? (any crashlog..etc...)

[ps]

@sletz hise is crashing the moment the compilation starts and is unable to reopen the preset containing the script fx later on (Instant crash)

when trying to compile the network as .dll

return ::generateAuxFilesFromFile(filename, argc, argv, error_msg);

Compile DSP networks (25): EXC_BAD_ACCESS (code=2, address=0x315d53ce0)

when I try to reopen the preset:

 { return (llvm_dsp_factory*)::createDSPFactoryFromString(name_app, dsp_content, argc, argv, target, error_msg, opt_level); }

Sample Loading Thread (7): EXC_BAD_ACCESS (code=2, address=0x31a4add60)

[sletz]

Could not reproduce the crash at export time. The C++ file is properly generated, even if I get a 'ipp.h' file not found" related issue later on in the export step.

[Christoph Hart]

Just FYI: I've added polyphony & MIDI support for Faust, so if you've been holding off because you want to play around with the physical modeling library in Faust there's no reason anymore :)

With this feature, we can consider the Faust integration to be feature-complete for now (the complex data interface has to wait a few months, but I don't think that's a critical feature) so I can now go back to fixing the bugs, yay...

[ps]

@Christoph-Hart awesome! is there any way we can get information out of Faust nodes.. eg using analyser modules?
Ah and btw could get any information regarding the generateAuxFilesFromFile crash?

[Christoph Hart]

@ps If you declare a hbargraph primitive in your faust code it will use it as modulation source so you can connect it to any target in script node and propagate it to the UI using a peak node or whatever.

It currently works only with a single modulation source, but maybe I'll add multiple modulation outputs.

The crash is super annoying to debug, we're working on it and I can reproduce it with a Debug build, but @sletz cannot get this patch to crash, so we're stuck now trying to find the root of the issue (a vanilla test project with libfaust doesn't crash with the example code but the crash happens inside libfaust so we don't know where the error occurred).

[ps]

@Christoph-Hart awesome stuff with the hbargraph and very unfortunate with the crash - fingers crossed that you will find the root of evil here :)
Just tried to compile the latest develop to give the midi a try - build fails on my m1

 using vSIMDType = typename NativeOps::vSIMDType;

Implicit instantiation of undefined template 'juce::dsp::SIMDNativeOps<unsigned long>'