Request for quality sounds for the "LinnStrument MPE" library for Surge XT

[EvilDragon]

Hello!

Patch curator from Surge Synth Team here.

I would say any deeper information about how the patch should be played, or what X/Y/Z are doing, please put this in the Comment field when saving the patch. This stuff is not supposed to be in the patch filename, or any form of subfoldering IMO. This is why we have the Comment field - this comment is displayed as a popup when you hover for a bit over the patch browser. It supports multiline entry so feel free to post more elaborate descriptions.

Feel free to use imaginative names for patches. So instead of "Organ, Hammond, Z=vol, Y=drawbars, pedal=Leslie", it would be much better to do something like "Chunky Organ" or whatever other adjective fits. Then move all the controller descriptions to the comment field - this is so that you don't get these weird descriptors like Z=vol tripping up patch searching by text etc.

I will jump in a bit later to add more tips and suggestions for patch creation, have to deal with some work stuff right now. But this is something I just wanted to quickly share for now.

[MilesParker]

Looking forward to it!

Now ... here's what I can't help wondering as a general question ... what would be the dependencies / resource needs for a purely headless "player" version of the app running under Ubuntu? Folks probably know where I'm going with this.. has there been discussion of this? Where would such discussion go? I checked issue tracker but that's not usually a good place for general discussion like that.

A stand-alone hardware host is an exciting possibility and something that having an open source code base to work from would greatly facilitate! Imagine having a little box that could be docked to the Linnstrument and simply have line level audio out and a simple control/char display for patch selection, gain and perhaps a few other custom knobs to twiddle that could be configured to attach to arbitrary controls. Attach to powered studio monitor (and/or perhaps an integrated/docking headphone amp, for a bit of feature creep) and you have everything you need to play!

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

[MilesParker]

Has anyone discovered a way to define a different curve for MPE timbre / other modulations? From interface it seems I can only define a linear range and that ends up having too abrupt a transition for many cases. Portamento and some other options seem to have it but it doesn't seem part of the rest of modulation toolbox.

[EvilDragon]

Currently there are no "official" modulation shapers in Surge, however you can hack one by using an LFO in disabled mode (right-click Rate slider, then untick Enabled), and then using one of MPE modulators to modulate the Phase parameter. Now you can use any LFO waveform (msot probably MSEG) to shape your modulator's traversal however you want. Then of course, instead of using a particular MPE modulator directly on your target, you use the LFO instead.

[MilesParker]

Thanks, that makes perfect sense.

On a totally different topic, I just played around with playing splits, and though the path wasn't completely intuitive to me, the manual was clear -- and ... this is the first Synth (or DAW) that I've actually been able to get splits working on with full MPE control! Here is the basic recipe, in case it helps others:

1. Select the patch for the first split you want to use. Right click on Scene A and chose Copy Scene.
2. Select the patch for the second split you want. Now, click on Scene A and chose Paste Scene. (Scene B will still contain the Scene and modulation controls from the second patch you selected. Of course, you can do this the other way around, copying and pasting B.)
3. Select CH SPLIT from settings. (The default is Ch 8 for split point which is documented as inclusive of channel 8, but in practice that seems to work fine with standard Linnstrument settings of 2-8, 9-15, so not sure what gives there, but it works.)
4. Rock On!

A couple of notes:

1. I did find the scene selection thing awkward. It works, but feels a bit backward in practice because you need to anticipate the *other* thing you will need before selecting your target. Also it becomes extremely awkward if you want to switch to another patch sound for one of the scenes. Then you have to save what you are working on, go to the other patch, copy it, select the patch you just saved and copy it back. Some kind of "copy from patch" functionality would be nice here..
2. Note that FX is shared between both scenes. This means that if the patch you are using really relies on FX to sound the way you want, you will need to work around that, and set things up to start from the patch you really need the effects from. OTOH, it's nice if you want to set shared ambience for both splits. (Roger, note, appropos the offline conv. we had re: use of effects in patch design. I still agree that adding a bit of default ambience is nice for players.) (turns out I was mostly wrong about this ... see response below.
3. Issues above notwithstanding, when you do get things set up the way you want, you then have a complete performance setup that you can load and work with in real time with no fiddling at all. I imagine that will be worth the initial setup hassle for professional musicians who can't be mucking with screens on stage. It does mean that you could end up with a lot of saved patches. Perhaps having some kind of scheme for setting performance vs. library patches would help here, because there are clearly two different use cases that don't quite overlap.
4. I just really appreciate the deep thought that Geert and Roger put into the UX here. For example, it's so cool how when you select sequencer for one split you automatically get the full layout for the non-sequenced side. The complexity of what needs to happen can make some of this daunting, but throughout elegant design choices have been made that anticipate what one wants to do in practice. Bravo.
5. The patch combination caveats aside, kudos to the Surge team as well for thinking through the tricky bits and making things "just work" as advertised.

