Floe coming from Frozen Plain

[EvilDragon]

But we wouldn't be able to support the MIDI features, filters, effects, LFO, EQ, etc., because Floe takes a very different approach in that regard and we want the freedom to innovate in this space rather than conform to SFZ.

I think you could in fact do both (with time). It should be perfectly plausible to support the pretty standard modulator setup that SFZ supports (both in v1 and v2), and also be able to innovate in this space (whatever you actually meant by that is leaving me curious, though - it's just modulation. You got your LFOs, envelopes, step sequencers, MIDI message based modulators... All rather usual and expected stuff).

[Shabdahbriah]

But we wouldn't be able to support the MIDI features, filters, effects, LFO, EQ, etc., because Floe takes a very different approach in that regard and we want the freedom to innovate in this space rather than conform to SFZ.

[...] whatever you actually meant by that is leaving me curious, though - it's just modulation.

Somewhere in this stuff, perhaps an answer:

https://floe.audio/usage/parameters.html

https://floe.audio/develop/develop-libraries.html

https://floe.audio/develop/library-lua-scripts.html

https://floe.audio/develop/packaging.html

[FrozenPlain]

But we wouldn't be able to support the MIDI features, filters, effects, LFO, EQ, etc., because Floe takes a very different approach in that regard and we want the freedom to innovate in this space rather than conform to SFZ.

I think you could in fact do both (with time). It should be perfectly plausible to support the pretty standard modulator setup that SFZ supports (both in v1 and v2), and also be able to innovate in this space (whatever you actually meant by that is leaving me curious, though - it's just modulation. You got your LFOs, envelopes, step sequencers, MIDI message based modulators... All rather usual and expected stuff).

Ok that's good to know, and yes that sound plausible in time.

Whether to support an existing technology (such as all the various features of SFZ), I would use criteria such as these for Floe:
- Is the benefit big
- Is the cost of implementing it small
- Does it align with creating a product that is simple, GUI-based and has similar UX to major plugins that producers are used to
- Does supporting it lock the architecture of the plugin into a certain way of thinking makes other things harder

So I can see supporting the sample mapping of SFZ is a big win. Maybe the LFO and envelopes could be good too. The MIDI conditions and effects of SFZ would be a harder sell I think.

[EvilDragon]

Right, that makes sense. And also round robin and maybe the choking stuff is worth importing too.

[FrozenPlain]

Yeah for sure, the trigger criteria stuff will be important for more complex instruments. That will be added to the Floe format too.

[enroe]

Ok I think I'm sold on the SFZ idea. It probably won't make it into v1.0, but maybe v1.1 will have the limited SFZ support we've discussed.

Just out of curiosity, @kneebone77 and @enroe, where do SFZ instruments typically come from? Are they paid products from developers or more custom, one-off things?

So - a few comments from me:

--- Where do sfz instruments actually come from? ---

Briefly outlined:

After the heyday of hardware samplers from Emu, Akai, and
Roland, the era of software samplers arrived in the 1990s
with sound cards from Terratec and others. One format, the
"sf2" format, stood out: With it, any amateur musician could
create a sample for their PC. This led to a burgeoning
number of fantastic, freely available sample sounds online.

But sf2 had some drawbacks. First and foremost, it was a
cryptic block format. Then a certain Rene Caballos had the
idea of ​​using a simple text format as a sample playback
definition – and the SFZ format was born. Cakewalk and
Plogue-Aria subsequently adopted this format. But many
sf2 fans also found the new SFZ format fantastic. It has
several advantages:

1. It is relatively widespread and well-known.
2. There are the most samplers that understand the format.
3. It is easy to edit, namely with any(!) text editor.
4. It is not hampered by proprietary restrictions.

You can find a lot of information about this here.

One more comment: If you build a new sampler, then that is of
course a great event for the musician community and very
welcome.

However, there are already a lot of samplers in the sampler
world, and accordingly, a lot of small niche formats for samplers.
So, the question is whether developers want to add another
"niche format" like this. And thus, presumably, such a niche
existence will be reserved for a very few musicians?

Or whether you simply use an already established free format?
And thus, from the very beginning, you're part of a large musical
community—and can suddenly play a large number of
multisamples that already exist?

A well-known instrument overview is this , but there are
almost countless others.

[FrozenPlain]

Thank you very much, that's good to learn.

[kneebone77]

Just out of curiosity, @kneebone77 and @enroe, where do SFZ instruments typically come from? Are they paid products from developers or more custom, one-off things?

I assume someone is making paid multi-samples in SFZ format but I've never really seen it. Tons of Freewre SFZ's and quite a few freeware utilities for creating your own custom SFZ's.
Plus a few freeware utilities for converting other Multi-sample formats into SFZ.
It's well supported at this point.

[art&sound]

Great news!

@FrozenPlain, many sample libraries still come in SFZ. Grab a pack from a company like Samples from Mars for example and you'll typically find a few format options with SFZ being one of them.

Rene from rgc:audio designed SFZ as an open-source replacement for SF2, and all the other formats that existed at the time, like Gigastudio, AKAI, etc, and it has gotten a decent amount of support over the years. A decent amount of samplers now support the format.

Of course, Kontakt dominates the sampler/sampler library space. Part of it has to do with them aggressively putting out their own stuff and Komplete being popular. It also has a lot of GUI customization, which is a major draw for people who want to build instruments. Look at Slate+Ash Cycles for an impressive look at what can be done. And then we have SampleTank, Best Service Engine, Big Fish Audio Momentum, etc etc.

Floe looks great. For it to gain traction I think it being able to use 3rd party libraries would be important. Otherwise it's use this sampler for this, and that sampler for that. SFZ support will allow Floe to also use more than just Floe libraries. You might consider what other types of samples it could eventually load after thinking about the cost/benefit.

[audiojunkie]

Floe's beta is now live. Try it out with making some real music. There still may be the occasional bug - please let use know, we're very keen to fix them.



There's 5 high quality and free sample libraries to install and use.

Additionally, all existing FrozenPlain libraries are completely compatible with Floe. Make sure to install the Mirage Compatibility package too though.

Floe's homepage: https://floe.audio/
Downloads: https://floe.audio/installation/downloa ... -floe.html
Available packages: https://floe.audio/packages/available-packages.html

Since the last alpha:
- Added AU (Audio Unit v2) support
- Brand new instrument browser supporting tags, search, and filtering by library
- Brand new impulse response browser featuring all the options of the instrument browser
- Brand new preset browser with tags, search, and filtering by library. Preset metadata is tracked, library information is tracked, file changes are detected, duplicate presets are hidden.
- New built-in convolution reverb impulse library with 33 impulse responses

What?! No Linux binaries?! How can this even begin to be considered cross platform? In this day and age, especially with all things open source, Linux is in every way an equal partner in the realm of music production. Please tell me that I am completely mistaken here! We are living in the year 2025, are we not?

[FrozenPlain]

@art&sound Thanks the more info, and feedback in general!

This is got me thinking about the Floe format vs other formats a bit more.

Floe's sample library format is a bit like SFZ except you write using the Lua programming language. It's a hugely nicer experience and allows you to make complicated sample library configurations in a manageable way. https://floe.audio/develop/develop-libraries.html

The sample library development features are all still early days though, but it's usable.

SFZ support, when added, will allow for simple, existing SFZ libraries to be loaded and used. However, using the Floe format will be necessary for certain features - it already has features that SFZ doesn't, such as: tags, attribution definitions (to better support using CC-BY samples), certain metadata, auto sample mapping, more flexible region groups, and other minor things.

You're right about other formats too. Maybe there could be strong case for supporting Decent Sampler, Ableton sampler, etc.

I would just say though that Floe is not trying to be a generalist. It's trying to offer a curated, opinionated experience for users: no-hassle, integrated, and standardised. To achieve that it's very helpful to develop the sample library format alongside the plugin. Hence our focus on the Floe sample library format and not others at the moment.

Another thing to consider later down the line is developing a migration program that would convert other formats to the Floe format. This would then allow for someone to then edit the converted code to add missing Floe-specific features if that was important to them.

@audiojunkie Correct, no Linux support at the moment. It will happen though. We already use it for development. Just a warning though, it will probably be CLAP only.

[Uncle E]

Maybe ask Moss to add it to ConvertWithMoss?

https://www.mossgrabers.de/Software/Con ... hMoss.html

[audiojunkie]

@audiojunkie Correct, no Linux support at the moment. It will happen though. We already use it for development. Just a warning though, it will probably be CLAP only.

Cool! Something is something! Thank you for supporting Linux!!

[FrozenPlain]

Good idea with ConvertWithMoss. When Floe reaches version 1.0 I'll propose that addition.

[kneebone77]

SFZ support, when added, will allow for simple, existing SFZ libraries to be loaded and used. However, using the Floe format will be necessary for certain features - it already has features that SFZ doesn't, such as: tags, attribution definitions (to better support using CC-BY samples), certain metadata, auto sample mapping, more flexible region groups, and other minor things.

SFZ as an sample mapped import option is all I'm really after. The fact that Floe already has features outside of SFZ is Splinded! I'm excited.