mdedwards
Floating point error in test-clm-play
Hello,
as already discussed on Monday, I am unable to run test-clm-play in SBCL 2.4.9 (MacOS 14.7). I assume this to be related to the *clm-data-format* (mus-lfloat) and the :header-type (clm::mus-aiff) as the test function breaks with the following error message:
arithmetic error FLOATING-POINT-INVALID-OPERATION signalled
[Condition of type FLOATING-POINT-INVALID-OPERATION]
Restarts:
0: [RETRY] Retry SLY mREPL evaluation request.
1: [*ABORT] Return to SLY's top level.
2: [ABORT] abort thread (#<THREAD tid=6147 "sly-channel-1-mrepl-remote-1" RUNNING {7004F900D3}>)
Backtrace:
0: ((FLET SB-UNIX::RUN-HANDLER :IN SB-UNIX::%INSTALL-HANDLER) 8 #.(SB-SYS:INT-SAP #X104F0F810) #.(SB-SYS:INT-SAP #X104F0F878))
1: ("bogus stack frame")
2: (CLM::CLM-SCALE-FILE "/tmp/mini-1-vn-vc-audio-1-seq1-3.aif" "/tmp/mini-1-vn-vc-audio-1-seq1-3.aif.temp" 2.229363602366421d0 12 49)
3: (CLM::SCALE-TO-FILE "/tmp/mini-1-vn-vc-audio-1-seq1-3.aif" 0.99 12 T 49)
4: (CLM::END-WITH-SOUND 0.99 "/tmp/mini-1-vn-vc-audio-1-seq1-3.aif.temp" "/tmp/mini-1-vn-vc-audio-1-seq1-3.reverb" T 49 12 CLM::NREV 3 NIL 2 NIL NIL)
5: ((:METHOD CLM-PLAY (SLIPPERY-CHICKEN T T T)) ..) [fast-method]
6: (TEST-CLM-PLAY)
7: (SB-INT:SIMPLE-EVAL-IN-LEXENV (TEST-CLM-PLAY) #<NULL-LEXENV>)
8: (EVAL (TEST-CLM-PLAY))
9: ((LAMBDA NIL :IN SLYNK-MREPL::MREPL-EVAL-1))
--more--
I've now tested all calls to clm-play in test-clm-play separately, but none of them succeeds.
Best Ruben
Hello Ruben, I think the idea was to try with WAV output instead of AIFF. See if they pass with that simple change. Best, Michael.On 23. Oct 2024, at 20:45, Ruben Philipp @.***> wrote: Hello, as already discussed on Monday, I am unable to run test-clm-play in SBCL 2.4.9 (MacOS 14.7). I assume this to be related to the clm-data-format (mus-lfloat) and the :header-type (clm::mus-aiff) as the test function breaks with the following error message: arithmetic error FLOATING-POINT-INVALID-OPERATION signalled [Condition of type FLOATING-POINT-INVALID-OPERATION]
Restarts: 0: [RETRY] Retry SLY mREPL evaluation request. 1: [*ABORT] Return to SLY's top level. 2: [ABORT] abort thread (#<THREAD tid=6147 "sly-channel-1-mrepl-remote-1" RUNNING {7004F900D3}>)
Backtrace: 0: ((FLET SB-UNIX::RUN-HANDLER :IN SB-UNIX::%INSTALL-HANDLER) 8 #.(SB-SYS:INT-SAP #X104F0F810) #.(SB-SYS:INT-SAP #X104F0F878)) 1: ("bogus stack frame") 2: (CLM::CLM-SCALE-FILE "/tmp/mini-1-vn-vc-audio-1-seq1-3.aif" "/tmp/mini-1-vn-vc-audio-1-seq1-3.aif.temp" 2.229363602366421d0 12 49) 3: (CLM::SCALE-TO-FILE "/tmp/mini-1-vn-vc-audio-1-seq1-3.aif" 0.99 12 T 49) 4: (CLM::END-WITH-SOUND 0.99 "/tmp/mini-1-vn-vc-audio-1-seq1-3.aif.temp" "/tmp/mini-1-vn-vc-audio-1-seq1-3.reverb" T 49 12 CLM::NREV 3 NIL 2 NIL NIL) 5: ((:METHOD CLM-PLAY (SLIPPERY-CHICKEN T T T)) ..) [fast-method] 6: (TEST-CLM-PLAY) 7: (SB-INT:SIMPLE-EVAL-IN-LEXENV (TEST-CLM-PLAY) #<NULL-LEXENV>) 8: (EVAL (TEST-CLM-PLAY)) 9: ((LAMBDA NIL :IN SLYNK-MREPL::MREPL-EVAL-1)) --more--
I've now tested all calls to clm-play in test-clm-play separately, but none of them succeeds. Best Ruben
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
That's true. I've just tested all calls to clm-play with clm::mus-riff. Indeed I don't get this annoying error then.
Good to know. We could just change that permanently in the tests and be done with it but it might just be worth seeing if writing a 24 bit AIFF also passes. I don’t know why this would fail on your system and not with mine, but I know I’ve had problems in the past with 32 bit floating point AIFF files. On 23. Oct 2024, at 21:08, Ruben Philipp @.***> wrote: That's true. I've just tested all calls to clm-play with clm::mus-riff. Indeed I don't get this annoying error then.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
We could just change that permanently in the tests and be done with it […]
I would make a case for that.
[…] it might just be worth seeing if writing a 24 bit AIFF also passes.
I will check this tomorrow.
I don’t know why this would fail on your system and not with mine […]
This is also quite opaque to me, especially since we use the same version of SBCL (don't we?). Maybe it is related to our C-compiler, but this is not much less of a mystery then…
Best Ruben
Tests with AIFF files also fail when clm:*clm-data-format* is:
- mus-ldouble
- mus-bdouble
- mus-l24int
- mus-b24int
- mus-lint
- mus-bint
I hope, this answers the second desideratum.
Best Ruben
Good to know but :/
I’ve changed test-clm-play to write and test for .wav instead of .aiff
Tests pass for me
Out of interest, test-clm-play-1-section-and-nils causes no problems even though it also explicitly writes aiff?
Best, Michael
Thanks a lot, Michael!
No, test-clm-play-1-section-and-nils also breaks the tests. I've changed it -- analogous to test-clm-play -- to aiff, but get a division by zero-error instead of the floating point-error. :/
arithmetic error DIVISION-BY-ZERO signalled
[Condition of type DIVISION-BY-ZERO]
Restarts:
0: [NIL] try to exit current note cleanly and go on.
1: [NIL] abort current note.
2: [NIL] close files and return to top-level.
3: [NIL] jump past remaining notes.
4: [RETRY] Retry EVAL of current toplevel form.
5: [CONTINUE] Ignore error and continue loading file "/Users/rubenphilipp/lisp/slippery-chicken/tests/sc-test-suite.lsp".
--more--
Backtrace:
0: ((FLET SB-UNIX::RUN-HANDLER :IN SB-UNIX::%INSTALL-HANDLER) 8 #.(SB-SYS:INT-SAP #X109BFF970) #.(SB-SYS:INT-SAP #X109BFF9D8))
1: ("bogus stack frame")
2: (CLM::|clm_sine56| #.(SB-SYS:INT-SAP #X702E5BD590) 20 #.(SB-SYS:INT-SAP #X702E5BD500) 31)
3: (CLM::SINE "no path" 0.0 :DURATION 0.5 :FREQUENCY 261.62554931640625d0 :START 0.0 :SRT 0.9999982503128149d0 :WIDTH 5 :AMP 1.0 :PRINTING NIL :AMP-ENV (0 0 5 1 60 1 ...) :AMP-ENV-BASE 2 :AMP-ENV-SCALER ..
4: ((:METHOD CLM-PLAY (SLIPPERY-CHICKEN T T T)) ..) [fast-method]
5: (TEST-CLM-PLAY-PSYNCH)
6: ((LAMBDA NIL :IN "/Users/rubenphilipp/lisp/slippery-chicken/tests/sc-test-suite.lsp"))
7: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SC-TEST-TEST-ALL) #<NULL-LEXENV>)
8: (SB-INT:SIMPLE-EVAL-IN-LEXENV (IF (SC-TEST-TEST-ALL) (PROGN (SETF *SC-TEST-METH-AND-FUNC-TESTS-STATE* "- ALL METHOD AND FUNCTION TESTS PASSED.") (FORMAT T "~%~%~a~%~%" *SC-TEST-METH-AND-FUNC-TESTS-STA..
9: (SB-EXT:EVAL-TLF (IF (SC-TEST-TEST-ALL) (PROGN (SETF *SC-TEST-METH-AND-FUNC-TESTS-STATE* "- ALL METHOD AND FUNCTION TESTS PASSED.") (FORMAT T "~%~%~a~%~%" *SC-TEST-METH-AND-FUNC-TESTS-STATE*)) (PROGN ..
10: ((LABELS SB-FASL::EVAL-FORM :IN SB-INT:LOAD-AS-SOURCE) (IF (SC-TEST-TEST-ALL) (PROGN (SETF *SC-TEST-METH-AND-FUNC-TESTS-STATE* "- ALL METHOD AND FUNCTION TESTS PASSED.") (FORMAT T "~%~%~a~%~%" *SC-TES..
11: ((LAMBDA (SB-KERNEL:FORM &KEY :CURRENT-INDEX &ALLOW-OTHER-KEYS) :IN SB-INT:LOAD-AS-SOURCE) (IF (SC-TEST-TEST-ALL) (PROGN (SETF *SC-TEST-METH-AND-FUNC-TESTS-STATE* "- ALL METHOD AND FUNCTION TESTS PASS..
12: (SB-C::%DO-FORMS-FROM-INFO #<FUNCTION (LAMBDA (SB-KERNEL:FORM &KEY :CURRENT-INDEX &ALLOW-OTHER-KEYS) :IN SB-INT:LOAD-AS-SOURCE) {10980196B}> #<SB-C::SOURCE-INFO {7003810763}> SB-C::INPUT-ERROR-IN-LOAD..
13: (SB-INT:LOAD-AS-SOURCE #<SB-INT:FORM-TRACKING-STREAM for "file /Users/rubenphilipp/lisp/slippery-chicken/tests/sc-test-suite.lsp" {7003810533}> :VERBOSE NIL :PRINT NIL :CONTEXT "loading")
14: ((LABELS SB-FASL::LOAD-STREAM-1 :IN LOAD) #<SB-INT:FORM-TRACKING-STREAM for "file /Users/rubenphilipp/lisp/slippery-chicken/tests/sc-test-suite.lsp" {7003810533}> NIL)
15: (SB-FASL::CALL-WITH-LOAD-BINDINGS #<FUNCTION (LABELS SB-FASL::LOAD-STREAM-1 :IN LOAD) {10980154B}> #<SB-INT:FORM-TRACKING-STREAM for "file /Users/rubenphilipp/lisp/slippery-chicken/tests/sc-test-suite..
16: (LOAD "/Users/rubenphilipp/lisp/slippery-chicken/tests/sc-test-suite.lsp" :VERBOSE NIL :PRINT NIL :IF-DOES-NOT-EXIST :ERROR :EXTERNAL-FORMAT :DEFAULT)
17: (SB-INT:SIMPLE-EVAL-IN-LEXENV (RUN-TESTS) #<NULL-LEXENV>)
18: (EVAL (RUN-TESTS))
19: ((LAMBDA NIL :IN SLYNK-MREPL::MREPL-EVAL-1))
--more--
I don't have time to investigate this further right now but might have a look at it later…
Best Ruben
I've changed it -- analogous to test-clm-play -- to aiff,
Do you mean riff/wav?
I don’t see anything new when I pull so I’ll await your deliberations.
Best, M
Do you mean riff/wav?
Sure.
test-clm-play-1-section-and-nils works now after changing to riff/wav. I will push a commit in a few seconds.
The arithmetic-error is caused by test-clm-play-psynch, namely by the two clm-play calls involving clm::sine. :/ Any ideas about this?
Best Ruben
Thanks. As I can’t create this error myself I’m not sure. Might have to look at it on your machine. One place to start might be the size of the float type being used...
On 24 Oct 2024, at 20:09, Ruben Philipp @.***> wrote:
Do you mean riff/wav?
Sure.
test-clm-play-1-section-and-nils works now after changing to riff/wav. I will push a commit in a few seconds. The arithmetic-error is caused by test-clm-play-psynch, namely by the two clm-play calls involving clm::sine. :/ Any ideas about this?
Best Ruben
— Reply to this email directly, view it on GitHub https://github.com/mdedwards/slippery-chicken/issues/104#issuecomment-2436039840, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3IOIQRPM35AJ4YJH2WUZTZ5EZVLAVCNFSM6AAAAABQPOQJHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZWGAZTSOBUGA. You are receiving this because you commented.
Sure. I just quickly tried to use clm::mus-lfloat and clm::mus-ldouble in the :data-format slot, unfortunately without success. Maybe we should indeed have a look at it on my machine next week!?
Best Ruben
👍On 26. Oct 2024, at 12:00, Ruben Philipp @.***> wrote: Sure. I just quickly tried to use clm::mus-lfloat and clm::mus-ldouble in the :data-format slot, unfortunately without success. Maybe we should indeed have a look at it on my machine next week!? Best Ruben
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
Just a quick update:
I've just built SBCL on my system (via brew install --build-from-source sbcl), unfortunately without any success with regards to our issue. I'll keep it up…
Best Ruben
😟On 28. Oct 2024, at 21:24, Ruben Philipp @.***> wrote: Just a quick update: I've just built SBCL on my system (via brew install --build-from-source sbcl), unfortunately without any success with regards to our issue. I'll keep it up… Best Ruben
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
I'm just comparing our two CLM log-files and found an (probably) astonishing difference. While my Mac states that the CLM sources are compiled on an arm64 architecture, your file says uname -m = x86_64. Here's an excerpt from the diff of our two files (yours is the second, green file). I've altered the hostnames here for privacy reasons.
-hostname = ruben.local
-uname -m = arm64
+hostname = michael.local
+uname -m = x86_64
uname -r = 23.6.0
uname -s = Darwin
-uname -v = Darwin Kernel Version 23.6.0: Wed Jul 31 20:48:52 PDT 2024; root:xnu-10063.141.1.700.5~1/RELEASE_ARM64_T6020
+uname -v = Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:46 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6031
-/usr/bin/uname -p = arm
+/usr/bin/uname -p = i386
Are you running your compiler in rosetta? This might explain at least why your system behaves different from mine.
Best Ruben
That’s bizarre. Well spotted though. When I run that I get this:
/usr/bin/uname -p arm
But perhaps CLM is explicitly running in rosetta. I’ve definitely not instigated that.
Even more bizarre is this:
- Darwin Kernel Version 23.6.0: Wed Jul 31 20:48:52 PDT 2024; root:xnu-10063.141.1.700.5~1/RELEASE_ARM64_T6020
-Kernel configured for up to 12 processors.
-12 processors are physically available.
-12 processors are logically available.
-Processor type: arm64e (ARM64E)
-Processors active: 0 1 2 3 4 5 6 7 8 9 10 11
-Primary memory available: 16.00 gigabytes
-Default processor set: 651 tasks, 2753 threads, 12 processors
-Load average: 1.81, Mach factor: 10.18
+ Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:46 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6031
+Kernel configured for up to 14 processors.
+14 processors are physically available.
+14 processors are logically available.
+Processor type: i486 (Intel 80486)
+Processors active: 0 1 2 3 4 5 6 7 8 9 10 11 12 13
+Primary memory available: 36.00 gigabytes
+Default processor set: 816 tasks, 3627 threads, 14 processors
+Load average: 7.95, Mach factor: 6.06
This is me??? :::: +Processor type: i486 (Intel 80486)
Yes. Very strange…
So: more weirdness. If I run a virgin clm all.lisp the configure script somehow does indeed identify my system as being X86 (intel), for some unknown reason. However, if I run the script by hand, in the shell, then it identifies arm instead. Very strange. Then I load all.lisp, it uses the existing mus-config.h, compiles clm, and all the sc tests pass yet again. In the shell and in emacs.
Do we know if @Leon-Focker hits any problems? Or someone else?
:( :( ::::
@-> brew config HOMEBREW_VERSION: 4.4.1 ORIGIN: https://github.com/Homebrew/brew HEAD: 70672606c6ac07a5e8f75abeda7b8736e8285dbe Last commit: 3 weeks ago Core tap HEAD: d59c56b8d034a750eeed89538995ee6308900154 Core tap last commit: 2 weeks ago Core tap JSON: 19 Oct 09:08 UTC Core cask tap HEAD: a55831e0023a8f03197d91c255f4ad323415fb66 Core cask tap last commit: 2 weeks ago Core cask tap JSON: 19 Oct 09:08 UTC HOMEBREW_PREFIX: /usr/local HOMEBREW_REPOSITORY: /usr/local/Homebrew HOMEBREW_CELLAR: /usr/local/Cellar HOMEBREW_CASK_OPTS: [] HOMEBREW_DISPLAY: /private/tmp/com.apple.launchd.O7XS0ULXrx/org.macosforge.xquartz:0 HOMEBREW_EDITOR: emacs HOMEBREW_MAKE_JOBS: 10 HOMEBREW_NO_AUTO_UPDATE: set Homebrew Ruby: 3.3.5 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/3.3.5/bin/ruby CPU: 10-core 64-bit westmere Clang: 15.0.0 build 1500 Git: 2.47.0 => /usr/local/bin/git Curl: 8.7.1 => /usr/bin/curl macOS: 14.6.1-x86_64 CLT: 15.3.0.0.1.1708646388 Xcode: N/A Rosetta 2: true
Hey all,
Do we know if @Leon-Focker hits any problems? Or someone else?
I have just tried to get up to speed on this but am not entirely sure what to test. Just test-clm-play as it currently is? I can do that as soon as I'm back at my VM.
Best, Leon
OK so my brew (itself!) was running under rosetta, so installing sbcl rosetta, it would seem.../usr/local/bin (my path of ages) seems no longer to be relevant. Who knew?
Am now running sbcl-2.4.10-macosx-arm64 for sure and I finally get the division by zero error.
Result!
All that work just to have a failing system.
Have now mailed Bill to see if he can locate the locsig error in clm
Wow. That's both relieving and annoying. Thanks for your effort and for writing to Bill.
Best Ruben
we narrowed it down to the :distance argument of clm's locsig ugen. The ultimate solution is not yet apparent but in order to dodge the problem I've made the default distance of the sine instrument to be 0.01 instead of 0. Should make no difference to resulting sound files but it's definitely head-in-the-sand stuff for now.
git pull and see if it works for you @rubenphilipp Ruben
Great!
git pull and see if it works for you @rubenphilipp https://github.com/rubenphilipp Ruben
Yes, I can successfully run the tests without any error, finally. Thanks!
Best Ruben
On 6. Nov 2024, at 15:58, Michael Edwards @.***> wrote:
we narrowed it down to the :distance argument of clm's locsig ugen. The ultimate solution is not yet apparent but in order to dodge the problem I've made the default distance of the sine instrument to be 0.01 instead of 0. Should make no difference to resulting sound files but it's definitely head-in-the-sand stuff for now.
git pull and see if it works for you @rubenphilipp https://github.com/rubenphilipp Ruben
— Reply to this email directly, view it on GitHub https://github.com/mdedwards/slippery-chicken/issues/104#issuecomment-2459976055, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC7525TAMBSDCGWUYHGNUY3Z7IVATAVCNFSM6AAAAABQPOQJHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJZHE3TMMBVGU. You are receiving this because you were mentioned.