[EvilDragon]

1. Yeah it's simply the fact that patches in Surge are meant to contain both scenes, there is no concept of a single scene patch you would load into two or more scene "slots", so to speak. Just the nature of the beast.

2. Well, scene A has 4 of its own FX slots and scene B has the same, so not ALL effects are shared.

5. Thanks!

[MilesParker]

1. Yeah it's simply the fact that patches in Surge are meant to contain both scenes, there is no concept of a single scene patch you would load into two or more scene "slots", so to speak. Just the nature of the beast.

Thinking something like "Copy Scene A|B from Patch X to Scene A|B in Patch Y" + perhaps "Copy global effects from Patch X". I'll try to make this a bit more clear and propose on issue tracker.

2. Well, scene A has 4 of its own FX slots and scene B has the same, so not ALL effects are shared.

Ah ... looks like I need to spend some more time with the FX docs. That and the filter routing were a bit opaque to me.

[baconpaul]

Looking forward to it!

Now ... here's what I can't help wondering as a general question ... what would be the dependencies / resource needs for a purely headless "player" version of the app running under Ubuntu? Folks probably know where I'm going with this.. has there been discussion of this? Where would such discussion go? I checked issue tracker but that's not usually a good place for general discussion like that.

A stand-alone hardware host is an exciting possibility and something that having an open source code base to work from would greatly facilitate! Imagine having a little box that could be docked to the Linnstrument and simply have line level audio out and a simple control/char display for patch selection, gain and perhaps a few other custom knobs to twiddle that could be configured to attach to arbitrary controls. Attach to powered studio monitor (and/or perhaps an integrated/docking headphone amp, for a bit of feature creep) and you have everything you need to play!

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

The synth builds on a raspberry pi. The engine runs inside the vst inside vcvrack inside a Python interpreter and inside a standalone c++ test harness.

Taking a raspberry pi and making it output sound when you input midi in a standalone bit of ui free software is basically a question of “how well do you know rtmidi and rtaudio”. Probably a couple of days work if you have a pi with midi in and audio out and raspbian 64 working.

I have thought often if a little hardware surge device of this nature. But my MacBook is far far more powerful than it is heavy in comparison so haven’t done it. But if you want to hop on our discord (which you can join via the abour page link) and I can share with you how to do it and which code to read.

[EvilDragon]

Thinking something like "Copy Scene A|B from Patch X to Scene A|B in Patch Y" + perhaps "Copy global effects from Patch X". I'll try to make this a bit more clear and propose on issue tracker.

We've already had this request some time ago, and eventually decided against implementing that feature. We forgot to document our reasoning, though...

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

[MilesParker]

The synth builds on a raspberry pi. The engine runs inside the vst inside vcvrack inside a Python interpreter and inside a standalone c++ test harness.
...I have thought often if a little hardware surge device of this nature. But my MacBook is far far more powerful than it is heavy in comparison so haven’t done it.

Thanks! This was actually my main question .. I was pretty sure it was possible but what I wasn't sure of is if it makes any sense -- in particular I'm wondering what the resource requirements / ideal might be for runtime (player) only. Like would a RPi be struggling or have plenty of head room running a fairly complex patch with effects? IOW, I'm not interested in this as an exercise in hackery but whether it would be an effective, non-compromised, general solution for a (mostly) headless hardware synth. What would be ideal is something like the Micromonsta 2 or Rebel Witch but running Surge patches that sound just as good as they would out of Mac.

[baconpaul]

The synth builds on a raspberry pi. The engine runs inside the vst inside vcvrack inside a Python interpreter and inside a standalone c++ test harness.
...I have thought often if a little hardware surge device of this nature. But my MacBook is far far more powerful than it is heavy in comparison so haven’t done it.

