sfizz : An Open-source SFZ Engine/Player in development

[kinwie]

You've broken self-muting again! This'll be a third way of doing it now...

What do you mean? Can you please explain more detail?

[kinwie]

Self-muting is simply using group=N and polyphony=1. I explain it in my doc

[pljones]

Your document says it needs changes to existing implementations. To me, that means you've broken many SFZ implementations. It's basically a blocking reason for adopting your solution. I don't have the time.

I may not be understanding what your document tries to say, but unless you have backwards compatibility on self-muting, I'm not interested, sorry.

[kinwie]

You mean self-muting on a key when use with CC, for example to switch between Hihat articulations?
Yes, I think it can be done like what sforzando can.

sfizz takes the middle way between Cakewalk's and Aria's implementation.

"No self-muting" like Rgc sfz and Cakewalk behavior is good and useful, e.g. for users who played the sfz that auto-converted from other formats like sf2, exs, kontakt, etc. Because converter always took the 'exclusive group' number from source format, for both group= and off_by= numbers in sfz.

While the usage with CC and choking is the same as what Aria can.

There are lots of different implementations in sfz. Even Aria/sforzando did some of its own implementation/behaviors, differ from what Cakewalk/Rene did (the original).
sfizz try to walk in between.

[kinwie]

My biggest whishlist is the implementation of "output" opcode so sfz player can have the multi-output feature and adding second-set of choke group opcodes
(https://github.com/sfz/opcode-suggestions/issues/3)

[Obsolete462444]

Hey Kinwie,

good to see you still being active for the SFZ cause.

I really like the idea of Sfizz as an open source SFZ player, nice initiative.

I'm also curious about the advantages over simply using Sforzando, which to me is the standard playback engine for SFZ mapped sample sets?

One thing that could set it apart would be a graphical interface for quickly creating mappings and exporting them.

Maybe not a full scale sampling workstation with convoluted feature set, but a simple visual way to create and export .SFZ mappings. Something that can also read and automap the key description contained in the names of properly named audio files.

I think this would also enhance the accessibility of the SFZ format for non-technically minded sample library devs, who are more used to the drag and drop functionality of some commercial alternatives.

I guess also backward compatibility with the way Sforzando handles SFZ might be important, when most SFZ libs out there where created with Sforzando in mind (thats at least my impression)?

To me personally the updated Logic Sampler (formerly EXS24) embodies the perfect balance between ease of use and tweakability regarding multisampling (opposed to more slice, pitch and stretch style "creative sampling" with one singular audio sample as in Ableton Simpler, Logic Quicksampler or Serato Sample).

And I agree with you that the ability to route sounds / key ranges to different outputs could be great for drum / percussion related sample libs. For drums / percussion programming I still tend to prefer specialised drum sampler plugins, like the latest edition of Sitala over multisample playback engines like Kontakt or Sforzando, since the former are more suitable for the workflow, unless you really just need to playback a premapped drumset. Eg when I want to eg tune one particular sound by a few semitones, its often not possible in multisamplers without having to click through menus or even having to edit a text file. Your SFZ drum mappings are the rare exception, since you cleverly implemented direct access to the parameters.

The disadvantage of most drum-focussed sample engines: they often lack the more advanced multi-velocity and round-robin capability of multisample engines. Hence, ideally in Sfizz (can I dream please?) there would be a normal multisampler and also a drum specialised mode inside the same plugin. When you work with drum material, you can switch to a paradigm more appropriate to note & velocity map, tune, ADSR and layer drum sounds (create or playback drumsets), while the standard mode is more geared towards melodic multisamples..

Sorry for the wall of text, I hope at least some useful ideas are contained inside.

[kinwie]

Hi Kazi7, good to see you!

I'm also curious about the advantages over simply using Sforzando, which to me is the standard playback engine for SFZ mapped sample sets?

At some level, there are lots of new features can be added to a new SFZ player to shape the sounds (especially acoustic instruments) much better and proper. For example, for me personally, actually we still less one more "choke-group opcodes-set" to make an acoustic drums sounded "more acoustic". Current mappings mostly workaround, not a proper solution. So those new things might be easier happened in sfizz. While sforzando is not much improved in a decade.

I guess also backward compatibility with the way Sforzando handles SFZ might be important, when most SFZ libs out there where created with Sforzando in mind (thats at least my impression)?

This point has been taken seriously by the devs from the start. For example, some detailed things also followed Aria/sforzando's math, like curve calculation etc. But some better implementation also created when it necessary. So the compatibility won't be an issue I hope so.


Yeah, your post is full of great ideas which I would like to see also one day soon.
From what I understand from the dev's goal, is to first finished a good quality full-featured SFZ engine that can be used by anybody to build a new sampler.
What in sfizz as SFZ player is a more generic type one.
So then, let's say. the dev or other people build a Sitala-like Drums sampler, or a Multi-timbral Sampletank-like GM player, or a BFD-like drums player, or like you said, a sampler with integrated sample-mapper with drag and drop, or etc, etc, etc..
There're already stuff like that available, but simple ones. Paul Fd himself already built a BeatBox mobile Drum machine, or an user has built a simple sample player named Drops, over sfizz engine.
That's how the ideas will go AFAIK...
Many things can be made with it in the future..

[pljones]

Part of the reason SFZ v1 and SFZ v2 are distinct is that certain features in SFZ v2 behave differently from how they did in v1 - i.e. it's not backwards compatible in those areas. One is mute groups. Because of that, v2 is not just an extension to v1, it's a new version. So sfizz needs to decide -- are you implementing v2 or writing v3? If you're implementing v2 -- okay, with extensions -- then existing v2 behaviour must not change. As far as I'm aware, except where expressly "not in the standard for v2", Cakewalk and Plogue implementations have been compatible (I could well be wrong...). Both v1 and v2 expressly only defined minimal implementations but they made that behaviour clear (with some help...). Not all samplers claiming v1 or v2 compatibility achieve this, though. But to take existing features and explicitly say you do not match either v1 or v2 means you're choosing to make something new.

Not wrong, but just don't say it's "v2" when it isn't .

[kinwie]

Part of the reason SFZ v1 and SFZ v2 are distinct is that certain features in SFZ v2 behave differently from how they did in v1 - i.e. it's not backwards compatible in those areas. One is mute groups. Because of that, v2 is not just an extension to v1, it's a new version. So sfizz needs to decide -- are you implementing v2 or writing v3? If you're implementing v2 -- okay, with extensions -- then existing v2 behaviour must not change. As far as I'm aware, except where expressly "not in the standard for v2", Cakewalk and Plogue implementations have been compatible (I could well be wrong...). Both v1 and v2 expressly only defined minimal implementations but they made that behaviour clear (with some help...). Not all samplers claiming v1 or v2 compatibility achieve this, though. But to take existing features and explicitly say you do not match either v1 or v2 means you're choosing to make something new.

Not wrong, but just don't say it's "v2" when it isn't .

Okay, first let's talk about Choking behavior.
- Sforzando did one behavior that it self-muting when the number of group= and off_by is the same. This kind of behavior is also common used by eg. Kontakt V1, NN-XT V3, DirectWave, AIR Structure, etc..
- Rgc sfz (v1), Dimension , Rapture and DropZone (v2) did another behavior that it won't be self-muting which means the region is polyphonic. This kind of behavior is also used by Sampletank, Samplelord, Kontakt V2+, etc..

The specs never explicitly instruct how's the "official" sfz muting should be done!
Both of that are their implementation that different and not part of the sfz v1 or v2 official specs like you mean to
sfizz took the middle way so it capable to do both. It's not about version 1 or 2 or 3.

The specs only said a little regarding behaviors for some opcodes.
Lot of implementations even in Aria/sforzando was David's own tricks. Lot of great tricks, but also some not-nice ones.
Compare if you want to make sure, between Dimension and sforzando to list their differences.

Please point me to the official source that said v2 has to do self-muting or not...

[kinwie]

In this regards, the devs always have to make a choice, wheteher to use official Cakewalk or ARIA implementations and also consider what will the better one for many cases.
So some are following Cakewalk, some are the middle way and most of it follow what ARIA did.
But for this Choke behavior, middle way is the best way for sfizz.
And if we add these new ones : choke_group=, choke_by=, choke_time=, etc.. then we are golden..

[kinwie]

If you guys tried sfizz and found issues and like to contribute a report for it, please post it here :
https://github.com/sfztools/sfizz/issues

[kinwie]

Current version not yet has the CC, but next version should..

Untitled.jpg

[slangbein]

great; looking forward. Using sfizz with Linux Mint and Carla

[kinwie]

One nice and useful version 2 opcode that never supported in other players, but yes in sfizz is : loop_crossfade
It's in seconds unit, like, loop_crossfade=0.02 (Crossfading loop for 20 ms)

[kinwie]

Oscillator opcodes and the <effect> also already implemented in sfizz. So, beside as a sample playback engine, sfizz can also act as a fully capable synth