SFZ format documentation

[DSmolken]

Mostly, yeah, though there are players that only support parts of SFZ1, and Sforzando doesn't support all V2 opcodes - there's some stuff that was only used in a few Cakewalk products, like effect-specific controls which Plogue implemented in a different way. So, adding another table would give us a better overview over what, say, BassMIDI supports, which is apparently the player of choice of people trying to use SFZ on Android phones. And Zampler, Bliss and everything else.

[discoDSP]

Thanks for pointing up.

[redtide]

For anyone that would like to keep in touch and share some ideas we have also a Discord chat.

[JeffLearman]

Nice. Where I can contribute with Bliss sampler supported SFZ opcodes?

An option would be to add them on our wiki, which could be a start point as some sandbox for a later better solution, but it would require that all player developers to use it.
The most simple way would be to add a page on your website that we could link to from our list of players page.

What does it take to be able to edit that page? I have a github account but it's not editable. Of course, we can fork the repo, modify, and do a pull request, but then what's the point of a Wiki?

[JeffLearman]

Having a database or table with opcodes supported by every SFZ software would be nice.

We have that table already: https://sfzformat.com/opcodes/

Afaik this is the most detailed table of sfz-opcodes, and if you
look the right column you can see the version of every opcode.

sfz version 1 works with pretty much all sfz players (or at least
it should!)

sfz version 2, on the other hand, works with what is probably
the most advanced sfz player, the Plogue Sforzando.

Not really the same thing, because different players support different subsets of sfz v2, and also different subsets of various extensions. For example, I believe other players support some of the Aria extensions. What would be great is a table like that but including all the main players. It'd be a lot of work to put it together, but a lot of the knowledge is already out there. (The table would need to have three states for each player: yes, no, and unknown, and hopefully the number of unknowns would diminish over time.)

[redtide]

What does it take to be able to edit that page? I have a github account but it's not editable. Of course, we can fork the repo, modify, and do a pull request, but then what's the point of a Wiki?

A wiki on Github can be set as public where any registered user can modify it (by unticking "Restrict editing to collaborators only" in settings), just like Wikipedia. That would be the simplest way to let people add information without complexity of YAML files and Pull Requests.

It'd be a lot of work to put it together, but a lot of the knowledge is already out there. (The table would need to have three states for each player: yes, no, and unknown, and hopefully the number of unknowns would diminish over time.)

I did already that work, which I posted yesterday, it's not that big thing to do using YAML files, the problem is to keep them updated (maintenance) other than explain how to handle it to anyone would like to keep it updated. You can just list the supported opcodes without listing them all for each player.

[kinwie]

basenote sounds like a custom opcode.

It applies to root key.

Yes! it should be pitch_keycenter alias :

Code: Select all

rootkey=

[enroe]

sfz version 1 works with pretty much all sfz players (or at least
it should!)

sfz version 2, on the other hand, works with what is probably
the most advanced sfz player, the Plogue Sforzando.

Not really the same thing, because different players support different subsets of sfz v2, and also different subsets of various extensions. For example, I believe other players support some of the Aria extensions.

This is exactly true when you go into the details!

For people who are newcomers to the sfz format and want to learn the basics
first, such details are rather daunting! Therefore, a rough distinction between
sfz version 1 and sfz version 2 is initially simple and clear.

But I agree with you overall:

What would be great is a table like that but including all the main players. It'd be a lot of work to put it together, but a lot of the knowledge is already out there. (The table would need to have three states for each player: yes, no, and unknown, and hopefully the number of unknowns would diminish over time.)

If you need it in more detail, but only then, there should be such a
detailed table. That would of course be great if someone could do
the work - primarily on "sfzformat.com".

[kinwie]

Idea for SFZ development, post yours...
https://github.com/sfz/opcode-suggestions/issues

[DSmolken]

https://sfzformat.com/tutorials/range_extension

Added a simple tutorial about range extension.

Been thinking about doing one on guitar feedback, since I've implemented that in a few instruments now. Would there be interest, or is that too niche? Perhaps even too Nietzsche, sometimes when you sustain a note too long, the note also sustains you...

[enroe]

https://sfzformat.com/tutorials/range_extension

Added a simple tutorial about range extension.

Been thinking about doing one on guitar feedback, since I've implemented that in a few instruments now. Would there be interest, or is that too niche? Perhaps even too Nietzsche, sometimes when you sustain a note too long, the note also sustains you...

I think that everyone who creates his own multisamples always comes to the
question "How big will I do the range?" In this respect, you give very helpful
ideas in your tutorial.

However, every range extension depends on the samples themselves: Does it still
sound good? Or should I avoid such extreme transpositions? Or does a "round-robin
extension" help?