SFZ import - root key works, but no hikey or lokey in end result (missing samples?)

[andioak]

I´m trying to import from SFZ into a sampler. It recognises the groups, the root keys via key=, but the full mapping of the keys are ignored. The values come from the sfz opcode lokey= and hikey=, respectively.

Here´s my SFZ contents:

<group> locc64=64 hicc64=127        // pedal-on-f
<region> sample=samples/A#-1-pon-f-1-free-ed.wav key=22 lokey=21 hikey=23 lovel=110 hivel=127 volume=4 loop_mode=no_loop
<region> sample=samples/C0-pon-f-1-free-ed.wav key=24 lokey=24 hikey=25 lovel=110 hivel=127 volume=3 loop_mode=no_loop
<region> sample=samples/D#0-pon-f-1-free-ed.wav key=27 lokey=26 hikey=28 lovel=110 hivel=127 volume=2 loop_mode=no_loop
<region> sample=samples/F0-pon-f-1-free-ed.wav key=29 lokey=29 hikey=31 lovel=110 hivel=127 volume=2 loop_mode=no_loop
<region> sample=samples/A0-pon-f-1-free-ed.wav key=33 lokey=32 hikey=34 lovel=110 hivel=127 volume=2 loop_mode=no_loop
<region> sample=samples/B0-pon-f-1-free-ed.wav key=35 lokey=35 hikey=36 lovel=110 hivel=127 volume=2 loop_mode=no_loop
<region> sample=samples/D1-pon-f-1-free-ed.wav key=38 lokey=37 hikey=38 lovel=110 hivel=127 volume=2 loop_mode=no_loop
<region> sample=samples/E1-pon-f-1-free-ed.wav key=40 lokey=39 hikey=40 lovel=110 hivel=127 volume=4 loop_mode=no_loop

Here I cleaned up the sfz file by removing all comments and global vars it had in the beginning. I also renamed it to a shorter name because a longer name makes HISE crash immediately.

Below, you can see that HISE has ignored the above mentioned opcodes for hi-key and lo-key mappings, nor a file-name:

It seems that it hasn´t found the samples. The samples are in PROJECT-FOLDER/Samples/samples/, like so:

So the path is correct: samples=samples/file-name.wav

What am I missing??

My specs: MacOS 10.13, HISE scriptnode (2020-08-22)

[andioak]

I have experienced around 20+ HISE crashes while trying to discern the issue here. I added other instruments and found some that would indeed be imported via the SFZ importer, and mimicked their structure and opcodes.

The structure I have myself:

<region> sample=samples/A#-1-pon-f-1-free-ed.wav key=22 lokey=21 hikey=23 lovel=110 hivel=127 volume=4 loop_mode=no_loop

Crashes HISE every time.

The other SFZ instrument I tried has this structure (by structure I mean the succession of opcodes in each line):

<group>

<region> sample=anotherfolder/C0-poff-f-1-free-ed.wav lokey=24 hikey=25 lovel=110 hivel=127 pitch_keycenter=24
<region> sample=anotherfolder/D#0-poff-f-1-free-ed.wav lokey=26 hikey=28 lovel=110 hivel=127 pitch_keycenter=27

So that instrument loads fine, but the one I have above is only crashing HISE. Why?

TXT file encoding? Some bug I should know about?

[Lindon]

@andioak said in SFZ import - root key works, but no hikey or lokey in end result (missing samples?):

pitch_keycenter=

is it because your example doesn't have "pitch_keycenter=" , which I think is like rootKey for HISE, - so HISE doesnt know where to put the sample?

Yours has "key=" which might not map correctly? Try swapping these around

[Christoph Hart]

Yeah, I never read the (hardly existing) SFZ specs, so it's definitely not a 100% compliant SFZ parser. It just happens to accept the SFZ files that the Chicken Translator NKI2SFZ converter spits out...

[andioak]

@Lindon said in SFZ import - root key works, but no hikey or lokey in end result (missing samples?):

@andioak said in SFZ import - root key works, but no hikey or lokey in end result (missing samples?):

pitch_keycenter=

is it because your example doesn't have "pitch_keycenter=" , which I think is like rootKey for HISE, - so HISE doesnt know where to put the sample?

Yours has "key=" which might not map correctly? Try swapping these around

Correct, in that the key root center token is very specific. But in the HISE docs here, you can read that the tokens included and parsed by the HISE SFZ importer are:

sample, lokey, hikey, lovel, hivel, offset, end, loop_mode, loopstart, loopend, tune, pitch_keycenter, volume, group_volume, pan, groupName, key

So both pitch_keycenter= and key= is supported, along with the rest of all the tokens of the sfz files I´ve tried. Most trials of which immediately crash HISE. No real red thread except for that two files that are identical that I tried are instigating different behaviour. Suggesting I might have a txt encoding error on my hands . Or something else.

The most of the times I could actually import an SFZ file, either of these things happened:

• sfz file imports but file names are entirelly missing, including file paths. But I see "sample cells" present on the mapping editor surface.
• sfz file imports but file names are missing but path and file name shows up in the sample table, but showing the file as path/last-folder\filename.wav as the end folder, with missing file still. This is due to the windows saved files containing "\" (backslash) instead of "/" as the ultimate parent folder of the sound file.

