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…)
While I’m not saying it couldn’t be done otherwise, I really think the normal mapping mechanism is the way to go, given that mapping is inherently parameter based in Rack. But, if there’s one thing I’ve learned making modules over the years, is that the Rack API is extremely flexible, and with the proper will and skills, perhaps it could be done without using Rack parameters. With what I know of things though, I would definitely recommend using parameters.
Oh you know we don’t need it anyway since the modulation depths are parameters today and PatchMater can map them already. I should have just tried before tagging you sorry @marc_boule (Making the activation toggles parameters is really a mistake I think! It’s like making the skin or color choices a parameter).
@trevormeier - basically you can map the modulation depth separately than the actual value without problem. Bring up a rack module, map a control with watchmaster, then arm modulation, then map a second control to that modulation depth. You then get independent control of the underlies and the modulation depth
Basically when you arm mod, all the knobs get replaced with “other” knobs and patch master finds them all fine.
Here’s an example patch where the first knob modifies the modulation depth of drive and the second modifies the drive and bias together.
That’s a great trick! Having the mod amount be a parameter is a big step of the way there, but it still requires mouse interaction and pre-mapping all of the mod knobs, which kind of kills their flexibility.
I’m envisioning a setup using only hardware control to build a patch. To simplify the example, let’s say the mod CV inputs are pre-wired. What I imagine is to map the mod buttons and module controls to hardware buttons and knobs. Pressing a mod button and turning any pre-mapped knob would set modulation amount. In this way, hardware could be used to set up the modulation routing in the modules as you build the patch.
As it is, everything has to be pre-mapped: two Patchmaster controls for every Surge control, with the mod inputs locked to their pre-mapped controls. This kills the flexibility of the mod knobs. If the mod knobs could be mapped, then they could be hardware controlled as a patch is built.
Right but what you are asking for isn’t to activate the button with patch master. It is to have patch master control the param in one case and the depth in another. The button flips the knob which is on screen but they are separate params. We display it visually as if the knob is in overlay mode but it isn’t - there’s just 5 knobs for every modulatable knob and they are separate.
So here’s another way to think about it, what you want is a mode where a patch master knob can map to either param a or param b, and that selection is done by another patch master knob. Toggling the ui state wouldn’t change a mapping in patch master anyway and the depth is a different id.
If instead of a knob with overlays we had made surge have each knob be a single knob and 4 tiny attenuverter knobs around it, how would you want patch master to work? Since that’s what surge is (just rendered fancy) that’s what I think you are looking to solve,
It sounds like what you want is patch master to have a knob and button. When the button isn’t pressed the knob edits filter. When the button is pressed the knob edits filter 1 mod depth. So the patch master button acts “as if” you pressed the surge arm mod 1 button
Is that right?
If it is the mechanics of that are just that patch master has a button that can change a patch master param assignment (the ux could be harder)
But if it’s not well I need to kinda understand what the thing you want to happen is
