Vember Audio Surge is now open-source

[dtrq]

Will there ever be proper FM routing with non-sine\fm oscilators (e.g. WT to WT)?

Already in there with FM 1>2 1>2<3 etc..

Nope, it does some kind of modulation, but it sounds nothing like FM. Only Sine and FM2\FM3 oscillators work this way.
EDIT: It seems like it's too weak with a WT carrier even with the fm slider set to maximum. When generated sine already goes full noise, WT sine is only slightly modulated and muffled.

[kinwie]

Neat. Thanks for the testing, and always happy to hear your music if there's a link to share.

And good eye on this. I can't believe this has been wrong this way forever. It was a 10 second fix, and I fixed it in the nightlies which are going to come out in about 30 minutes. If you want to test again later this evening or tomorrow, would be appreciated. We also fixed a few other bugs folks found in our testing, and have one or two small ones left before we print the final release next week.

Thank you very much for the numbered param . It will be easier now and less confused to automate the fx parameters of my next surge synth track in other new songs. The new nightly version runs great as before, very appreciated

A song i produced is a simple teenage-pop tune. I use 2 Surge tracks for the 8th upbeat and 16th arp in the chorus to give the song a little bit electronic nuance and Surge's sound character blended really well.
It's probably foreign language to you but here's the link to check it out :

[Gone soft]

Will there ever be proper FM routing with non-sine\fm oscilators (e.g. WT to WT)?

Already in there with FM 1>2 1>2<3 etc..

Nope, it does some kind of modulation, but it sounds nothing like FM. Only Sine and FM2\FM3 oscillators work this way.

That is FM. What you want is probably PM (Phase Modulation) which AFAIK is what is in the so-called FM2 and FM3 oscillators. Yamaha would do OM but call it FM in many of their synths from the eighties on, and it became something of a convention to keep misnaming it and sometimes calling a royal FM "analogue FM" or some such to emphasise it's something different from what is usually known as FM. Using both FM and PM in one synth without making any distinction between them or even mentioning it in the manual is unfortunate.

[dtrq]

Whatever you call it, one would expect the same results when using FM routing with same waveforms regardless oscillator types. WT sine sounds broken when compared to the generated sine.

[EvilDragon]

Known issue about FM not working well with wavetable oscs (and is not even implemented for Window oscillator).

https://github.com/surge-synthesizer/surge/issues/1253

[baconpaul]

Known issue about FM not working well with wavetable oscs (and is not even implemented for Window oscillator).

https://github.com/surge-synthesizer/surge/issues/1253

Yeah if you go read that issue you can see that I think I identified found the problem. The thing is fixing it would change how all current fm-wt patches render. I’m out of slots on the oscillator params to adjust behavior so there’s an old mode and a new mode. So fixing this will change saved patches and renders which I’ve tried not to do. Will ponder a bit more

[dtrq]

That's a shame, combining wavetable and FM synthesis is one of the most essential technique in modern sound design. Hope it's gonna be solved eventually.

[Echoes in the Attic]

Known issue about FM not working well with wavetable oscs (and is not even implemented for Window oscillator).

https://github.com/surge-synthesizer/surge/issues/1253

Yeah if you go read that issue you can see that I think I identified found the problem. The thing is fixing it would change how all current fm-wt patches render. I’m out of slots on the oscillator params to adjust behavior so there’s an old mode and a new mode. So fixing this will change saved patches and renders which I’ve tried not to do. Will ponder a bit more

What about having a global setting in settings menu for new mode or old mode, which changes the behaviour over the whole synth?

[baconpaul]

What about having a global setting in settings menu for new mode or old mode, which changes the behaviour over the whole synth?

That’s the first thing you think of yeah, but you don’t want it global. You want it so old patches don’t change and new patches have the right behavior. So what you really want is a mode where (1) all current patches which are loaded have the broken behavior and keep it, (2) all new patches including init have the correct behavior but can be toggled to broken and (3) that’s remembered on a per-patch level so you can do things like save DAW state for long periods or share patches.

