a buffer full of a const that is not zero will be giving you the same as unweighted, as it will give every item the same weight. It is still a strange thing that this is needed but in the meantime that might help.
p
1 Like
Thanks for tracking that down @pikseliahky – so now I understand where the -1 comes from, but not why the code moans 
Looking at the condition that leads to that error message, it’s checking a bufnum against the reported number of buffers on the server and only triggers if the bufnum is greater than this count. So this being true for a bufnum of -1 is weird and troubling. OTOH, I can at least confirm that it should still behave as expected error message notwithstanding.
If you do want to shut it up, then a dummy buffer of constant non-zero entries will do the job, as @tremblap says.
The crashes with larger audio files are still baffling though. Do you get any useful information in /var/logs? Memory exhaustion isn’t impossible, but it’d be good to track it down and see if we can streamline things a bit.
1 Like
Thanks for the hints. With the provided buffer of non-zero values the analysis runs fine.
Then I’ve tried to look at the kernel log when attempting to slice a longer audio buffer and, indeed, this looks like a memory problem:
Jul 7 10:31:47 bela kernel: [ 1065.604500] rtdm_pruss_irq_open
Jul 7 10:31:53 bela kernel: [ 1071.154327] node invoked oom-killer: gfp_mask=0x14201ca(GFP_HIGHUSER_MOVABLE|__GFP_COLD), nodemask=(null), order=0, oom_score_adj=0
Jul 7 10:31:54 bela kernel: [ 1071.154374] CPU: 0 PID: 479 Comm: node Tainted: G W O 4.14.108-ti-xenomai-r143 #1xross
Jul 7 10:31:54 bela kernel: [ 1071.154382] Hardware name: Generic AM33XX (Flattened Device Tree)
Jul 7 10:31:54 bela kernel: [ 1071.154389] I-pipe domain: Linux
Jul 7 10:31:54 bela kernel: [ 1071.154437] [<c0110ad4>] (unwind_backtrace) from [<c010e098>] (show_stack+0x20/0x24)
Jul 7 10:31:54 bela kernel: [ 1071.154454] [<c010e098>] (show_stack) from [<c0c3e7e4>] (dump_stack+0x24/0x28)
Jul 7 10:31:54 bela kernel: [ 1071.154481] [<c0c3e7e4>] (dump_stack) from [<c0297748>] (dump_header+0xc4/0x268)
Jul 7 10:31:54 bela kernel: [ 1071.154499] [<c0297748>] (dump_header) from [<c0296880>] (oom_kill_process+0x34c/0x5ec)
Jul 7 10:31:54 bela kernel: [ 1071.154513] [<c0296880>] (oom_kill_process) from [<c02974cc>] (out_of_memory+0x200/0x32c)
Jul 7 10:31:54 bela kernel: [ 1071.154532] [<c02974cc>] (out_of_memory) from [<c029c910>] (__alloc_pages_nodemask+0xa80/0xd64)
Jul 7 10:31:54 bela kernel: [ 1071.154548] [<c029c910>] (__alloc_pages_nodemask) from [<c0292c38>] (filemap_fault+0x344/0x66c)
Jul 7 10:31:54 bela kernel: [ 1071.154567] [<c0292c38>] (filemap_fault) from [<c03c2b6c>] (ext4_filemap_fault+0x38/0x4c)
Jul 7 10:31:54 bela kernel: [ 1071.154585] [<c03c2b6c>] (ext4_filemap_fault) from [<c02c5dd4>] (__do_fault+0x3c/0x154)
Jul 7 10:31:54 bela kernel: [ 1071.154602] [<c02c5dd4>] (__do_fault) from [<c02cab5c>] (handle_mm_fault+0x4f8/0xd58)
Jul 7 10:31:54 bela kernel: [ 1071.154628] [<c02cab5c>] (handle_mm_fault) from [<c0c5c678>] (do_page_fault+0x21c/0x490)
Jul 7 10:31:54 bela kernel: [ 1071.154646] [<c0c5c678>] (do_page_fault) from [<c0101468>] (do_PrefetchAbort+0x58/0x148)
Jul 7 10:31:54 bela kernel: [ 1071.154662] [<c0101468>] (do_PrefetchAbort) from [<c0c5c18c>] (ret_from_exception+0x0/0x34)
Jul 7 10:31:54 bela kernel: [ 1071.154671] Exception stack(0xcb2fffb0 to 0xcb2ffff8)
Jul 7 10:31:54 bela kernel: [ 1071.154683] ffa0: 017d9418 032487a0 bee41880 00000000
Jul 7 10:31:54 bela kernel: [ 1071.154696] ffc0: bee41cf4 bee41880 03248778 032487a0 00000000 000001b6 031dd948 bee41ca4
Jul 7 10:31:54 bela kernel: [ 1071.154708] ffe0: 0109b974 bee41738 004f4ab4 005a74a4 800f0010 ffffffff
Jul 7 10:31:54 bela kernel: [ 1071.154715] Mem-Info:
Jul 7 10:31:54 bela kernel: [ 1071.154737] active_anon:16854 inactive_anon:2994 isolated_anon:0
Jul 7 10:31:54 bela kernel: [ 1071.154737] active_file:9 inactive_file:14 isolated_file:0
Jul 7 10:31:54 bela kernel: [ 1071.154737] unevictable:97240 dirty:0 writeback:0 unstable:0
Jul 7 10:31:54 bela kernel: [ 1071.154737] slab_reclaimable:2560 slab_unreclaimable:1853
Jul 7 10:31:54 bela kernel: [ 1071.154737] mapped:10285 shmem:5209 pagetables:498 bounce:0
Jul 7 10:31:54 bela kernel: [ 1071.154737] free:609 free_pcp:0 free_cma:0
Jul 7 10:31:54 bela kernel: [ 1071.154753] Node 0 active_anon:67416kB inactive_anon:11976kB active_file:36kB inactive_file:56kB unevictable:388960kB isolated(anon):0kB isolated(file):0kB mapped:41140kB dirty:0kB writeback:0kB shmem:20836kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
Jul 7 10:31:54 bela kernel: [ 1071.154774] Normal free:2436kB min:2820kB low:3524kB high:4228kB active_anon:67416kB inactive_anon:11976kB active_file:36kB inactive_file:56kB unevictable:388960kB writepending:0kB present:524288kB managed:499296kB mlocked:388960kB kernel_stack:840kB pagetables:1992kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
Jul 7 10:31:54 bela kernel: [ 1071.154780] lowmem_reserve[]: 0 0 0
Jul 7 10:31:54 bela kernel: [ 1071.154806] Normal: 75*4kB (UME) 33*8kB (ME) 7*16kB (ME) 9*32kB (UME) 7*64kB (UM) 6*128kB (UM) 1*256kB (M) 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB = 2436kB
Jul 7 10:31:54 bela kernel: [ 1071.154918] 13235 total pagecache pages
Jul 7 10:31:54 bela kernel: [ 1071.154926] 0 pages in swap cache
Jul 7 10:31:54 bela kernel: [ 1071.154934] Swap cache stats: add 0, delete 0, find 0/0
Jul 7 10:31:54 bela kernel: [ 1071.154940] Free swap = 0kB
Jul 7 10:31:54 bela kernel: [ 1071.154946] Total swap = 0kB
Jul 7 10:31:54 bela kernel: [ 1071.154953] 131072 pages RAM
Jul 7 10:31:54 bela kernel: [ 1071.154959] 0 pages HighMem/MovableOnly
Jul 7 10:31:54 bela kernel: [ 1071.154965] 6248 pages reserved
Jul 7 10:31:54 bela kernel: [ 1071.154972] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
Jul 7 10:31:54 bela kernel: [ 1071.155002] [ 102] 0 102 7058 539 10 0 0 0 systemd-journal
Jul 7 10:31:54 bela kernel: [ 1071.155016] [ 139] 0 139 3258 379 8 0 0 -1000 systemd-udevd
Jul 7 10:31:54 bela kernel: [ 1071.155028] [ 179] 100 179 3986 411 9 0 0 0 systemd-timesyn
Jul 7 10:31:54 bela kernel: [ 1071.155040] [ 184] 0 184 744 302 6 0 0 0 cron
Jul 7 10:31:54 bela kernel: [ 1071.155051] [ 187] 0 187 358 258 4 0 0 0 bela-cape-btn
Jul 7 10:31:54 bela kernel: [ 1071.155064] [ 189] 107 189 1332 370 6 0 0 0 avahi-daemon
Jul 7 10:31:54 bela kernel: [ 1071.155076] [ 190] 0 190 1408 357 8 0 0 0 systemd-logind
Jul 7 10:31:54 bela kernel: [ 1071.155088] [ 192] 105 192 1302 355 6 0 0 -900 dbus-daemon
Jul 7 10:31:54 bela kernel: [ 1071.155099] [ 198] 107 198 1300 252 6 0 0 0 avahi-daemon
Jul 7 10:31:54 bela kernel: [ 1071.155111] [ 204] 0 204 5552 444 8 0 0 0 rsyslogd
Jul 7 10:31:54 bela kernel: [ 1071.155123] [ 365] 0 365 1315 349 6 0 0 0 dhclient
Jul 7 10:31:54 bela kernel: [ 1071.155134] [ 389] 0 389 1315 333 6 0 0 0 dhclient
Jul 7 10:31:54 bela kernel: [ 1071.155146] [ 435] 0 435 1315 350 6 0 0 0 dhclient
Jul 7 10:31:54 bela kernel: [ 1071.155158] [ 479] 0 479 33244 7763 87 0 0 0 node
Jul 7 10:31:54 bela kernel: [ 1071.155170] [ 498] 0 498 2125 414 9 0 0 -1000 sshd
Jul 7 10:31:54 bela kernel: [ 1071.155181] [ 505] 0 505 923 272 6 0 0 0 agetty
Jul 7 10:31:54 bela kernel: [ 1071.155192] [ 508] 0 508 456 254 4 0 0 0 agetty
Jul 7 10:31:54 bela kernel: [ 1071.155204] [ 511] 0 511 456 270 5 0 0 0 agetty
Jul 7 10:31:54 bela kernel: [ 1071.155216] [ 525] 0 525 677 274 5 0 0 0 bash
Jul 7 10:31:54 bela kernel: [ 1071.155227] [ 532] 0 532 3732 531 11 0 0 0 journalctl
Jul 7 10:31:54 bela kernel: [ 1071.155238] [ 607] 0 607 2125 434 7 0 0 0 sshd
Jul 7 10:31:54 bela kernel: [ 1071.155249] [ 609] 0 609 459 300 4 0 0 0 sftp-server
Jul 7 10:31:54 bela kernel: [ 1071.155261] [ 983] 0 983 3732 531 9 0 0 0 journalctl
Jul 7 10:31:54 bela kernel: [ 1071.155272] [ 1047] 0 1047 452 315 5 0 0 0 make
Jul 7 10:31:54 bela kernel: [ 1071.155284] [ 1082] 0 1082 357 226 5 0 0 0 sh
Jul 7 10:31:54 bela kernel: [ 1071.155295] [ 1084] 0 1084 700 302 5 0 0 0 bash
Jul 7 10:31:54 bela kernel: [ 1071.155306] [ 1089] 0 1089 22958 8520 31 0 0 0 sclang
Jul 7 10:31:54 bela kernel: [ 1071.155318] [ 1123] 0 1123 103797 97276 204 0 0 0 scsynth
Jul 7 10:31:54 bela kernel: [ 1071.155329] [ 1141] 0 1141 94 31 3 0 0 0 dhclient-script
Jul 7 10:31:54 bela kernel: [ 1071.155338] Out of memory: Kill process 1123 (scsynth) score 757 or sacrifice child
Jul 7 10:31:54 bela kernel: [ 1071.183302] Killed process 1123 (scsynth) total-vm:415188kB, anon-rss:348760kB, file-rss:32152kB, shmem-rss:8192kB
Jul 7 10:31:54 bela kernel: [ 1071.226294] oom_reaper: reaped process 1123 (scsynth), now anon-rss:348756kB, file-rss:32140kB, shmem-rss:8192kB
Jul 7 10:31:54 bela kernel: [ 1071.253894] rtdm_pruss_irq_close
No idea if this is solvable or we would really have to stick to a shorter audio buffer on Bela…
The s.options.memSize is 8192 * 8 as of now, and it does not seem to allow much more without throwing a std::bad_alloc error.
Thanks for chasing that down. Bummer that it’s running out so quickly. In this case it won’t even be a function of the server memory, because the Buf* processes are able to allocate directly from the heap.
I know that there’s scope these processes to make better use of memory, although it hasn’t been critical up to this point: but here’s some motivation to address it (and get an up to date Bela build into the world).
There is a pain in the arse workaround, which will be to load up and analyse longer files in sections. You’ll need to do this by actually copying sections into a shorter source buffer: using the numFrames stuff doesn’t yet entail any memory savings (it will, one day, promise).
1 Like
Anyone working on an updated Bela build since the project hit 1.0 (congrats btw!)?
I’ve still been trying to build myself using distcc but still coming up against some issues 
Not personally, I know @weefuzzy is deep in refactoring some framework level code so he might not be in the headspace… or it might be perfect
It’s on my radar, although I’m a bit worried that our move to C++17 might complicate things.
What issues coming up with distcc? Is this using the 3.8g image? Did you ever try doing a straight cross compile instead of distcc?
Is your C++17 migration going to be a 1.0.x release? should in theory be fine…
I did try a cross compile based on your notes in Guidance building for Bela platform - #23 by weefuzzy but ran into a wall with linker errors:
flucoma-sc/build on main [?] via 🅒 base
➜ cmake -DSC_PATH=/Users/blahblah/supercollider-src --toolchain ../arm-linux-gnueabihf.cmake ..
-- The CXX compiler identification is Clang 13.0.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: /opt/homebrew/opt/llvm/bin/clang++
-- Check for working CXX compiler: /opt/homebrew/opt/llvm/bin/clang++ - broken
CMake Error at /opt/homebrew/Cellar/cmake/3.22.3/share/cmake/Modules/CMakeTestCXXCompiler.cmake:62 (message):
The C++ compiler
"/opt/homebrew/opt/llvm/bin/clang++"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /Users/blahblah/flucoma-sc/build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make -f Makefile cmTC_8779f/fast && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/cmTC_8779f.dir/build.make CMakeFiles/cmTC_8779f.dir/build
Building CXX object CMakeFiles/cmTC_8779f.dir/testCXXCompiler.cxx.o
/opt/homebrew/opt/llvm/bin/clang++ --target=arm-linux-gnueabihf --sysroot=/Users/blahblah/armsysroot -I/usr/local/opt/llvm/include -isystem=/Users/blahblah/armsysroot/usr/include/c++/6.3.0 -isystem=/Users/blahblah/armsysroot/usr/include/carm-linux-gnueabihf -B/Users/blahblah/armsysroot/usr/lib/gcc/arm-linux-gnueabihf/6.3.0 -march=armv7-a -mtune=cortex-a8 -mfloat-abi=hard -mfpu=neon -std=c++17 -MD -MT CMakeFiles/cmTC_8779f.dir/testCXXCompiler.cxx.o -MF CMakeFiles/cmTC_8779f.dir/testCXXCompiler.cxx.o.d -o CMakeFiles/cmTC_8779f.dir/testCXXCompiler.cxx.o -c /Users/blahblah/flucoma-sc/build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
Linking CXX executable cmTC_8779f
/opt/homebrew/Cellar/cmake/3.22.3/bin/cmake -E cmake_link_script CMakeFiles/cmTC_8779f.dir/link.txt --verbose=1
/opt/homebrew/opt/llvm/bin/clang++ --target=arm-linux-gnueabihf --sysroot=/Users/blahblah/armsysroot -I/usr/local/opt/llvm/include -isystem=/Users/blahblah/armsysroot/usr/include/c++/6.3.0 -isystem=/Users/blahblah/armsysroot/usr/include/carm-linux-gnueabihf -B/Users/blahblah/armsysroot/usr/lib/gcc/arm-linux-gnueabihf/6.3.0 -march=armv7-a -mtune=cortex-a8 -mfloat-abi=hard -mfpu=neon CMakeFiles/cmTC_8779f.dir/testCXXCompiler.cxx.o -o cmTC_8779f
/opt/homebrew/bin/arm-linux-gnueabihf-ld: cannot find /lib/ld-linux-armhf.so.3 inside /Users/blahblah/armsysroot
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [cmTC_8779f] Error 1
make: *** [cmTC_8779f/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:41 (project)
With distcc I wasn’t able to figure out this NEON support issue:
root@bela:~/flucoma-sc/build# make install
[ 2%] Built target flucoma_VERSION_LIB
[ 5%] Built target FLUID_SC_COPYREPLYADDR
[ 5%] Building CXX object _deps/flucoma-core-build/CMakeFiles/HISSTools_FFT.dir/__/hisstools-src/HISSTools_FFT/HISSTools_FFT.cpp.o
In file included from /root/flucoma-sc/build/_deps/hisstools-src/HISSTools_FFT/HISSTools_FFT.cpp:3:
In file included from /root/flucoma-sc/build/_deps/hisstools-src/HISSTools_FFT/HISSTools_FFT_Core.h:9:
/usr/lib/llvm-11/lib/clang/11.0.1/include/arm_neon.h:32:2: error: "NEON support not enabled"
#error "NEON support not enabled"
It’s already been bumped for a few versions prior to 1.0.0. Just using the language features and those library features that are header only (like std::optional).
That rings a bell - I think I had to export my PATH with the homebrew LLVM glued to the front to ensure that it actually called the right linker, but from your error message that’s not the problem:
/opt/homebrew/bin/arm-linux-gnueabihf-ld: cannot find /lib/ld-linux-armhf.so.3 inside /Users/blahblah/armsysroot
so it’s calling the right linker but can’t find /lib/ld-linux-armhf.so.3 in the toolchain root.
Hmm, ok. Maybe we’re missing a flag to pass to our FFT library there – I’ll have a check.
It’s a clang error message. I think you need to make sure that the CXXFLAGS have -mfloat-abi=hard -mfpu=neon (
)
so it’s calling the right linker but can’t find /lib/ld-linux-armhf.so.3 in the toolchain root.
Yeah, I was pretty confused about how to download/install this for macOS. arm-linux-gnueabihf-binutils and llvm don’t seem to have everything that’s needed for this to work…?
It’s a clang error message. I think you need to make sure that the CXXFLAGS have -mfloat-abi=hard -mfpu=neon (
Yeah, it fails with the same error when I try to make install like this too:
CC="distcc-clang" CXX="distcc-clang++" CXXFLAGS="-mfloat-abi=hard -mfpu=neon" make install
I couldn’t get to the bottom of it 
Giulio from Bela kindly did some further digging around with the distcc approach.
Compiling with:
cmake .. -DSC_PATH=/root/supercollider -DCMAKE_CXX_COMPILER=distcc-clang++ -DCMAKE_C_COMPILER=distcc-clang -DCMAKE_CXX_FLAGS='-mfpu=neon -mfloat-abi=hard' -DCMAKE_C_FLAGS='-mfpu=neon -mfloat-abi=hard'
Results in:
In file included from /root/flucoma-sc/build/generated_sources/FluidBufTransients.cpp:11:
In file included from /root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/TransientClient.hpp:19:
In file included from /root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../../algorithms/public/TransientExtraction.hpp:13:
In file included from /root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ARModel.hpp:13:
In file included from /root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:14:
/root/flucoma-sc/build/_deps/hisstools-src/SIMDSupport.hpp:540:80: error: use of undeclared identifier 'vdivq_f32'
friend SIMDType operator / (const SIMDType& a, const SIMDType& b) { return vdivq_f32(a.mVal, b.mVal); }
^
/root/flucoma-sc/build/_deps/hisstools-src/SIMDSupport.hpp:547:54: error: use of undeclared identifier 'vsqrtq_f32'
friend SIMDType sqrt(const SIMDType& a) { return vsqrtq_f32(a.mVal); }
^
/root/flucoma-sc/build/_deps/hisstools-src/SIMDSupport.hpp:551:55: error: use of undeclared identifier 'vrndq_f32'
friend SIMDType trunc(const SIMDType& a) { return vrndq_f32(a.mVal); }
^
/root/flucoma-sc/build/_deps/hisstools-src/SIMDSupport.hpp:580:24: error: use of undeclared identifier 'vcvt_f64_f32'
vec.mData[0] = vcvt_f64_f32(vget_low_f32(mVal));
^
/root/flucoma-sc/build/_deps/hisstools-src/SIMDSupport.hpp:581:24: error: use of undeclared identifier 'vcvt_f64_f32'
vec.mData[1] = vcvt_f64_f32(vget_high_f32(mVal));
Then the same again with VERBOSE=true reveals the command:
/usr/local/bin/distcc-clang++ -DBOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE -DEIGEN_MPL2_ONLY=1 -DFluidBufTransients_EXPORTS -DJSON_DIAGNOSTICS=0 -DJSON_USE_IMPLICIT_CONVERSIONS=1 -I/root/flucoma-sc -I/root/flucoma-sc/build/_deps/flucoma-core-src/include -I/root/flucoma-sc/build/_deps/tl_optional-src/include -I/root/flucoma-sc/include -isystem /root/supercollider/include/plugin_interface -isystem /root/supercollider/include/common -isystem /root/supercollider/common -isystem /root/supercollider/external_libraries/boost -isystem /root/flucoma-sc/build/_deps/eigen-src -isystem /root/flucoma-sc/build/_deps/spectra-src/include -isystem /root/flucoma-sc/build/_deps/hisstools-src -isystem /root/flucoma-sc/build/_deps/json-src/single_include -mfpu=neon -mfloat-abi=hard -fPIC -fdiagnostics-color=always -Wall -Wextra -Wpedantic -Wreturn-type -Wconversion -Wno-c++11-narrowing -fvisibility=hidden -std=c++17 -o CMakeFiles/FluidBufTransients.dir/generated_sources/FluidBufTransients.cpp.o -c /root/flucoma-sc/build/generated_sources/FluidBufTransients.cpp
Seems to be that some A64 intrinsics (which aren’t available to Bela) are being called via HISSTools/SIMDSupport.hpp that shouldn’t be? cc @a.harker
https://developer.arm.com/architectures/instruction-sets/intrinsics/vdivq_f32
Thanks to you and Giulio for prodding at this!
Just so I’m clear, is the problem that it’s assuming the availability of A64 intrinsics whenever it’s on ARM, but actually on the Bela it should only be trying to use A32 intrinsics?
I don’t think I’ve ever tried to compile SIMDSupport.hpp on Bela (I’ve done other things with SIMD but I only needed +, * and - for that). One solution is to header guard the given methods (although that is likely to cause problems for other code). Another solution is to fall back to scalar on A32, or finally (most horrible) emulate those methods in scalar for A32.
Given that divide isn’t available I’d suggest that under A32 fallback to scalar should be used, because that’s fairly basic and you can’t really support much without it. That will slow a few things but FluCoMa doesn’t really too much on SIMDSupport.hpp and other things are more of a bottleneck that might also be slow.
I’m not able to look at this at the moment, but I’d consider a PR on the library is @weefuzzy is able to figure out the correct precompiled incantations, to say that under A32 the max Vector sizes should be 1 (scalar).
1 Like
I can have a crack It’ll be somewhere around here, right?
@jarm I can’t get to this immediately (in the middle of sorting out the real-time safety of the algorithms, which will, I hope, benefit Bela performance a great deal…).
If you’ve any energy left for this, can you see what happens if you go into SIMDSupport.hpp* and remove defined(__arm__) || from the test on line 84? I think this will make it fall back to scalar for Bela. No worries if not – I’ll have a go when I’ve finished making a mess
* The file will probably be in
build/_deps/hisstools-src
Yes - that elif needs to test false for A32. If that’s arm then that should be removed.
Thanks for the replies and suggestions!
I repro’d Giulio’s results, then tried editing that L84, more errors now:
root@bela:~/flucoma-sc/build# nano _deps/hisstools-
hisstools-build/ hisstools-src/ hisstools-subbuild/
root@bela:~/flucoma-sc/build# nano _deps/hisstools-src/SIMDSupport.hpp
root@bela:~/flucoma-sc/build# nano --linenumbers _deps/hisstools-src/SIMDSupport.hpp
root@bela:~/flucoma-sc/build# nano --linenumbers _deps/hisstools-src/SIMDSupport.hpp
root@bela:~/flucoma-sc/build# make install
[ 2%] Built target flucoma_VERSION_LIB
[ 5%] Built target FLUID_SC_COPYREPLYADDR
[ 6%] Built target HISSTools_FFT
[ 8%] Built target FluidBufMelBands
[ 9%] Built target FluidStats
[ 10%] Built target FluidSTFTPass
[ 11%] Built target FluidBufMFCC
[ 13%] Built target FluidBufSelect
[ 14%] Built target FluidBufSelectEvery
[ 15%] Built target FluidManipulation
[ 16%] Built target FluidBufOnsetSlice
[ 18%] Built target FluidLoudness
[ 20%] Built target FluidBufScale
[ 22%] Built target FluidBufLoudness
[ 24%] Built target FluidAmpGate
[ 25%] Built target FluidBufStats
[ 27%] Built target FluidBufThreadDemo
[ 29%] Built target FluidBufAmpFeature
[ 30%] Built target FluidBufSTFT
[ 31%] Built target FluidBufThresh
[ 33%] Built target FluidBufAmpSlice
[ 34%] Built target FluidBufNMFCross
[ 36%] Built target FluidBufHPSS
[ 37%] Built target FluidBufAmpGate
[ 39%] Built target FluidBufNoveltySlice
[ 40%] Built target FluidAmpFeature
[ 41%] Built target FluidChroma
[ 42%] Built target FluidHPSS
[ 44%] Built target FluidAmpSlice
Scanning dependencies of target FluidBufTransients
[ 45%] Building CXX object CMakeFiles/FluidBufTransients.dir/generated_sources/FluidBufTransients.cpp.o
distcc[1700] ERROR: compile /root/flucoma-sc/build/generated_sources/FluidBufTransients.cpp on 192.168.7.1 failed
distcc[1700] (dcc_build_somewhere) Warning: remote compilation of '/root/flucoma-sc/build/generated_sources/FluidBufTransients.cpp' failed, retrying locally
distcc[1700] (dcc_build_somewhere) ERROR: failed to distribute and fallbacks are disabled
In file included from /root/flucoma-sc/build/generated_sources/FluidBufTransients.cpp:11:
In file included from /root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/TransientClient.hpp:19:
In file included from /root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../../algorithms/public/TransientExtraction.hpp:13:
In file included from /root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ARModel.hpp:13:
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:383:38: error: no matching constructor for initialization of 'SIMDType<double, currentVecSize>'
SIMDType<double, currentVecSize> scaleVec(scale);
^ ~~~~~
/root/flucoma-sc/build/_deps/hisstools-src/SIMDSupport.hpp:168:8: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'double' to 'const SIMDType<double, 0>' for 1st argument
struct SIMDType {};
^
/root/flucoma-sc/build/_deps/hisstools-src/SIMDSupport.hpp:168:8: note: candidate constructor (the implicit move constructor) not viable: no known conversion from 'double' to 'SIMDType<double, 0>' for 1st argument
struct SIMDType {};
^
/root/flucoma-sc/build/_deps/hisstools-src/SIMDSupport.hpp:168:8: note: candidate constructor (the implicit default constructor) not viable: requires 0 arguments, but 1 was provided
In file included from /root/flucoma-sc/build/generated_sources/FluidBufTransients.cpp:11:
In file included from /root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/TransientClient.hpp:19:
In file included from /root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../../algorithms/public/TransientExtraction.hpp:13:
In file included from /root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ARModel.hpp:13:
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:385:40: warning: division by zero is undefined [-Wdivision-by-zero]
for (size_t i = 0; i < (dataLength / currentVecSize); i++)
^ ~~~~~~~~~~~~~~
In file included from /root/flucoma-sc/build/generated_sources/FluidBufTransients.cpp:13:
In file included from /root/flucoma-sc/include/FluidSCWrapper.hpp:14:
In file included from /root/flucoma-sc/include/wrapper/DeriveBaseClass.hpp:3:
In file included from /root/flucoma-sc/include/wrapper/NonRealtime.hpp:5:
In file included from /root/flucoma-sc/include/wrapper/Messaging.hpp:3:
/root/flucoma-sc/include/wrapper/ArgsFromClient.hpp:89:34: warning: implicit conversion changes signedness: 'unsigned int' to 'fluid::index' (aka 'int') [-Wsign-conversion]
index localBufNum = bufnum - x->mWorld->mNumSndBufs;
~~~~~~~~~~~ ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
/root/flucoma-sc/include/wrapper/ArgsFromClient.hpp:89:27: warning: implicit conversion changes signedness: 'fluid::index' (aka 'int') to 'unsigned int' [-Wsign-conversion]
index localBufNum = bufnum - x->mWorld->mNumSndBufs;
^~~~~~ ~
/root/flucoma-sc/include/wrapper/ArgsFromClient.hpp:87:15: warning: comparison of integers of different signs: 'fluid::index' (aka 'int') and 'uint32' (aka 'unsigned int') [-Wsign-compare]
if(bufnum >= x->mWorld->mNumSndBufs)
~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~
/root/flucoma-sc/include/wrapper/ArgsFromClient.hpp:251:15: warning: comparison of integers of different signs: 'fluid::index' (aka 'int') and 'uint32' (aka 'unsigned int') [-Wsign-compare]
if(bufnum >= x->mNumSndBufs)
~~~~~~ ^ ~~~~~~~~~~~~~~
In file included from /root/flucoma-sc/build/generated_sources/FluidBufTransients.cpp:13:
In file included from /root/flucoma-sc/include/FluidSCWrapper.hpp:14:
In file included from /root/flucoma-sc/include/wrapper/DeriveBaseClass.hpp:3:
/root/flucoma-sc/include/wrapper/NonRealtime.hpp:813:10: warning: unused variable 'ft' [-Wunused-variable]
auto ft = getInterfaceTable();
^
In file included from /root/flucoma-sc/build/generated_sources/FluidBufTransients.cpp:11:
In file included from /root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/TransientClient.hpp:19:
In file included from /root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../../algorithms/public/TransientExtraction.hpp:13:
In file included from /root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ARModel.hpp:13:
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:385:40: warning: division by zero is undefined [-Wdivision-by-zero]
for (size_t i = 0; i < (dataLength / currentVecSize); i++)
^ ~~~~~~~~~~~~~~
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:416:3: note: in instantiation of function template specialization 'fluid::algorithm::impl::binaryOp<fluid::algorithm::impl::ConvolveOp>' requested here
binaryOp(spectrum1, spectrum2, dataLength, scale, op);
^
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:519:3: note: in instantiation of function template specialization 'fluid::algorithm::impl::binaryOpReal<fluid::algorithm::impl::ConvolveOp>' requested here
binaryOpReal(spectrum1.mSpectra, spectrum2.mSpectra, fftSize >> 1, scale,
^
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:537:9: note: in instantiation of function template specialization 'fluid::algorithm::impl::binarySpectralOperationReal<fluid::algorithm::impl::ConvolveOp>' requested here
impl::binarySpectralOperationReal(output, in1, size1, in2, size2, mode,
^
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:73:23: error: invalid operands to binary expression ('const SIMDType<double, 0>' and 'const SIMDType<double, 0>')
outR = scale * (a * c - b * d);
~ ^ ~
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:386:7: note: in instantiation of function template specialization 'fluid::algorithm::impl::ConvolveOp::operator()<SIMDType<double, 0>>' requested here
op(real1[i], imag1[i], real1[i], imag1[i], real2[i], imag2[i], scaleVec);
^
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:416:3: note: in instantiation of function template specialization 'fluid::algorithm::impl::binaryOp<fluid::algorithm::impl::ConvolveOp>' requested here
binaryOp(spectrum1, spectrum2, dataLength, scale, op);
^
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:519:3: note: in instantiation of function template specialization 'fluid::algorithm::impl::binaryOpReal<fluid::algorithm::impl::ConvolveOp>' requested here
binaryOpReal(spectrum1.mSpectra, spectrum2.mSpectra, fftSize >> 1, scale,
^
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:537:9: note: in instantiation of function template specialization 'fluid::algorithm::impl::binarySpectralOperationReal<fluid::algorithm::impl::ConvolveOp>' requested here
impl::binarySpectralOperationReal(output, in1, size1, in2, size2, mode,
^
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:74:23: error: invalid operands to binary expression ('const SIMDType<double, 0>' and 'const SIMDType<double, 0>')
outI = scale * (a * d + b * c);
~ ^ ~
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:385:40: warning: division by zero is undefined [-Wdivision-by-zero]
for (size_t i = 0; i < (dataLength / currentVecSize); i++)
^ ~~~~~~~~~~~~~~
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:416:3: note: in instantiation of function template specialization 'fluid::algorithm::impl::binaryOp<fluid::algorithm::impl::CorrelateOp>' requested here
binaryOp(spectrum1, spectrum2, dataLength, scale, op);
^
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:519:3: note: in instantiation of function template specialization 'fluid::algorithm::impl::binaryOpReal<fluid::algorithm::impl::CorrelateOp>' requested here
binaryOpReal(spectrum1.mSpectra, spectrum2.mSpectra, fftSize >> 1, scale,
^
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:546:9: note: in instantiation of function template specialization 'fluid::algorithm::impl::binarySpectralOperationReal<fluid::algorithm::impl::CorrelateOp>' requested here
impl::binarySpectralOperationReal(output, in1, size1, in2, size2, mode,
^
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:84:23: error: invalid operands to binary expression ('const SIMDType<double, 0>' and 'const SIMDType<double, 0>')
outR = scale * (a * c + b * d);
~ ^ ~
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:386:7: note: in instantiation of function template specialization 'fluid::algorithm::impl::CorrelateOp::operator()<SIMDType<double, 0>>' requested here
op(real1[i], imag1[i], real1[i], imag1[i], real2[i], imag2[i], scaleVec);
^
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:416:3: note: in instantiation of function template specialization 'fluid::algorithm::impl::binaryOp<fluid::algorithm::impl::CorrelateOp>' requested here
binaryOp(spectrum1, spectrum2, dataLength, scale, op);
^
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:519:3: note: in instantiation of function template specialization 'fluid::algorithm::impl::binaryOpReal<fluid::algorithm::impl::CorrelateOp>' requested here
binaryOpReal(spectrum1.mSpectra, spectrum2.mSpectra, fftSize >> 1, scale,
^
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:546:9: note: in instantiation of function template specialization 'fluid::algorithm::impl::binarySpectralOperationReal<fluid::algorithm::impl::CorrelateOp>' requested here
impl::binarySpectralOperationReal(output, in1, size1, in2, size2, mode,
^
/root/flucoma-sc/build/_deps/flucoma-core-src/include/clients/rt/../common/../../algorithms/public/../util/ConvolutionTools.hpp:85:23: error: invalid operands to binary expression ('const SIMDType<double, 0>' and 'const SIMDType<double, 0>')
outI = scale * (b * c - a * d);
~ ^ ~
8 warnings and 5 errors generated.
make[2]: *** [CMakeFiles/FluidBufTransients.dir/build.make:82: CMakeFiles/FluidBufTransients.dir/generated_sources/FluidBufTransients.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1097: CMakeFiles/FluidBufTransients.dir/all] Error 2
make: *** [Makefile:149: all] Error 2
All seems to be fixable…!
We can circle back sometime after your current refactoring efforts
It looks like the max vector size is getting set to 0 which is not correct. Let look at the source of SIMDSupport.hpp as used by flucoma a minute.
My mistake - in ConvolutionTools.hpp I ask for a vector that is half the max size (which will be 0 if the vecSize is 1).
@weefuzzy - this might require the removal of this file, which is outdated, and should now be replaced with SpectralProcessor.hpp etc. from HISSTools_Library. I think I did a PR for that already, but let me know if I didn’t. I’ve checked that code and it seems to have tests to avoid this kind of problem, so there’s little point in fixing up old and unmaintained files vs maintained files in my view.
OK I didn’t do a PR but the changes are a commit on my fork.
@jarm - if you feel adventurous you could keep the changes you’ve already made and than patch this commit (only) on also and that might work…
1 Like