Right so on the language you have adopted (which I like) the current behavior for m != n is 11111111xxx independent of m
And as I’m sure you can imagine this bit of code has to be tight
But let me take a look and see if there’s a way to add some options
I think 1111111 or 1230000 or 1231111 for 3/7 are all good choices. I am not sure I’m sold on 1231231 but I admire it’s creativity 
I think the argument for 1231231 is “apply the most diverse modulation available” but if doing MP_n = (n % M) is significantly costlier than the other options and there’s no good way to cache it and only recompute on poly changes, it’s not that different than 1231111 in effect. Agree 1230000 is reasonable. I don’t know if any user would prefer 1111111 (“where’d my polyphonic modulation go?”) to any of these options–it’s kind of the “punishment” choice :)–but it does signal that something’s mismatched, even if interpreting that signal might be hard and seem bug-like at first (per @DaveVenom’s report)
Ideally I would be able to have them all and then add an inscrutable menu item to each module which has people diving into the manual when their polyphony mismatches, and we choose a good default (and probably 1230000 meets the least surprise model)
But I need to refresh myself on how hard that is. Like I said tbis is some code where the first version wasn’t fast enough so I spent some time on it….
OK looking at the code, changing from “1111111” to “1230000” is a two character change and has no performance impact.
the other cases are all hard because we basically address the input channels as SIMD values. so I need to calculate and compute a shuffle load. I might (might) be able to do “1231111” with a simd mask operation and only add an instruction or two. but 1231231 is right out alas.
Stay tuned. I’ll figure out something today and update here.
Ah, got it. My bag of tricks for this kind of thing doesn’t take SIMD into account–I can see why storing an infrequently updated mapping would still be too slow.
I think 1230000 is good and is not going to seem like a bug to anybody–if you want poly modulation, provide it! Anything fancier than that is highly optional gravy
(TBH/IMO I’m not sure that 1111111 even deserves a right-click option–that really does only seem suited to me for the poly voice/mono mod scenario–but, again, might well be missing something).
Also, y’all are awesome!
Ha yeah.
Anyway here’s my test case. I think we all agree that the first and third row are correct. The thing which is counter-intuitive is that the second row uses 111 rather than 120 correct?
I can just change that if you agree. I agree with you it is more natural behavior.
PolyModMismatch.vcv (2.1 KB)
Yeah now i use it in that patch, it is clear “120” is the right answer. I don’t know why I ever thought a fake monophonicization was correct. But to be honest most of my test cases were either mono or matched so its not like we thought about it that hard.
I’ll merge that now, which is useful, because it makes that section of the manual easier to write this afternoon too. Chuckle.
ah, healthy paranoia is good. Too bad you didn’t read my long treatise on the evils of DC on VCO outputs I put up about a year ago 
i actually have read that thread! and thought “yeah good thing surge doesn’t have a dc problem” and then never tested the raw oscillators, and didn’t think our dc was eliminated further down our chain (in our almost-always-on HPF in the VST).
but anyway after further testing today I merged it as default on but still toggle able off.
Hey, with most audio software development this would be something your users would discover and fight for six months to get your attention about, then wait for a patch a year later 
This is moving way ahead of the curve.
But yeah, that’s exactly the right test case, and 120 is perfectly natural. (One funny thing I noted about the 111 behaviour is that when you mult the sine LFO in the second row to input 3, you change only voice 2 )
+2 for a better user experience and easier manual writing!
Well, you are in good company. Befaco Even VCO still puts out a ton of DC after all these years.
Anyway 120 is merged and will be in the next nightly, in about 20-30 minutes
@Squinky the DC blocker i put in is a tiny bit of code. Doesn’t belong as a standalone here but if you want I could make it a standalone module in the BaconPlugs collection (which I recently did a refresh on, since they were basically still the same as the first v0.5 treatment of them). Let me know if that would help.
Just as an FYI, Nysthi already has a ‘4DCB’ module which is a 2hp, 4 x in/out DC Blocker utility which seems to do the job well.
My opinion (bias) as that the DC blockers belong in the module - stand alone is a pain for several reasons. The main one is that ignorant users won’t use them, the other is that it’s extra patching and panel space. Put them in the module!
Here’s the panel of my old “Shaper”, btw. I put it right there (AC/DC button):
Right
Well surge now has a DC Blocker also so we can stop hijacking this thread with a constant offset noise and instead get back to the regular zero-based oscillations of users giving us feedback and us fixing it. Chuckle.
Valley Dexter has a lot of different algorithms build in but if you want to go real far out (and you seem like you would) the Valley Terrorform is fine.
As you’ll see on your own issue, this has been fixed but admittedly not yet back to the library due to the rather protracted process for Befaco series.
Edit: sorry Paul for further hijacking - I love surge xt and have no meaningful feedback other than I’ve been having such fun with it!
(ducking back under OT caution tape)
For FM algo exploration, I can’t recommend @sys.del 's Algomorph enough; not in the v2 Library (yet?) but since you’ve already gone off-piste:
The doc page has a list of suitable operators, including FM-OP, Kitchen Sink, and some others. Gonna try to make this slightly OT by suggesting that new Surge XT modules might be an excellent addition to this list!
It is funny, but I don’t like to go “real far out” in VCV. I have little interest in the subtleties of DSP and classic synth circuitry and algorithms. I do like to push individual modules to their limits though. Mostly, I only want to make complex but good sounding music. But, that is just me. I think I have gone as far into FM as I want. I thoroughly explored XT FM and Kitchen Sink and and happy to just stick with FM-OP, although both Surge XT and Squinky are excellent, as far as I can tell and far more capable than FM-OP. FM-OP is pretty useful for making Meander conducted/ sequenced harmony, melody and bass.
I’m still exploring all of the XT oscillators with Meander though:)
OK so its the end of the weekend! If you haven’t let me encourage you to grab the nightly again since a lot has changed.
As promised a rough roundup of issues identified and fixed since Omri’s video
I changed the version number to be not-insane. The beta is now “2.0.beta.0-nightly-hash” and when its in the library it will be “2.0.0.0”.
Fix that font problem in Rack Pro VST
The envelope retriggers from the prior value, not from zero, unless you opt in to the from-zero behavior
There’s a DC Blocker.
Change the behavior of polyphonic modulators on polyphonic modules where the polyphony mismatches
UI changes including
There are also myriad smaller fixes I won’t share here, but they all came from feedback from users here, on youtube, on discord, and on GitHub. So thanks everyone!
If you downloaded this week, a fresh download would be great I’m sure. There’s lots fixed and better.
And finally thanks for all the feedback and support. We’re delighted in how well these modules have been received!