Vember Audio Surge is now open-source

[EvilDragon]

It never got fixed because:

"The problem is pretty straight forward though. energyXT creates an editor but never calls the dispatcher with effEditOpen, so we never open the editor.

I have no idea why energyXT never sends us effEditOpen but since it doesn't there's not much I can do."

From the github issue I just linked.

[ENV1]

It's unfortunate but it's a clean cut licensing-wise. VST3 is truly free and open source software, VST2 is not. The current Surge synth team would like to steer away from legal ambiguities and gray areas that VST2 is full of now after Steinberg did what they did to VST2.

Makes sense from their point of view.

Still unfortunate, but not the end of the world.

Keep up the good work!

[EvilDragon]

By the way, you SHOULD be able to load Surge VST3 inside your VST2 host using something like Blue Cat Patchwork.

[baconpaul]

Hi,
I thought that we can use alternatives for vst2 https://github.com/sadko4u/lsp-plugins/ ... /steinberg https://github.com/osxmidi/LinVst/blob/master/vestige.h https://git.iem.at/zmoelnig/FST
But as I can see Surge vst2 part uses headers from public.sdk/source/vst2.x/ which be not fully reimplemented. Is it?

Yeah I don't think that'll work.

The VST2 license has a crystal clear no-reverse-engineering statement in it. It is unclear to me whether any of those packages meet it, and if you google around dev forums it is unclear to a lot of other folks also.

That said: surge is open source. If you want to fork the project, modify the VST2 code to use one of those headers, and make and distribute a build, as long as you distribute all your source changes, no one on the surge team would (or could) stop you. Heck, there’s even an azure pipeline setup in the repo which would let you run your own builds and binaries on github!

[Kott]

I see. Thanks for answer.

[mustgroove]

Is this a known issue with Surge (1.6.6) in Ableton Live (running macOS 10.14.6):

1. Start a new Live project
2. Create an instance of Surge on a track of a given plugin format (e.g. VST2)
3. Try to create a different plugin format (e.g. VST3 or AU) instance of Surge on a different track - nothing happens. There's no device created on the track whatsoever, and Live doesn't give any error message, just simply nothing happens.
4. Create a new project (without closing Live)
5. Try to create an instance of Surge of the same format used in step 3 - Live still does nothing, it's still not possible to create an instance of those formats at all.
6. Quit and restart Live - now you can create an instance of any plugin format of Surge again, but the same thing repeats itself - instances of any other format are impossible to create until you quit & restart Live.

[baconpaul]

Yes. We've been unable to make live load two flavors of surge at once.

Been open since late 2018 actually!

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

In the nightly installer on mac, we even pop up a warning explaining this (but not in 1.6.6); and also encourage people to prefer the AU over the VST3 in Mac Live

[mustgroove]

Ah right, thanks baconpaul - it's super weird that the issue persists even in new projects, and is only "reset" when you quit & restart Live. I have some existing projects which used different flavours of the plugin so I've been running into this a bit lately (and needing to quit & restart Live to switch between projects).

I'll try to stick to the AU in Live moving forward

[Hanz Meyzer]

If you enable sandboxing for Surge, it might fix the problem (works in Bitwig). This is most likely caused by globally shared Objective-C references, so the bug in the objective-c part or so.

[JLMORIART]

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.

