I have these modules far enough along that I’ve decided to tag them as a “1.beta1.0”. I still have lots to do and there will be changes over the summer, but the module set is a good starting point. (Over the summer we will see more filters, more non-generic faceplates, and more performance and code improvements).
We would very much value you’re feedback. GitHub issues are the best approach. I am going to be offline a bit for the end of June and start of July, but all feedback is useful.
just add it and download and you will get the modules in current state matching the manual. Polyphonic Oscillators, LFOs, envelopes, and loads of effects from the VST, as well as a module which plays any surge patch as a polyphonic voice.
Loads of bugs (like I need to map the rack midi MPE to the surge voice MPE for the voice player; and add loads of face panels; and the like). And I’m about to head off on a vacation for a bit. But please let me invite you to download and play with these and raise issues either here or on the GitHub. Like I said, slow response time from me for a couple of weeks but will have some dev time to fix and address issues in July as you find them, as well as finish some modules which don’t have final UIs and add the rest of the filter banks from the VST.
Have fun! And most importantly: if you make any cool music with these modules would love to hear!
@baconpaul - just fyi: i have just successfully compiled the surge-rack modules on arm 32bit and 64bit as part of getting vcvrack running on both architectures (https://github.com/hexdump0815/vcvrack-dockerbuild-v1 - not yet updated and used by https://github.com/hexdump0815/sonaremin) - i used simde (https://github.com/nemequ/simde) to automatically translate intel sse to arm neon and the surge plugins seem to work - maybe this might be useful for a future port of surge to arm too in some way … i’ll soon update the above repos with the scripts and patches i used as soon as i have polished them a bit
on intel i’m impressed how cpu efficient the surge modules are - i’ll still have to see how much of this remains alive on arm
best wishes and keep up your cool work on the surge stuff! - hexdump
Well that is remarkably interesting. A few of us have tried to build surge for a raspberry pi and failed but seems you have got it working. With the caveat that I am on a 2.5 week trip with no development device let me ask a couple of questions
1: did you have to change surge-rack or surge code? If so I would be more than happy to merge a pr appropriately ifdefed
2: can I run an arm build easily in our ci pipeline so I make sure it keeps running? Our Linux box can stage and run a docker image I bet so love to hear thoughts on this
3: I would love surge proper (the headless app not the vstgui) to compile non intel so any docs you have on how you did it could also go back to main repo
But short version is: whoa cool - happy to include changes in our build pipeline or codebase to make your effort easier!!!
enjoy your trip - i think there is no hurry with this - i just wanted to note, that there is now a proof of concept that it works. to your questions:
yes and no - not directly, but i searched all of the intel sse _mm_xyz calls and replaced them with the simde versions simde_mm_xyz … i think this could be done much cleaner by adding a header file which redefines all the _mm_xyz used in surge with the simde ones and is included together with the simde headers via ifdef on arm instead of the intel sse intrinsics headers
As to the prefix to all the _mm yeah the way I would do that is in surge (the submodules of surge-rack) add a directory called “src/arm_support” or some such and then add an “arm_intrinsics” and at the same time add the simde library as a submodule in libs. Then that file looks like
#define _mm_ps_zero simde_mm_ps_zero
I presume. Then in the appropriate place (probably globals.h where we include xmmtrim) do a #ifdef, add the #ifdef to the cmake file for headless and go.
Headless is a standalone exe which is the smallest code path to make any sound with surge indeed. I did it so I could run valgrind and stuff without a DAW; but then the headless code became (most of) the code path I used for surge-rack. (There are a few other rack differences; on windows we compile with visual studio for the VST and gcc for rack etc… and so the surge code has TARGET_RACK).
But anyway if you are interested in having a change like that be part of the surge code base so you don’t always have to merge it in, I would be happy to have that fired in as a PR and work with you to get it merged and so on.
And then perhaps I can finally build that physical surge keyboard with an embedded PI!
Hi! It’s been a while since we updated surge-for-rack even though a load of things have been happening in surge-vst. Thanks to the community team, we just released 1.beta1.2 of the surge-rack modules which include a couple of big changes. Just do a regular update to get them.
Upgraded the underlying surge to the 1.6.3 engine. This means that the wavetable oscillator can read wavetables from many popular WT synths, including Serum; and that there’s a much larger collection of wavetables, including a wave-tabled virtual orchestra
Several DSP improvements, including an expanded distortion effect.
Thanks to @TroubledMind and @Eurikon poking me and helping with design, the modules now have swappable skins also. Some people don’t like that orange and blue it turns out! RMB and choose skins/(skin name). Ships with 4. Classic, Miami and New York which show the color ranges, and @TroubledMind’s Night, which is a great dark mode. If you want to add more skins, just look in res/skins and it should be clear
There’s still a lot of new features coming to surge and I’ll try to keep the rack modules more up to date as we push them. Enjoy!
This week we released Surge 1.7.0 - a major release with lots of new features in the VI. You can read about all the new surge proper features at https://surge-synthesizer.github.io/changelog
Along with that, we are happy to update our rack plugins to 1.7.0. This means that Rack contains our new features, including the cool new wave shapes and built in filters on our sin oscillator, new effects (a new reverb, a flanger, and a ring modulator), and innumerable other behind the scenes fixes.
In the “there’s no testing like the field” camp, we will release 1.7.1 of the Virtual Instrument this weekend and will almost definitely have another update of the modules shortly. There’s a couple of new features (especially the built in filters on the oscillators, but also a couple of effects tweaks) which can’t be turned on in rack.
Yeah, it’s pretty good. @baconpaul any chance you will make a full Leslie effect? I’m not looking for an exact emulation or anything, but Leslie’s do have some feature missing from Surge Rotary. Biggest is only a single horn not dual. I guess you could use a crossover and two rotaries, but… Of course it would be cool it is had a nice “grindy” overdrive, although if you put a good distortion in front of it…
One of the thigns I realized is we introduced “activatable” features which are off by default and the Leslie has that in some of the filter effects. In a soon-to-be-released-but-needs-to-be-coded-first rack 1.7.1 you can get pretty close. With 1.7.0 we did things like split the horn rates and change the drive model too. You should give it a whirl in the surge instrument to see what’s coming soon to rack if you want to know what I mean. But any ideas to improve the circuit we are all ears.
The flanger is also super fun. Push the feedback… you can get some very interesting sounds.
Ha i didn’t even think that! We just released 1.7.0 after 6 months of dev and have found some … edge cases … in the wild. So if it blew up I would want to know
Getting 1.7.1 together including exposing the complete new rotary circuit and a few other things. This week or so.
