Faust 2.58.11 to test
We are working with David Braun to compile Faust using GitHub actions. This actually solves the "LLVM not self-contained" issue we had with last published version.
Can you Faust users test the compiled X86 and ARM64 version here :
@sletz Just checked the x64 build on an M1 MacBook under Rosetta and it yields this error:
@sletz I got the same result as Christoph using the X64 version
OK, I was able to reproduce the problem on a test program.
@Christoph-Hart you'll have to explicitly set the
targetparameter to "x86_64-apple-darwin" when using the
Can you test on your side and report?
@sletz Now it compiles but crashes at
Faust: Resizing buffers: nChannels=0, blockSize=0 Faust: Resizing buffers: nChannels=0, blockSize=0 Faust: Resizing buffers: nChannels=0, blockSize=0 Faust: Resizing buffers: nChannels=0, blockSize=0 Global Faust Path: /Users/christophhart/Development/faust Global Faust Path: /Users/christophhart/Development/faust Faust jit compilation successfu::
Assembly stack trace (not expecting to be helpful, but anyways):
0x1113b99f0 <+0>: pushq %rbp 0x1113b99f1 <+1>: movq %rsp, %rbp 0x1113b99f4 <+4>: pushq %rbx 0x1113b99f5 <+5>: pushq %rax 0x1113b99f6 <+6>: movq %rdi, %rbx -> 0x1113b99f9 <+9>: movq 0x18(%rsi), %rsi 0x1113b99fd <+13>: movq (%rsi), %rax 0x1113b9a00 <+16>: callq *0x58(%rax) 0x1113b9a03 <+19>: movq %rbx, %rax 0x1113b9a06 <+22>: addq $0x8, %rsp 0x1113b9a0a <+26>: popq %rbx 0x1113b9a0b <+27>: popq %rbp 0x1113b9a0c <+28>: retq 0x1113b9a0d <+29>: nopl (%rax)
Same issue using the Interp backend, although this
getWarningMessagesmethod is not called at all.... No more idea for now. I see libfaust is still called in a separated thread ?
And what happens on a real Intel machine ? (the compiled version is for macOS 10.15 minimum, and I still have a 10.13 here where I could not test).
I've found the problem: changes in the Faust dsp/dsp_factory API, and since HISE is maintaining it's own version, this make the thing quite fragile.. @Christoph-Hart I'll send you a patch.
@sletz Yes I can confirm that the patch you send me works now (I had to add the
darwinflag but apart from that everything loaded fine).
However now it won't compile against the old Faust (2.50.6 or whatever it was) because the old API doesn't have the
getWarningMessage()function. Is there a preprocessor macro in the faust headers that I can query for the version and conditionally include the
getWarningMessage()function definition? I would love to not force everybody to update their Faust installation to keep using it.
FAUSTVERSIONwork for that?
Function added in 2.54.0, see: https://github.com/grame-cncm/faust/commit/a962231a9ca985cfa2ba513c01028872af62b115
BTW: now I understand why the latest published 2.54.9 version was also crashing !?
@sletz The problem is that this is a preprocessor string and it's impossible to use it in a conditional expression. I've added a manual projucer flag in the
hi_faust_typesmodule that the user has to switch on if he wants to keep using the old faust version (
OLD_FAUST_API_SUPPORT), but this is only a very low level solution that only removes the
getWarningMessage()function from the Faust wrappers and will probably cause issues again with the next breaking API change.
If you could add integer versions of the version, this would allow people to check the library version conditionally (and I could remove that flag and let the system figure it out automatically). Usually it's done like this:
#define FAUSTMAJORVERSION 2 #define FAUSTMINORVERSION 50 #define FAUSTPATCHVERSION 6
then I could use
#if FAUSTMAJORVERSION <= 2 && FAUSTMINORVERSION <= 54 #define OLD_FAUST_API_SUPPORT 1 #else #define OLD_FAUST_API_SUPPORT 0 #endif
classInitmethod in dsp_factory class, https://github.com/grame-cncm/faust/commit/90d40d425dac7557667387e3a8a5f4b44ce1ae43.
Version raised to 2.59.0, possible breaking for HISE integration.
Working with 2.59.1 without changes.
for those looking....
down the bottom of the page 2.59.2