Topic: BASS_MIDI and SFZ files

[andrelubke]

It is probably a lot to ask,
but is it a possibility that BASS_MIDI in the future could read SFZ files as well?
SFZ files ar basically a text discription file and a bunch of separate wave files.
This would greatly enhance the possibillities of the BASS_MIDI library.

André

[andrelubke]

It is probably a lot to ask,
but is it a possibility that BASS_MIDI in the future could read SFZ files as well?

Now I am thinking about it,
To make it easier: BASS_MIDI could have only the possibility to load separate 'wav' files and map them to one or more MIDI-notes. That way the parsing of the SFZ text file (or any other file) could be left to the programmer and that would make it even more flexible.

In this way BASS_MIDI could easlily be used as the base for making a midi sampler.

Well, just an idea.
Hope this fits in your future BASS_MIDI plans

Gr. André

[Ian @ un4seen]

There are no immediate plans for SFZ support (it won't be in the upcoming release), but perhaps something for a future release

How widespread in the SFZ format, eg. are there any publicly available collections?

[andrelubke]

There are no immediate plans for SFZ support (it won't be in the upcoming release), but perhaps something for a future release
How widespread in the SFZ format, eg. are there any publicly available collections?

Well, cakewalk 'invented' the SFZ format, but until now there are not that many I believe.
The advantage of sfz is that it is non-monolithic. It is a collection of separate wave (or ogg) files with a text file describing the notes and other midi properties like velocity etc.
http://www.cakewalk.com/DevXchange/article.aspx?aid=108.
(Actually an sf2 file is as you know about the same, but then it is all packed in one file).
I just thougt it would give some more flexibility if BASSMIDI allowe to load separate wave/ogg (whatever files) with the possibility to map them to midi-keynotes and other midi events.
So actually it doesn't have to be SFZ format, because a programmer could then make up his own description (or indeed parse an SFZ file) and map the wav files accordingly. Probably you already have these low-level functions in BASSMIDI already (to read sf2 files). Publishing these functions in some kind of form in the DLL would be nice . BASSMIDI could be turned into a very flexible sound sampler then. Probably all this stuff can be done with BASS.DLL (reading xxx wav files in xxx channels and writing own midi-in events for each channel). But since such a mechanism is already under the hood in BASSMIDI I thought that would be more practical.
Anyway, just a thought.
Gr. André

[Ian @ un4seen]

Yes, the ability to use individual instruments/samples without having to create an SF2 file does sound like a nice idea. There can be quite a lot of information associated with an instrument though, and it would probably be impractical to include support for all of that via function call parameters, so I think it is likely to need some file format (like SFZ) to contain the information. I'll look into it after the next BASSMIDI release.

[andrelubke]

Thanks Ian,
That sounds great!
Looking forward to it

[donatopace]

Hello, to all member of this site.

I play Music with VANBASCO karaoke player + VIRTUALMIDISYNTH (support *.sf2 sound fonts).
The author of VirtualModoSynth will add support o *.sfz sound fonts but it is necessary that "BASS_MIDI read SFZ files",
when BASS_MIDI will read SFZ files" ?

Thanks a lot.

[kinwie]

@Ian,

I've made a conversion of Fluid R3 GM soundfont as SFZ GM bank here if you are interested to take a look at it :
https://www.dropbox.com/sh/4ydmh512nummp0h/AAAMHOwnodwHBXUOIzwcPuc8a/Fluid_R3_GM_SFZ_full_bank.rar

Each instrument presets are easily reproduce as single sfz instrument using open standard SFZ version 1.0 opcodes/commands. But to make the SFZ bank version (so the sfz can be function like sf2 bank), it needs some SFZ version 2.0 opcodes which is not public yet (but can be found on some sfz site). The Fluid SFZ bank of mine also uses some ARIA extension which are custom opcodes belongs to ARIA Engine maker.

I just want to let you know, I'm happily and ready to help for the SFZ format.

[Ian @ un4seen]

Thanks for that. I looked into SFZ support a while ago, but unfortunately it didn't get very far. I don't recall now exactly why it didn't progress further, but I think there were some issues mapping the SFZ stuff to SF2, which is basically what SFZ support would involve, ie. translating the SFZ stuff for the existing SF2-based engine. Perhaps it was the SFZ 1.0 limitations you mention. As you appear to have converted an SF2 to SFZ, I guess the reverse should also be possible and perhaps it's worth another look

[kinwie]

Actually, the idea of sfz was derived from sf2 (stated by the creator himself, Rene) where in the public version 1.0 format covered all sf2 parameters/generators plus some more advanced opcodes. Only the program/bank changes not yet included at that time. So to me, I see them just like brother and sister.

The reverse that you said, SFZ > SF2, of course possibly done. Many format converters are able to do that. And for a free/native sf2 editor choice, there is Polyphone which i participated as contributor (mainly for the sfz stuff).
For example, the sf2 test file that I've sent you before actually was created from sfz and saved as sf2 using Polyphone. It was originally a soundfont but i have all my sf2 archived as sfz
So far, conversion/mapping things between sf2 > sfz > sf2 by Polyphone is great, only with the exception that parameter which doesn't have counterpart in both format will be ignored (limitation).

I think if user want to use sfz instrument in BASS or VirtualMIDISynth, it can be done really easy using Polyphone. Only two steps, just open the sfz file and save as sf2.
Well, as BASS and VMS user, this option is enough for me.
I agree if you stick as SF2-based engine. It's only format matter and they only different in "2" and "z"

p.s.
As sfz and sf2 now also support 24-bit samples, i haven't test them in BASS/VMS. Is it supported already?

[Ian @ un4seen]

BASSMIDI doesn't currently support 24-bit samples. 24-bit SF2 files are back-compatible though, allowing the most significant 16 bits of the sample data to still be played.

[Ian @ un4seen]

Regarding SFZ support, work on implementing that has resumed. SFZ does have some features that aren't supported by SF2, so there will be some SFZ opcodes that aren't fully supported, but it looks like it should be fine in the main. If any of the missing stuff turns out to be important, then perhaps support for it can be added later. Only individual SFZ files will be supported initially, so an SFZ file would need to be assigned to a particular preset rather than entire banks.

I think there should be something ready for testing this week. The SFZ support is actually being implemented in the XMPlay MIDI plugin (rather than BASSMIDI) first, as XMPlay provides a ready testbed for it. So if you're willing to test with XMPlay, you can probably get something to try sooner

[kinwie]

Sure, will happy to do it

[Ian @ un4seen]

OK. The updated XMPlay plugin is now available for testing, here:

   https://www.un4seen.com/forum/?topic=5337.msg109923#msg109923

Please give that a try and report your findings.

[kinwie]

i just tried a bit with single drums and piano midi track, so far things load fine and sounds okay
i'm not yet perform a detailed test but i've noticed that the pan is wider than it should,
probably because SF2 use -50/50 pan value versus SFZ use -100/100 value?

i'll do more in-depth test but i'm a bit annoyed by the reverb, which i'm pretty sure it's always on even i can see the 'reverb tick box' is un-ticked.

can you please tell me how to turn it off, so i can hear a real dry sound?
also, how can i override the midi's channel/preset number in XMplay so it can always go to e.g. channel-1 preset-000?
this is the 2nd time i run XMplay so please forgive me for my lack experience of it.
thanks...

(i test with the fluid gm sfz that i made)

[Ian @ un4seen]

You're right about the panning. An update to correct that is now up at the same URL.

Regarding reverb, if the "reverb & chorus" switch is off (or the reverb level slider is set to off), then there will be no reverb applied, so it's strange that you're still hearing some reverb. Are you getting it with all SFZ files or only specific ones? If the latter, perhaps the reverb is present in the samples themselves? I guess another thing that could sound like reverb is an amp EG with a long release phase? If the reverb is still a mystery, please provide an example SFZ file to have a look at.

Unfortunately, the XMPlay MIDI plugin doesn't currently provide any way of overriding the presets used by a MIDI file. Although not as convenient as an override switch, what you could do for now is assign a different SFZ file to the preset that you want to override in the plugin's config.

[kinwie]

achhh..it's my bad
after you mention the 'reverb & chorus', i try to look for that switch, and i found it, it's in the Mixer section. The "un-ticked reverb" i saw was on the DSP section. I can have my dry sound now, thanks (really embarassed )

yeah, i just realize, XMplay is not midi sequencer but a player. I assign like the way you suggested for some midi files while testing.

I'm testing those opcodes currently supported, will return to report of this.

But at this moment i mention this first ;
the "fil_veltrack" works fine, so why not include the "amp_veltrack" also? It's very often used
Continue to the previous sf2 test file that i've sent to you, i just upload the source file : Prophet_FATCAT_APS_SFZ
to the ftp link. There is 'amp_veltrack' used in that sfz file (amp-veltrack=0)

Most sfz files (version 1.0) are load fine, i'm really impressed!
only found one sfz file that unable to load, will send it to you later
and will get back here reporting soon...

[kinwie]

my opcode testing, all the currently supported opcode here :
https://www.un4seen.com/forum/?topic=5337.msg109923#msg109923

- from the first opcode (sample=) till "pitcheg_xxx" / "fileg_xxx" and the "Round-Robin" (seq_length, seq_position) are working fine
- LFOs (pitchlfo/fillfo/amplfo) seems not yet properly working
- i don't test the effect1 & effect2 opcodes cause i remove them from all of my sfz files
- as the Key to hold/decay of SF2 already implemented, its sfz equivalent maybe can be added, but i'll explain about this later.

This is regarding the loop point behavior between SF2 and SFZ
- SF2 use exclusive loop point value
- SFZ use inclusive (the loop_end is lesser 1 value) > this is not clearly stated in the official sfz v1.0 spec but have been explained/discussed at other forum

So the case is, if the loop points are defined within the samples then it's probably no any problem but when they're defined within the sfz files then 'inclusive' should be the correct one.
I send you a test file (sfz_loop_point.rar) that shows BASS use exclusive loop for the sfz (the 'exclusive sfz file' sounds no buzzing). This case also applied to the "end=" opcode

Another file (GD_SS1_invalid.rar) is the failed sfz. The error message said it is not a valid sfz, but i don't know what's the problem is. It's a valid one and has been tested in other players.

That's all i found so far...

[Ian @ un4seen]

Thanks for the loop/end-point clarification and other bug reports. An updated plugin for you to try is now up at the usual place. It should correct the loop/end-point stuff and fix the LFO (freq setting wasn't processed properly) and fix the SFZ file verification (to accept the Session Set 1 SFZ file). It also adds support for the amp_veltrack opcode, and pitch_veltrack too for velocity tracking completeness. Let me know if you spot anything else.

[QuentinC]

Yes, the ability to use individual instruments/samples without having to create an SF2 file does sound like a nice idea. There can be quite a lot of information
associated with an instrument though, and it would probably be impractical to include support for all of that via function call parameters, so I think
it is likely to need some file format (like SFZ) to contain the information. I'll look into it after the next BASSMIDI release.

Perhaps you don't need so much new functions. It could be nice, wheither or not you are going to support other bank formats such as SFZ, to be able to quickly load some samples from a couple sound files.

We could imagine limit sample loading facility to something like this :

1. HINSTRUMENT BASS_MIDI_InstrumentCreate(DWORD bank, DWORD program);
I think it should be clear enough what it does

2. BOOL BASS_MIDI_InstrumentAddSample(HINSTRUMENT instrument, DWORD handle, DWORD nSF2Generators, DWORD* sf2Generators);
Where handle would be a HSTREAM or HSAMPLE so that we can just load samples from any format supported, compressed or not (just reuse one of the great BASS powers whenever we can !). Using the generator list it's probably easy enough to set base note, loop points, volume, envelopes, key/velocity range where the sample applies, etc.
As a bonus, a flag to pass a file name unstead of an handle.
As a second bonus, a special generator to pass instrument name (might be useful)

3. Update BASS_MIDI_StreamSetFonts to be able to pass indifferently HINSTRUMENTS and HSOUNDFONT in BASS_MIDI_FONT(EX) structure.

And I think that's all ! Probably no need to add functions to modify the parameters after creation.

[kinwie]

Everything that has just been fixed and added, now working fine. Thanks for the 'amp_veltrack' it's great!
And yes! get one more bonus, the 'pitch_veltrack' which is very useful for percussion sounds.

I remember, this is the first sfz file that i saw using pitch_veltrack, Brad's Conga 1.0, still can be found here :
http://www.burtin.net/conga/

Related to that conga sfz, the samples it uses is ogg files. I tested it, loaded but no sounds. Same also for sfz with flac samples.
I supposed those two sample formats not yet supported.

Since, you have added the Key to Hold/Decay for the soundfont, i like to explain how it translated to sfz.
First, there is no existing/fixed sfz v1.0 opcodes for those two parameters, so they can be made by adding the keyboard tracking function to the correspond parameters.
In sfz format version 1.0, there are some Beta opcodes and extended CC that added by the creator (later becoming v2.0 standard), can be found here and here :
http://www.drealm.info/sfz/plj-sfz.xhtml#newCC
https://docs.google.com/document/d/1UxPar5toq2uDrU4Gkf4jOGzV3ic-CAoRPo0cWE6xino/pub

So, the keyboard tracking CC is number 133. The sf2's key to hold/decay becoming :
- ampeg_holdcc133= & ampeg_decaycc133=
- pitcheg/fileg_holdcc133= & pitcheg/fileg_decaycc133=
I send you two examples of piano sounds which use these opcodes, one is the Synthgms piano for a comparison to look at.

So far, all good to me. I don't spot anymore bugs or problems. Various structured sfz files (v1.0) are succesfully loaded. Tune beyond -100/100 cents working fine (which is better than limited). Opcode priority is fine too.

Hope others can give suggestion too. Really impressive works, thanks Ian!

[rv]

The next step is to get a BASSMIDI.dll with that

[Ian @ un4seen]

Yes, the ability to use individual instruments/samples without having to create an SF2 file does sound like a nice idea. There can be quite a lot of information
associated with an instrument though, and it would probably be impractical to include support for all of that via function call parameters, so I think
it is likely to need some file format (like SFZ) to contain the information. I'll look into it after the next BASSMIDI release.

Perhaps you don't need so much new functions. It could be nice, wheither or not you are going to support other bank formats such as SFZ, to be able to quickly load some samples from a couple sound files.
...

Each SFZ file actually defines a single instrument, so it should be possible to achieve what you want that way, eg. you could generate an SFZ file (perhaps in memory) and pass that to BASS_MIDI_FontInit, and then use the returned HSOUNDFONT handle in BASS_MIDI_StreamSetFonts calls. As an SFZ file defines a single instrument, they would need to be assigned to specific presets rather than entire banks in the BASS_MIDI_StreamSetFonts calls.

If you would like to see what options/opcodes SFZ has available, a list can be found here...

   www.sfzformat.com

Note that not all of them will be supported by BASSMIDI, at least not initially. A list of currently supported opcodes is in the XMPlay MIDI plugin thread.

Related to that conga sfz, the samples it uses is ogg files. I tested it, loaded but no sounds. Same also for sfz with flac samples.
I supposed those two sample formats not yet supported.

Yep, encoded samples aren't currently supported. I was thinking of adding support for them, but delays (from initializing the decoder and then decoding the sample data) are a concern as the samples are loaded on the fly; I'll have to check what sort of delays they introduce. BASSMIDI will include support for them though, as it has the option of pre-loading samples.

Since, you have added the Key to Hold/Decay for the soundfont, i like to explain how it translated to sfz.
First, there is no existing/fixed sfz v1.0 opcodes for those two parameters, so they can be made by adding the keyboard tracking function to the correspond parameters.
In sfz format version 1.0, there are some Beta opcodes and extended CC that added by the creator (later becoming v2.0 standard), can be found here and here :
http://www.drealm.info/sfz/plj-sfz.xhtml#newCC
https://docs.google.com/document/d/1UxPar5toq2uDrU4Gkf4jOGzV3ic-CAoRPo0cWE6xino/pub

So, the keyboard tracking CC is number 133. The sf2's key to hold/decay becoming :
- ampeg_holdcc133= & ampeg_decaycc133=
- pitcheg/fileg_holdcc133= & pitcheg/fileg_decaycc133=
I send you two examples of piano sounds which use these opcodes, one is the Synthgms piano for a comparison to look at.

I'm not really sure about supporting the "cc" opcodes. There are a lot of them, but they don't seem to be used very much at the moment, eg. Google-ing the aforementioned "cc133" opcodes gives no results. I think I'll leave them out for now, and perhaps reconsider later

The next step is to get a BASSMIDI.dll with that

I will try to have a BASSMIDI update available for testing later this week.

[kinwie]

no problem, thanks for the sfz

[Ian @ un4seen]

Here's the SFZ-supporting BASSMIDI update...

   www.un4seen.com/stuff/bassmidi.zip

It should have the same SFZ support as the XMPlay MIDI plugin, but also supports encoded samples (in any format supported by BASS and plugins). SFZ files can be used in the same way as SF2, via BASS_MIDI_FontInit/etc. They can be loaded from memory or user files (via BASS_MIDI_FontInitUser), but the "sample" fields should contain full paths (rather than relative) in that case. A way to load samples from memory will probably be added before the final release.

Please report any problems.