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
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.
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!
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?
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
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
@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
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.
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.
With the advent of PatchMaster, one feature request is to enable the modulation buttons to be mapped. I could envision a workflow where when the modulation button is pressed, the next control to be moved is mapped, and the amount that the control is moved is added to the modulation amount.
oooh interesting. The modulation buttons aren’t parameters since they just change UI state and I don’t know what the requirement is to have something be mapped if it isn’t a parameter. @marc_boule - any thoughts? or do I have to just add 4 fake parameters (which I can do of course but if there’s a better way…)