In all (non crash) cases the ...

<control>
default_path=Samples/

... that governs the relative (and most effective and very important) path to the files, never once got read and thus forced me to add (by search/replace) the relative path to all sample= references in the SFZ files, like so: sample="sub-folder/file.wav".

That´s a small deal to do if it had worked, but doesn´t HISE read the default_path=? It should. The token is hard not to find at the top of any sfz file. Also, I´d think it would be substituted simply by {PROJECT_FOLDER}.

Just to be clear, I managed to use the normal sample mapper and it performs well at import. But the big problem when viewing the samples (in the sampler table) is that the sample table is not showing me the entire file name, it strips away things at the end, most times the entire file name, because the path is included, which in itself makes less than sense. I think. It would be better to have path and filename separate. So we could align them according to their location as well, right? But that´s another discussion. However the thing about not being able to see the text at all, is not. That´s kind of a part of HISE´s core functionalities.

As stated above, I´m using scriptnode branch at 2020-08-22, latest commit at that time, if that matters.

@Christoph-Hart said in SFZ import - root key works, but no hikey or lokey in end result (missing samples?):

not a 100% compliant SFZ parser. It just happens to accept the SFZ files that the Chicken Translator NKI2SFZ converter spits out...

I think referencing a paid application that costs not that little money is the wrong way to go, here. Not that that app is not delicious in all it could give me apart from that, given I get the full Translator .

Additionally, the reason for me wanting to use SFZ is the very cumbersome work of getting these right: lokey & hikey. They have been worked out specifically for all instruments and tried and re-tried in other formats, for me, EXS24. I used the free windows app EXS2SFZ to spit out my files. It worked perfectly and loaded fine in Sforzando.

So the other aspects might be programmable, but not that one, that was instead made by hand by playing and reflecting. All people with lots of small instruments of little value on their own but perhaps lots of value as a collection, could be benefited greatly if the SFZ importer did a more consistent job.

@Christoph-Hart:

I never read the (hardly existing) SFZ specs...

When you started this fenomenal project, the docs might have been much worse than of late: https://sfzformat.com/opcodes/

[d.healey]

Looks like your samples have the note names and dynamics container in the file name, why not just use the HISE automapper?

[andioak]

@d-healey said in SFZ import - root key works, but no hikey or lokey in end result (missing samples?):

Looks like your samples have the note names and dynamics container in the file name, why not just use the HISE automapper?

I did, and it works, but the hinote / lownote are already pre-mapped in EXS and I use multiple formats, beginning with EXS/Kontakt. That will not change and so the changes to files will be imported upon changes to those formats. So the sfz is going to be important upon updates to values/volume changes and mapping differences. Nothing that will not be able to be manually entered, naturally, but preferably not.

[d.healey]

HISE has a one click button to fill the gaps between the notes, will that not work for your case?

[andioak]

@d-healey No, not for my current instrument, I have gone through it manually as some notes really sound much worse pitched down as opposed to up, but that´s individual in different samplers as well of course. The feature is great of course, if I started in HISE I would not care. Also, the importer should just work, it´s not complicated if you take into account all the other fantastic features of this project and the complexities in those.

With an eye on the fact that I might have created this entire issue, with some error in encoding in my text files.

[d.healey]

@andioak Ah I see the issue. I think you're out of a luck with the current SFZ importer implementation then.

[andioak]

@d-healey said in SFZ import - root key works, but no hikey or lokey in end result (missing samples?):

@andioak Ah I see the issue. I think you're out of a luck with the current SFZ importer implementation then.

That´s why I am now half-way through the creation of a Javascript/HTML page that converts it and spits out a HISE samplemap. If I can make it work it will use all of the opcodes supported in the HISE docs, and give you the code in a web page alongside spitting it out in a .xml file that you "should" be able to import with no issues into HISE.

The question marks will be the HISE specific codes, Duplicate="" and some other aspects and potential pitfalls. But it´s a bit fuzzy as I am not that great of a JS coder yet. But i´m using ES5/6 that will just take a file from a web file chooser (input form field), or a drag/drop and spit out the code. If the opcodes are valid, of course.

I´ll post the result in the Snippet-section and you can all grill it till its dead, or bug-fixed.

@Christoph-Hart @Lindon

[d.healey]

@andioak Don't fancy tackling it on the C++ side?

[andioak]

@d-healey said in SFZ import - root key works, but no hikey or lokey in end result (missing samples?):

@andioak Don't fancy tackling it on the C++ side?

Never wrote a line of C++ code, but perhaps my functions can be translated directly after, but this is very convenient if it can work. It will just be a folder you run a html-page from in any up-to-date (HTML5+) web browser that then gives you a .xml file. It´s a simple search/replace in JS function. Still, of course I´d like to say my skills are up to par with a C++ component, sadly, they are far from it. But I´ll get up on github for all to wrangle.

Current problems: relative vs absolute paths (I´m thinking just a form you fill in yourself that is placed into the paths). Duplicate=, which is?? On Christoph now for some details.