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.
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
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…)