Dedicated sampler/SFZ player oscillator

[mortfell]

This is a feature request idea, probably to be filed under far future if ever.... saw someone asking about a SFZ oscillator in the slack chat...
Had also already thought about this idea and have many thoughts for how an implementation could work..... so thought I'd write it down.

IDEA
A more fully featured sampler that could stream samples from the disk, rather than store them in the preset. It could also support the basic functionality of the SFZ format, for loading multi-samples.

To be clear I think this should be a "simple" sample player, with some options for looping, start time things like that and support for LOADING sfz files, but not editing them.

WHY
Lots of Synths now a days support a sample engine to layer realistic sounds along side the synthesis engine (Falcon, Omnisphere and in a more simplified way Serum, Sektor) and It's a cool thing!

SFZ is an open format and it's easy to find free libraries. It's human readable (which is awesome for everyone). It can do a LOT but also can be used for really simple things.
RENOISE for instance uses SFZ files just as a way of storing info about splits and velocity layers.

Adding samples into synth patches, and even using it with FM and filter feedback would be very fun. I also feel there is always a place for a simple well designed samplers. Surge has a great flexible layout already, and a cool modular oscillator design so it could be a good fit.

INTERFACE/IMPLEMENTATION
I have a bunch of ideas in my head about how and SFZ/sampler implementation could look inside Surge, but I need to think about them more, I'll post them here in here when I do.
Please also post comments if you are interested in this idea!!

[mortfell]

IDEAS ABOUT SAMPLE STORAGE LOADING
---------------------------------------------------
I use a few different computers (laptop, home studio, and studio)
and the most annoying thing with Samplers is where they store the data.

Some samplers store data the host chunk data, which is cool, but makes DAW projects HUGE if you have lots of samples or longer samples.
Some samplers don't really tell you how they are storing sample data, This is super annoying when you move a file too a different computer, and the sampler did not ever tell you where it was storing the data.

Some samplers store samples inside the DAW project folder but it seems like support for this is a bit dodgy across DAWS/plugin formats? I've never seen it done really well..... I feel like it would be best to avoid that all together.

I think if Surge ever includes a sampler it should strive to be useful as a simple sampler or something that can use multi-samples as a layer in other sounds. It should be VERY straightforward, deliberate and explicit when it comes to storing samples.

So here is some thoughts: (aka the rambling of a person who has been frustrated by a lot of samplers)

SURGE SAMPLE FOLDER
Surge should have ONE folder set for samples. This folder should act as root drive or " / " if Surge needs to search for a sample, it looks in there!
This folder should be separate from the wavetable/presets folders, and should be able to be user defined for users who want.

The default Surge sample location could come with a handful of lite-weight SFZ sample instruments, There is lots of open source SFZ files floating around I don't think it would be too hard to find good candidates. I'd be happy to contribute some myself! They should be small multi-sample instruments for layering and showing the engine. (rhodes, strings,piano, organ, guitar) that kinda thing.

SAMPLES STORED WITH PRESETS
Samples should only be stored inside a preset if they are under a certain size, something close to the maximum size of Wavetables currently. If you open a sample which is in your "sample folder" it should NOT store in the patch. If you drag and drop or import from another location it SHOULD.

If you import a sample from outside the sample folder and it's larger than the amount accepted for preset saving a pop up should appear. Something like:

"Surge stores large samples in a sample folder located at '/print location to screen/' Would you like to copy your sample to this location?"
"Yes" or "Cancel"
(below could be a checkbox, always copy samples too surge sample folder)

This would completely prevent any confusion about samples storage, and is totally usable for people in pretty much any situation.
If you want portability across machines: copy your Surge Sample folder, or use smaller samples.
Being extremely explicit and inflexible about sample storage would prevent lots of potential bugs and tons of user error.

LOADING SFZ FILES
I think if Surge ever supports SFZ it should ONLY support files loaded from the Sample Oscillator interface.
It could search it's sample folder for SFZ files and auto-populate a menu with sub-menus for the folder the SFZ resides in.

No drag and drop, or import dialogues.... There is just too much to go wrong. And most people don't even know what SFZ is anyway.
If you want to use SFZ, Use the included ones OR put your SFZ files in the sample folder OR link your existing samples folder for SFZ files.

I think that would also cut down on a LOT of potential issues.

** FORMATS**
It would be sweet if it supported Wav, Aiff, and Flac
I've seen SFZ files using all those audio formats.

[baconpaul]

