Surge XT 2.1 testing and feedback thread

Surge XT 2.0 is headed to the library and the nightly is starting to get 2.1 features. Opening this thread for folks who aren’t on our discord for conversation without spamming up the original announcement thread


Download here: Release Nightly releases updated on each push · surge-synthesizer/surge-rack · GitHub

You can see the XT 2.1 milestone here: XT 2.1 Milestone · GitHub but of course we can add or remove anything from that at any time. but we do tend to track fairly close to milestones in the way we run surge-y things.

We are keeping the changelog fairly up to date as we go. you can see it here surge-rack/ at main · surge-synthesizer/surge-rack · GitHub

Finally new modules will get merged in incomplete states. If a module is incomplete it will have a big red ALPHA on the panel (as of the next nightly).


I’m getting a segmentation fault with SurgeXTRack-2.1.beta.0-nightly-a97451f-lin.vcvplugin and Rack 2.2, running on Arch Linux.

I’ve not had this problem before, but I upgraded to Rack 2.2 yesterday and had the problem loading Surge modules, so today I tried to install the latest nightly.

Stack trace as follows; let me know if you want me to try something out, dig out some other logs, or whatnot!

Stack trace of thread 168231:
#0  0x00007f5aa59a39f8 _IO_fclose ( + 0x729f8)
#1  0x00007f5a7e3e5358 n/a (/home/XXX/.Rack2/plugins/SurgeXTRack/ + 0x1e5358)
#2  0x00007f5aa5f1b2a9 n/a (/home/XXX/.local/share/VCV/Rack2Pro/ + 0x31b2a9)
#3  0x00007f5aa5f1c12e n/a (/home/XXX/.local/share/VCV/Rack2Pro/ + 0x31c12e)
#4  0x00000000004032fc n/a (/home/XXX/.local/share/VCV/Rack2Pro/Rack + 0x32fc)
#5  0x00007f5aa5954290 n/a ( + 0x23290)
#6  0x00007f5aa595434a __libc_start_main ( + 0x2334a)
#7  0x0000000000403da9 n/a (/home/XXX/.local/share/VCV/Rack2Pro/Rack + 0x3da9)
ELF object binary architecture: AMD x86-64

Did you self build or download the binary? I wonder if there is a dll conflict. Presume nothing in log.txt right?

I’m traveling for txgiving so am macos only right now but first thing I would try is a local build or compare the output of ldd on the surge plugin and rack 2.2?

I downloaded the latest nightly.

Actually, there’s something in log.txt, as follows:

[0.495 info src/SurgeXT.cpp:26 init] [SurgeXTRack] initializing
[0.496 fatal adapters/standalone.cpp:49 fatalSignalHandler] Fatal signal 11. Stack trace:
9: /home/XXX/.local/share/VCV/Rack2Pro/Rack() [0x403e7d]
8: /usr/lib/
7: /usr/lib/
6: /home/XXX/.Rack2/plugins/SurgeXTRack/
5: ./
4: ./
3: /home/XXX/.local/share/VCV/Rack2Pro/Rack(main+0x52c)
2: /usr/lib/
1: /usr/lib/
0: /home/XXX/.local/share/VCV/Rack2Pro/Rack() [0x403da9]

I will try a local build! I’m not sure if I’ll be able to squeeze it in tonight, but I’ll try, and let you know what I find!


I might also have a bug. One of the 2.1 changes is a file handling change! Lemme peek

Oh yeah. So do you have a file called ‘default-skin.json’ in ~/Documents/Rack2/SurgeXTRack?

I think if that file is missing my new code will attempt to close a nullptr.

Stay tuned.

Yeah I definitely have a condition where i std::fclose a nullptr if that file is missing and while that’s fine on win and lin i bet your libc doesn’t like it (justifiably)

I’ve just pushed a PR which should fix that. Will merge it in a bit and so grab the next nightly in 30-45 minutes and see if that works?

I also added an “Alpha” label I can add to modules which are under development so people get less confused about incremental-fixes-to-existing-modules vs new-things-whcih-arent-done in this nightly

Awesome, will do!


OK just merged 02f1105 which - if that crash is what I think it is - should resolve it. It takes about 20 minutes from merge to updated nightly so give it a whirl once you see something at or after that hash

and thanks for the report!

1 Like

@superjudge because of some issues with the rack 2.2 sdk and simd we are going to resubmit a different hash to the library. Have you had a chance to confirm whether this fix works on arch? That would be super helpful to know before tomorrow midday if possible


Actually I was able to repro it by undoing that commit and running on ubuntu so yes it is fixed. Great thanks for flagging

The docs don’t say what would happen if you passed a null pointer, but they do say: “The behavior is undefined if the value of the pointer stream is used after fclose returns.”

Would running address sanitizer have found this? I would think so.

in this case it wasn’t a use after close it was just a close of a null

a sanitizer wouldn’t have found it for me because i have the file so the open succeeds.

but a blow away of rack dir and a run on unix would have found it indeed. which is how OP found it and how I reproduced it.

A sanitizer would have found the honking big memory leak I just fixed though, which was because i was interacting improperly with our pre-allocated pool in the string oscillator. Luckily a user found that today and also luckily we ran into a problem in the rack 2.2 sdk which surge tickles so i have to resubmit.


Yes, that’s why my short past said that.

I think I found a bug, where the mouse pointer would disappear and not return if I mess with the modulation intensity (while modulation mode is active) yet toggling with shift+alt, while hitting other modifier keys like command (in search for the right key command) it can happen that the mouse pointer disappears and won’t return until you hit cmd&q to exit vcc, this is on an m1 mac, razer mouse, steermouse utility, external screen.

Sorry, I got side-tracked by work, but I just downloaded the latest nightly, and now things seem to be working also on Arch Linux.

Thanks! And thanks in general for the great work on Surge XT!

1 Like

Thanks I’ll log this as an issue and investigate in the 2.1 cycle.

Out of curiosity do you have mouse hiding on or off in rack?

you mean cursor drag-lock? yes, it was on, and I was not able to reproduce it after I turned it off. I’m in rack 2.2 btw

1 Like