Seaside Modular Announcements Thread: v2.5.2

I do here, latest commit build on Win 10

Thread 32 received signal SIGFPE, Arithmetic exception.
[Switching to Thread 9468.0x1a1c]
0x00007ff833cc0545 in daisysp::Comb::Process (this=this@entry=0x12db77a0, in=<optimized out>, in@entry=0) at inc/DaisySP/Source/Filters/comb.cpp:43
43          outsamp                = buf_[(buf_pos_ + mod_) % max_size_];
(gdb) bt
#0  0x00007ff833cc0545 in daisysp::Comb::Process (this=this@entry=0x12db77a0, in=<optimized out>, in@entry=0) at inc/DaisySP/Source/Filters/comb.cpp:43
#1  0x00007ff833ce6d48 in Jawari::process (this=0x12d8ffd0, args=...) at src/Jawari.cpp:245
#2  0x00007ff8490e464c in rack::engine::Module::doProcess (this=0x12d8ffd0, args=...) at src/engine/Module.cpp:345
#3  0x00007ff8490df9d1 in rack::engine::Engine_stepWorker (that=<optimized out>, threadId=<optimized out>) at src/engine/Engine.cpp:331
#4  rack::engine::EngineWorker::run (this=0x8314ec0) at src/engine/Engine.cpp:1318
#5  0x00007ff86adacb5f in ?? () from C:\Program Files\VCV\Rack2 Pro\libstdc++-6.dll
#6  0x00007ff87c1a4b4b in ?? () from C:\Program Files\VCV\Rack2 Pro\libwinpthread-1.dll
#7  0x00007ff89100af5a in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll
#8  0x00007ff89100b02c in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll
#9  0x00007ff891bd7614 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
#10 0x00007ff8925826a1 in ntdll!RtlUserThreadStart () from C:\WINDOWS\SYSTEM32\ntdll.dll
#11 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Something uninitialized?

1 Like

Nothing super obvious (to me). I’m not crazy about the way the Daisy DSP library leaves everything uninitialized until you call Init. Makes it very difficult to tell if everything is initialized, but as I say I don’t see anything obvious.

1 Like

Ah I see it now, working backward from lines 132 and 119:

I see that Init is using a sample rate based on

which is 48kHz, I get a crash at 44.1kHz, setting the engine to 48kHz the module doesn’t crash. This is also reflected in the Init buffer size as well in line 132.

TL;DR the engine must be set @ 48kHz.

4 Likes

good catch!

3 Likes

Great catch thank you!

3 Likes

Interesting. I had changed the sample rate from 44.1 to 48kHz earlier but got a crash with both. I will try again and report back.

I got a small test patch that only loads @ 48kHz. Once loaded I can change the engine to 44.1kHz and then back again. If I exit Rack with it set @ 44.1 kHz, then restart Rack the autoloaded patch will crash. If I restart Rack clean, switch to 48kHz the patch, as I said, loads with no problem.

1 Like

I changed to 48kHz and it still crashed two times but on the third time it worked okay. Changing it back to 44.1kHz caused a crash. Changing it back to 48kHz got rid of the crash again. So, it looks like this is indeed the issue.

Thanks for finding the cause.

1 Like

No problem; the little nudge from Bruce helped!

2 Likes

All of my old Jawari patches are working fine now with the new build on Win11. I’m wiring up the RESET since I was one who requested this. Thanks for adding it.

1 Like

Fixed the math that was causing sample rate to cause crashes (bad casting). Also fixed an issue with live sample rate switching.

3 Likes

Confirming all good here.

1 Like

And, as I always say (I do), this would be a good test case for a unit test suit!

3 Likes

Oh Bruce, when will they listen, when!!!??? :laughing:

3 Likes

For unrelated reasons, I started making my own modules have a separate “engine” class that just calculates DSP but has no dependencies on VCV Rack. A wonderful side effect is that I can make a command-line version of the engine for automated unit tests. I highly recommend this approach.

And yes, a wonderful practice when a bug is reported is:

  • Make sure you can reproduce the bug.
  • Create a test that reproduces the bug.
  • Add that test to your automated suite of tests that is run every time you make a change.
  • Fix the bug.
  • Make sure your test now passes.

Never waste a good bug… make sure it breaks your test before you fix it.

6 Likes

yeah, pretty much what I do. This note has been in the repo for a long time: SquinkyVCV-main/composites.md at master · kockie69/SquinkyVCV-main · GitHub

1 Like

I tell ppl this at work all the time - true wisdom.

Everything good for me now. Thanks.

1 Like

I’m getting a

[7.493 warn src/plugin.cpp:203 loadPlugin] Could not load plugin /home/jackokring/Rack/plugins/SeasideModular: JSON parsing error at /home/jackokring/Rack/plugins/SeasideModular/plugin.json 27:1 string or '}' expected near '<'

False alarm, fix by re pull, seems some local edit of the json and some …

On branch master
Your branch and 'origin/master' have diverged,
and have 19 and 21 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   .gitignore
        both modified:   plugin.json

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    dist/SeasideModular/plugin.dylib
        modified:   dist/SeasideModular/plugin.json
        modified:   dist/SeasideModular/res/Jawari.svg

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        plugin-arm64.so

no changes added to commit (use "git add" and/or "git commit -a")
1 Like

Interesting. I am not getting that warning, but I usually do not look for warnings in the log file. I do see one warning in my log file, but that has to do with “plugin win” being missing. I do not know what that means.