It appears that the delay uses an assembly pre-compiled object. Maybe needs a fork to remove the spring delay for building on arm64.
the pcm file seems to be an IR for the spring reverb; while i haven’t built this this looks a bit more like the SDK rules for BINARY / obj copy need to have an ARM fork.
Yes, the make file does have a SOURCES += and some how objcopy -I binary -O elf64-x86-64 -B i386:x86-64 --rename-section .data=.rodata,alloc,load,readonly,data,contents src/SpringReverbIR.pcm build/src/SpringReverbIR.pcm.bin.o seems to be invoked.
I had no problem doing an ARM64 build of befaco on macOS with my little builder script also, and I just tested and the spring reverb works fine for me in the free arm 2.2.2
That is invoked by the BINARIES += line by the way. which then triggers the OBJECTS with a subst to make a .bin.o from the binary then triggers the .bin.o rule at line 97 of compile.mk
I guess you are doing a linux arm64 build. The line you need to patch for arm is line 100 of compile.mk
This is a Chromebook build, and I had to add a new config.guess for libsamplrate-1.9 to build to get the main Rack to build. It might be a similar configuration detect error default.
its just that no-one has ported the rack binary inclusion rule to non-x86 on linux in the sdk.
It’s not an SDK build. It’s using a full rack build, and a make from the plugin/Befaco directory. So the SDK maybe there behind the scenes.
EDIT: A file hack and one module from plugin delete is now in progress.
compile.mk is the same in both the SDK and source version if that helps!
ifdef ARCH_LIN
$(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 --rename-section .data=.rodata,alloc,load,readonly,data,contents $< $@
endif
needs an ifdef with a different -O elf64-x86-64 -B i386:x86-64.
yup that’s the line
santa-arm64?
Or even better: Distribute Spring Reverb IR as a file instead of in the binary. · VCVRack/Befaco@b5e11be · GitHub
1 Like
Oh that is better! 
Surprisingly it wasn’t even a spelling bug. 