I don't think so. This would require using a SoundUI object as explained here: https://faustdoc.grame.fr/manual/architectures/#developing-a-new-soundfile-loader
But since HISE use based on JUCE, then using the already written JuceReader should be strait forward.
The lastest release is Faust 2.79.3, see https://github.com/grame-cncm/faust/releases
/usr/lib/llvm-13/
this LLVM version is too old: use at least LLVM 15.
Faust lib reverbs:
https://faustlibraries.grame.fr/libs/reverbs/ can be tested here: https://faustdoc.grame.fr/examples/reverb/
Some other Faust coded reverbs here:
https://github.com/LucaSpanedda/Digital_Reverberation_in_Faust
@sletz Well, I just discovered that https://github.com/grame-cncm/faust/tree/master-dev-ocpp-od-fir-2-FIR. branch is still quite buggy, so no need to rush 
@aaronventure Trying to create binaries on the GitHub CI, but still some problems to solve.
In the meantime you can possibly try the Faust IDE Ondemand aware version: https://grame-cncm.github.io/faustide-od/
@aaronventure Note that in case you can directly compile Faust + LLVM, the WIP branch with ondemand working is here: https://github.com/grame-cncm/faust/tree/master-dev-ocpp-od-fir-2-FIR.
We are interested in feedback, in case you HISE guys can test it 
@aaronventure The reason is that maintaining this enable/control feature adds complexity in the compiler that we want now to cleanup.
@aaronventure Guys, we will not maintain enable/control for backward compatibility 
, so you are warned !
This is probably because the same labels (like BOOST, ATTEN) are used in different places.
try to use unique labels to confirm this hypothesis
then @Christoph-Hart this should be considered as a bug. Same labels can be used, but will internally correspond to differents pathnames (built following the group hierarchy).
The code https://github.com/christophhart/HISE/blob/develop/hi_faust/FaustUI.h does not use the pathname model so I guess UI items with same labels will be considered the same, which is not what is needed. Look at MapUI code to see how labels/shornames/pathnames can be used: https://faustdoc.grame.fr/manual/architectures/#some-useful-ui-classes-and-tools-for-developers
I don't understand at all:
what is ""FAUST Hardcoded Master FX" ?
what is the problematic Faust DSP code" ?
We have tools to help debugging, read:
https://faustdoc.grame.fr/manual/debugging/#debugging-at-runtime
https://faustdoc.grame.fr/tutorials/debugging/
This interp-tracer tool is currently to be used in the terminal, so requires a local installation. But in theory this kind of tool could be integrated in HISE , since the libfaust library used in HISE also embeds the needed Interpreter backend.
For more local NAN protection, using ma.EPSILON is a more portable solution, since is adapts the single/double compilation option.
@Morphoice abs(x) < 0.0000000000000000555111512312578270211815834045
hum seems like a non human intervention here ?
Really nice 
!
Ready to be added in the "Powered by Faust" page https://faust.grame.fr/community/powered-by-faust/ ? If yes just send me some material, screenshot, presentation text...etc..
Extract of Shihong Ren thesis "Creating an Online Platform and Tools for Real-Time Music Composition and Signal Processing"
3e5870ee-509c-4f16-880e-65c17ebfbee2-These_Shihong_REN-FFT.pdf These_Shihong_REN-FFT
@AxiomCrux No this FFT code can only work in a specialised "hacked" Faust IDE version that does FFT/iFF around the actual Faust DSP, using a social architecture, basically following the Max/MSP pfft model (https://docs.cycling74.com/legacy/max8/refpages/pfft~). This is not "official".
@Morphoice the first 1* part is just useless right ? (also Faust will optimise this itself of course)
Nice to meet you guys ! Sorry for coming late, I will be more prepared next time.