https://github.com/WhiteNoise/OpenSFZ

Is kicking around

Single wav sample playback is super duper easy from where we are now if we just have ‘start time’ ‘stop time’ ‘loop’ and ‘pitch0’ but that’s not very good - I agree if we do this we want a more fulsome sampler.

The folder semantic you outline is exactly how it works today for wt and patches. I only did wav files using the either-or because people have wav files over in other apps they want to drag in.

Where to store the sample is an interesting question.

Tagging this 1.6.n which is the polite tag I use for “not forever” but “not now” :)

[mortfell]

Coooool
Yeah I think it COULD be really neat.
Maybe a more featured but still simple one-shot player would be a good place to start someday

[mortfell]

“The folder semantic you outline is exactly how it works today for wt and patches. I only did wav files using the either-or because people have wav files over in other apps they want to drag in.”

Wait, Are you talking about how it auto populates the wavetable menu?
Or storing with patches?

[baconpaul]

Wt and wav files in docs/surge show up in the menu; sfz could too. That was all I was saying

[mortfell]

I see, thanks

[baconpaul]

no prob - sorry for the semi-coherent original message!

[mortfell]

I thought you were saying that WT files don't get saved in the preset if they are in the wavetable folder. Wavetables always get stored with presets currently right?

[baconpaul]

Yes that is right wt and wav stream to the patch populate the menu from a special set of directories and can be dragged in

You are proposing sfz have only the second of those features

[mortfell]

Yeah That makes sense to me personally.

Even just with the support for larger wavetables it’s possible to have Surge presets that are upwards of 2MB now.

Since that also gets stored with the host you can currently have a song with one bar of midi data and 5 tracks with surge taking up over 10MB on the daw side.

A small multi sampled instrument with one velocity layer is usually between 20-100mb depending on length of sample and number of splits, so you could easily end up with 100mb presets if Surge stored them with the preset. A handful of those in one project and you could m start seeing 1GB or more project files, which is a lot.

For hosts that don’t normally store all project data as one unified file especially this isn’t ideal. I’ve noticed lots of bugginess in ableton and reaper related to plugins when storing excessive amounts of data in the daws project file (such as some reaktor or renoise redux patches)

[baconpaul]

Yeah streaming 792mb of piano sample into an Fox seems unwise. But you buy the cost of non portable patches and missing file handlers

[Godly75]

+1, I use samples all the time in vps Avenger, so I would love to see it coming to Surge, would mean a huge improvement in general.

Import basic sfz should be enough. Of course the more parameters the better. But simple key zones would work also.

Add a simple functional sample editor to it. Start, end, loop, x fade,...

[mkruselj]

Add a simple functional sample editor to it. Start, end, loop, x fade,...

I very much disagree on this one. Have parameters to modulate startpoint, loop start and loop end, yes, but nothing more than that.

[mxmilkiib]

https://github.com/paulfd/sfizz

[baconpaul]

Huh neat thanks!

I’m leaving this issue until after I resolve the architectural problems outlined in #1117 but once that is done we are going to have a lot of opportunity to add to the synth.

[baconpaul]

Did a bit more idle googling tonight and some reading too

https://github.com/stevefolta/SFZero/tree/master/Source

That seems to be the submodule we could use to help us do this post #1117

[esaruoho]

are ya guys serious? some sort of sfz support or import or something? this would be absolute killer!!

[mortfell]

@baconpaul is very serious. He is out of control!!

[baconpaul]

Actually I'm totally in control but not that serious :)

I think it could be super useful though - especially when we are in 6 oscillator mode - to have a few new oscillator classes.

Think "spring 2020 earliest" though. So much work to go before Surge++ is even in an alpha state....

[mortfell]

Haha Yes, I know you are in control.
The scope of what you are doing with Surge is very impressive , Thanks @baconpaul !

[Jorgeelalto]

Actually drag and drop would be a nice thing to have - I don't use SFZ but old-school sampling, yeah I do.

Nevertheless, this would be a pretty cool thing to have, good idea!

[baconpaul]

@Jorgeelalto on mac and windows, drag n drop works right now, pushing the .wav or .wt into the wavetable oscillator. When we finally do this, I could imagine dragging an .sfz doing the same; or maybe even changing it so if your current oscillator is sampler, then the drag doesn't reset osc type. Will see.

And yeah I think this could be pretty exciting!

[Godly75]

Any updates on this yet? Would give surge a whole new level.

[baconpaul]

Lots of adjacent software but still no firm plan