Thanks! This was actually my main question .. I was pretty sure it was possible but what I wasn't sure of is if it makes any sense -- in particular I'm wondering what the resource requirements / ideal might be for runtime (player) only. Like would a RPi be struggling or have plenty of head room running a fairly complex patch with effects? IOW, I'm not interested in this as an exercise in hackery but whether it would be an effective, non-compromised, general solution for a (mostly) headless hardware synth. What would be ideal is something like the Micromonsta 2 or Rebel Witch but running Surge patches that sound just as good as they would out of Mac.

So the older features of surge (classic oscillator, the older filters, delay, reverb1) were all designed to run on a 2005 era PC, which is slower than a raspberry pi. The newer ones (modern oscillator, nonlinear filters, ) are designed to run very efficiently on a modern pc, but that is faster than a pi.

But you don't have to target pi. There are faster small systems you could use and as long as it runs linux you could do pretty well. I haven't done a deep dive but theres plenty of meaty SBC out there nowadays. And surge compiles everywhere.

The only problem I foresee is lots of SBC get performance by multi-threading and today the surge engine is single threaded. I actually want to break that constraint since some of our plans for XT2 could quite substantially increase CPU load, but haven't done it yet.

Anyway lets not clutter up this thread with this topic too much. If you are interested in this lets either hop to the monster surge thread on KVR or chat on the surge discord!

[MilesParker]

The only problem I foresee is lots of SBC get performance by multi-threading and today the surge engine is single threaded. I actually want to break that constraint since some of our plans for XT2 could quite substantially increase CPU load, but haven't done it yet.

Anyway lets not clutter up this thread with this topic too much. If you are interested in this lets either hop to the monster surge thread on KVR or chat on the surge discord!

Agreed. Here I just wanted to get a sense of a) whether it is even a reasonable approach and b) if anyone else in Linnstrument community might be interested as well. Please pipe up if so.

(Full disclosure, my own bandwidth on this one is probably limited to some basic exploration, I have other areas I think I can better contribute to with my available time and not able to invest in a lot of experimental hardware rn. So there would probably need to be a hardware oriented person involved on Linnstrument side.)

I just had a thought that if I was going to go the SBC route the simplest, easiest thing might actually be to just buy a refurbished Mac Mini. One other advantage beyond the ease of setup for Mac users is that Apple DACs are generally pretty decent. The big downside to SBC is that we would need to figure out battery power -> AC anyway. (I'm not sure but I think only things in the RasberryPi range will get enough juice from USB power.) But we can take this one offline as well.

[Roger_Linn]

Currently there are no "official" modulation shapers in Surge, however you can hack one by using an LFO in disabled mode (right-click Rate slider, then untick Enabled), and then using one of MPE modulators to modulate the Phase parameter. Now you can use any LFO waveform (msot probably MSEG) to shape your modulator's traversal however you want. Then of course, instead of using a particular MPE modulator directly on your target, you use the LFO instead.

Hi all,

Sorry for this late reply. For some reason, KVR didn't send me notification emails about this thread until yesterday, and I appreciate Evil Dragon's and baconpaul's posts.

Regarding Evil Dragon's post above, Paul had kindly offered me the same suggestion, which I used to create more pressure curves that are more sensitive to light touch on the following of the sounds in my "LinnStrument MPE" set:

Basic LinnStrument Sounds
Hammered Strings, Press=vol, Y=damping
Hurdy Gurdy, Press=vol
Organ, Hammond, Z=vol, Y=drawbars, pedal=Leslie
Synth, Press=octave, Y=comb
Synth, Press=Vol, Y=Vowels

Here's how I implemented it:

1) I click LFO1, which displays the LFO1 window at bottom, including little pictures of 10 waveforms, I select the lower-left one (MSEG).
2) In LFO1 (now titled MSEG1), I right-click on the Rate slider and deselect "Enabled".
3) I assign the "MPE Pressure" modulator to "MSEG1 Phase".
4) I assign the output of MSEG1 to control volume or filter or whatever I'm using to control total sound volume/loudness.
5) I click on MSEG1's large envelope display, which displays it very large in the upper section. I then right-click this display and select Actions > Delete to delete all envelope phases except the first one. I then drag the curve up in order to create a pressure curve that sends higher modulation values at light touches.

[wakyct]

I finally got a chance to try this tonight and it's a lot of fun, thanks for the instructions on the support page and the patches download, I've never used a daw or vsts and it was pretty straightforward to get it going. Sounded good in Ardour on a 10 year old laptop -- now I'm interested too in that embedded Surge idea!

[teknico]

Plain Surge runs on Zynthian, not sure about XT.