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.
PatchMasterForSurgeModulation.vcv (1.8 KB)
“WatchMaster” – our new clock module 
2 Likes
i thought that was just clocked with a rotary dial face?
Yes - and you have to virtually wind it up first before it will run
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.
say what? A wind-up clock? o_O
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,
I’m thinking of it from how I’d like it to work, not what Surge is—so I see your point. I can’t see an obvious solution, but I’ll give it a think.
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 
Yes, you got it - that would be very fun to work with.
Right so that’s actually just a patch master fr then! Interesting t
Not sure it’s possible to change the mapping target of a knob by pressing a button (Marc would know better than me though)
But even if it is I doubt we’d implement this as some significant and potentially complex UI changes would be needed to handle the multiple param targets, multiple labels and method of linking the button to a knob on PM to determine its current target. And you can already do essentially the same thing with 2 knobs - one targeting the Filter frequency and the other the FM depth.
Seems like it would be a lot of extra work to be able to do something you can already do in a slightly different way.
1 Like
Yeah, I guess it’s not possible. The problem is it would require five Patchmaster knobs per parameter (one for the main parameter, four for each mod input).
If you are using all 4 mod inputs for a parameter, and want to control all their attenuversion amounts manually in a performance, then yes it would. But if you DO want to be able to do that, you probably want to have easy access to the 5 knobs to do it also.
Replicating Surge’s mod matrix functionality is kinda outside the scope of what PatchMaster is intended for.
1 Like
Yeah so Steve I was thinking of something easier which is: if a patch master strip had a selector up top for abcd and that basically made it 4 strips with only one showing a user could do this (and other modal control things) themselves - basically strip “pages”
And then in this specific case page 1 is a filter knob and page 2 is a filter mod depth control set
So rather than the 5 knobs side by side they are on top and paged
That may be a terrible feature but it would solve the problem
1 Like
Yeah - I don’t think that’s something we’d do tbh as ‘hiding things on different pages’ kinda goes against the ethos of what PM is all about - which is putting the main performance controls for a patch front and centre.
2 Likes
Yup like I said it might be a terrible idea. Not my first not my last - lol.
2 Likes
yup!
Just so people know: if a module is marked ALPHA on the face plate then not only is it incomplete, but also all the parameter indices and ranges could change in non-stream compatible ways (in surge vst we say ‘nightlies gonna nightly’ but here since we have individual modules we have the slightly stronger ‘alpha-modules gonna nightly’ semantic).
So if you patch with it your patch may not work with a later alpha or the eventual release. But the adjustment should be easy enough in most cases.
I say this because I’m in the middle of re-doing all the parameters for exactly that LFO which will require steve to re-patch that example probably, or at least adjust all the levels, when he installs the next nightly.
5 Likes