It’s not impossible (the way to do it is to add a per-instance toggle and have that per-instance toggle do something different based on patch streaming version) and some other things will shortly work that way (with the upcoming 1.6.5 mpePitchBind kind of works this way, just at the DAW streaming not the Patch streaming level) so I’ll tag the issue for 1.6.6 and do something reasonable for that. Not the sort of surgery you do when you are 5 days from a release though so best bet is to subscribe to that github issue and you can see as we progress.

Thanks for pushing on this. I agree it would be useful and agree it is an irritating inconsistency

[baconpaul]

Hi

We are happy to release Surge 1.6.5 today. As normal you can grab it at

https://surge-synthesizer.github.io/

1.6.5 includes a load of changes to the tuning implementation, a bunch of fixes and features in the VST3, new content, modulation enhancements, MPE fixes, UI and workflow improvements, bug fixes, and more. https://surge-synthesizer.github.io/changelog/ details all the new stuff.

We recommend everyone upgrade to 1.6.5; and at this point also encourage you to use the VST3 over the VST2 version.

Finally, the synth keeps improving because of thoughtful code, contributions, testing and feedback from the community. If you have an idea for surge or find a bug, please reach out to the team via our GitHub, slack, or other social media places. And especially if you are a windows C++ developer with virtual instrument experience looking for a cool open source project, we could use some help on a couple of things.

We hope you enjoy making music with Surge! Have fun!

[thecontrolcentre]

Hi

We are happy to release Surge 1.6.5 today. As normal you can grab it at

https://surge-synthesizer.github.io/

Thanks

[focusrite]

Hi

We are happy to release Surge 1.6.5 today. As normal you can grab it at

https://surge-synthesizer.github.io/

1.6.5 includes a load of changes to the tuning implementation, a bunch of fixes and features in the VST3, new content, modulation enhancements, MPE fixes, UI and workflow improvements, bug fixes, and more. https://surge-synthesizer.github.io/changelog/ details all the new stuff.

We recommend everyone upgrade to 1.6.5; and at this point also encourage you to use the VST3 over the VST2 version.

Finally, the synth keeps improving because of thoughtful code, contributions, testing and feedback from the community. If you have an idea for surge or find a bug, please reach out to the team via our GitHub, slack, or other social media places. And especially if you are a windows C++ developer with virtual instrument experience looking for a cool open source project, we could use some help on a couple of things.

We hope you enjoy making music with Surge! Have fun!

Sfz osc incoming?

[Hanz Meyzer]

1.6.5 includes a load of changes to the tuning implementation, a bunch of fixes and features in the VST3, new content, modulation enhancements, MPE fixes, UI and workflow improvements, bug fixes, and more. https://surge-synthesizer.github.io/changelog/ details all the new stuff.

Hi,

I think Surge still has a bug regarding samplerate: The unison spread is dependent on the samplerate, but should not be. For example, try the "polysynth->megamega" patch. First listen in 48kHz, now switch to 96kHz. The unison spread sounds the stronger the high the samplerate is. So I guess the calculated pitch detune formula actually is samplerate dependent here, but this makes no sense.

Then I would kindly request an oversampling 2x option, so Surge "simply" would internally calculate with the doubled samplerate, and after all mixing together (before fx), there will be a resampling to actual DAW samplerate.

[baconpaul]

I think Surge still has a bug regarding samplerate: The unison spread is dependent on the samplerate, but should not be. For example, try the "polysynth->megamega" patch. First listen in 48kHz, now switch to 96kHz. The unison spread sounds the stronger the high the samplerate is. So I guess the calculated pitch detune formula actually is samplerate dependent here, but this makes no sense.

Then I would kindly request an oversampling 2x option, so Surge "simply" would internally calculate with the doubled samplerate, and after all mixing together (before fx), there will be a resampling to actual DAW samplerate.

On the first, I added that as an issue to our 1.6.6 milestone. I'll look this spring. You can track our progress here. https://github.com/surge-synthesizer/surge/issues/1548

On the second, Surge already oversamples internally, with a 2x option on at all times. If you look in the source for BLOCK_SIZE_OS vs BLOCK_SIZE you can see where it switches back and forth.

Thanks!

[baconpaul]

Sfz osc incoming?

Sfz osc contemplated. I personally think it would be sonically interesting, so that means there's a good chance I will tackle it. But this is all volunteer / hobby time so it may be a while. As may everything else! (If you are a dev and would like to work on it happy to collaborate)