SynthFont.com

Hello Kenneth! It's been a while since we last talked...
Today I checked out your website after a few months, and I noticed that you released a x64 version of SynthFont2, which got me intrigued.
I tested its loading capabilities and it's so nice to see it load 40-50 million notes without crashing!

There's one problem though... Everytime I try to load my B-211 sound bank, it doesn't seem to load any sample.
Does SynthFont2 support relative paths for the samples?

Any SFZ-complaint player has to follow the SFZ standard, and one of the basic requirements is to have native support for relative paths when loading a SFZ file.
If you want to test it by yourself, you can download B-211 from here: https://github.com/KaleidonKep99/Steinw ... master.zip

Hi there!
Long time mo see...
I guess it is a problem related to the path, but I will investigate in more details at a later moment. Right now occupied with my VST instrument VSTSynthFont (of which there is a 54 bit version as well...).

The major issue seems to be the use of this construct:
//SINC - BEGINNING OF INCLUDE SECTION

#include "Extensions/ECO/1960 Steinway B-211.key"

//EINC - END OF INCLUDE SECTION

This doesn't seem to be a documented feature? Clever, though.

Admin wrote: ↑Wed Jun 05, 2019 3:11 pm The major issue seems to be the use of this construct:
//SINC - BEGINNING OF INCLUDE SECTION

#include "Extensions/ECO/1960 Steinway B-211.key"

//EINC - END OF INCLUDE SECTION

This doesn't seem to be a documented feature? Clever, though.

I tried an older version of my SFZ that didn't use the #include feature (Which is part of SFZ 3.0 afaik), and it still refuses to load the samples.
You can find the old presets in the "Outdated presets" folder.

Great. I'll try it. I will soon release a new version of my VST plugin (with support for multiple CPU threads - should have done this years ago) and after that I'll continue to work on SynthFont2. But I have only this week left before summer vacation which will be o v e r l y long this year...

<control>
hint_ram_based=1

"hint_ram_based" is not a standard command. Remove the line and try again.

There is one other issue I find slightly problematic. The document from Cakewalk (here: http://www.synthfont.com/Cakewalk_sfz.pdf - the only one I have) says this.

Opcodes within a region can appear in any order, and they have to be separated by one or more spaces or tabulation controls. Opcodes can appear in separated lines within a region.

I have assumed that this is valid for <group> and <control> also. This means that no spaces (or tabs) are allowed within an opcode definition. Hence, this is not allowed:

<control>
label_cc14=Piano volume
label_cc15=Hammers volume
label_cc20=Pedal volume
label_cc64=Damper pedal

It should be coded like this:

<control>
label_cc14=Piano_volume
label_cc15=Hammers_volume
label_cc20=Pedal_volume
label_cc64=Damper_pedal

Strictly speaking...

Personally I find this original specification quite strange and not very clever at all, but who am I to say. SFZ is an open format, which is both good and bad.

Admin wrote: ↑Mon Jun 10, 2019 2:34 pm

<control>
hint_ram_based=1

"hint_ram_based" is not a standard command. Remove the line and try again.

Unrecognized opcodes should be ignored, so it's not a big deal.

Admin wrote: ↑Mon Jun 10, 2019 6:49 pm There is one other issue I find slightly problematic. The document from Cakewalk (here: http://www.synthfont.com/Cakewalk_sfz.pdf - the only one I have) says this.

Opcodes within a region can appear in any order, and they have to be separated by one or more spaces or tabulation controls. Opcodes can appear in separated lines within a region.

I have assumed that this is valid for <group> and <control> also. This means that no spaces (or tabs) are allowed within an opcode definition. Hence, this is not allowed:

<control>
label_cc14=Piano volume
label_cc15=Hammers volume
label_cc20=Pedal volume
label_cc64=Damper pedal

It should be coded like this:

<control>
label_cc14=Piano_volume
label_cc15=Hammers_volume
label_cc20=Pedal_volume
label_cc64=Damper_pedal

Strictly speaking...

Personally I find this original specification quite strange and not very clever at all, but who am I to say. SFZ is an open format, which is both good and bad.

Spaces ARE allowed for labels actually...
The original documentation is outdated and should not be followed anymore.


You should take a look at the latest documentation from ARIA: http://ariaengine.com/overview/sfz-format/

This first "problem" (unknown opcode) is of course the only bug I have found in the code so far. There is a code snippet supposed to remove unknown opcodes but it didn't work. Fixed now and will work in next version.

I have looked at the site you referred to but I must be blind - I cannot actually find a document that specifies the new SFZ format. I found two files to download: csfptpu-v2-downloads.zip and cs2-z2-update.zip but neither one seems to contain any specifications. The "Unofficial SFZ format information" doesn't say much. Please help me out here with a another link - or if you just simply can upload a PDF with the new specs would be even better.

Admin wrote: ↑Thu Jun 13, 2019 8:39 am This first "problem" (unknown opcode) is of course the only bug I have found in the code so far. There is a code snippet supposed to remove unknown opcodes but it didn't work. Fixed now and will work in next version.

I have looked at the site you referred to but I must be blind - I cannot actually find a document that specifies the new SFZ format. I found two files to download: csfptpu-v2-downloads.zip and cs2-z2-update.zip but neither one seems to contain any specifications. The "Unofficial SFZ format information" doesn't say much. Please help me out here with a another link - or if you just simply can upload a PDF with the new specs would be even better.

The documentation for SFZ 2.0 should be in Chapter 13 of Cakewalk's package. (csfptpu-v2-downloads.zip)
There's also more stuff here: http://drealm.info/sfz/plj-sfz.xhtml