I was linked here from the github, is this really where discussion about Surge is taking place? In one big thread, with no dedicated forum? (I can't imagine searching to see if someone has already asked about this manually...) Please feel free to point me somewhere else if necessary. Or maybe this should be happening somewhere back on GitHub?

Anyway, I've got a couple of mutually unrelated but both equally pivotal-to-me questions about Surge:

1. When I first installed (via .deb file on Ubuntu 18.04) it took me a while to realize that the plugins were installed to usr/lib/vst and usr/lib/vst3 instead of usr/share/Surge like it says in he manual. And now, after an update (I saw Surge in the list in the update manager at least) the usr/lib/vst3 folder is gone!

Did the vst3 plugin file install directory change in this update? If so to where? I still don't see the plugin files in usr/share/Surge either.

2. For the short time I had it working, I was trying to get microtonal playback using custom .scl files and .kbm files so that I can map specific notes to specific keys on my AXiS-49:
https://i.imgur.com/EWjR69P.jpg (https://i.imgur.com/EWjR69P.jpg)
In a mode that sends these midi notes for each key:
http://www.c-thru-music.com/images/selfless.gif (http://www.c-thru-music.com/images/selfless.gif)

This results in very non-linear mappings of midi notes to piches, which might be the source of some of the following, but I imagine not all.

When doing this (loading in a .scl file, and then a .kbm file to dictate which notes of the scale should be assigned to which midi notes):
-The majority of patches make either no sound, or are unintelligible and very quiet.
-Many others are pitched down probably 5 or 6 octaves to low. (You can hear the polyrhythm that turns into a very low tone just as it speeds up enough at the top of the keyboard to become... a tone xD)
-Some of the patches seem to sound ok, but are drastically out of tune, maybe drifting substantially as you go up and down octaves. Others have very messed up overtones/other pitches. (This one is unfortunate but understandable I guess, since it's probably using scale degrees as part of the timbre itself, but it doesn't know I've changed the pitches of all those scale degrees?)
-Even the patches that sound best and react correctly to the tuning seem to have many of their settings cranked when I load the .scl file and .kbm file, so that it is still a drastically different sound than it was before. For example, vibrato depth seems to always get maxed, leaving me with timbres that are, by default, super-duper extra shaky.

Any idea as to why so few of the Patches respond correctly to the tuning and keyboard mapping? Is there anything I can do about it? Any idea why those seemingly unrelated effects are changing when the tuning and mapping files are loaded?

Thanks very much for any help! (And, like I said, please feel free to point me somewhere else if this isn't the place for this sort of thing!)

[EvilDragon]

VST3 plugins have a fixed path on every platform, it's unlikely that this has been changed.


All SCL and KBM microtunings I am loading here work perfectly from what I can tell... this has been very extensively tested by one of microtuning specialists (Jacky Ligon), so... not sure what to say. Maybe you could try the latest nigthly version instead of the official 1.6.6 release (handle with care, obviously)?

[clipnotic]

VST3 plugins have a fixed path on every platform ...

And that's really good!

[baconpaul]

Most of the convo happens on GitHub or slack or the Facebook group. (I'm in the first two not the last).

But we have tested non-monotonic kbm mappings pretty careful. That said, they can be complicated. If you have a non-monotonic mapping which is breaking a few things to test

1. Do the "show current tuning" in the tuning menu. Do the frequencies per key look right?
2. If they do does the init patch play with the tuning properly?
3. If it does, can you identify a patch which does not?

Once you have the answer to those three, drop them on a GitHub issue (or here - we read this thread every now and then) along with your scl and kbm and we can definitely look!

[baconpaul]

If you enable sandboxing for Surge, it might fix the problem (works in Bitwig). This is most likely caused by globally shared Objective-C references, so the bug in the objective-c part or so.

Yeah sandboxed hosts are fine indeed. This is clearly something about process space sharing, and indeed may be objective c references (but I think a similar thing happens in some linux hosts so there are probably more references than that). Honestly, we've not made it a top priority to fix to date, since each individual flavor works great. And Thanks!

[baconpaul]

We are happy to announce the release of Surge 1.7.0

Surge 1.7.0 is a major enhancement to the synth with literally
hundreds of changes, new features, new FX, bug fixes, new patches,
new modulation options, and a large collection of UI enhancements,
including a dark skin. It is available now at

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

You can read the changelog at the surge synth site:

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

The Surge Synth Team which has collected around the project in the
last year has put a lot of effort into maintaining and expanding the
synth. We hope you enjoy it! If you would like to work with us on future
versions, please do get in touch!