Determine pitch range of SoundFont

[noocsharp]

Does FluidSynth provide a way to determine the range of valid pitches in a soundfont? What I'd like to be able to do is to guarantee that when I play a note using fluid_synth_noteon that the soundfont has a sample present for that note.

[derselbst]

There is no direct way to do this. Because whether or not a sample will be played does not only depend on the note. It also depends on the velocity. E.g. it could be that key 60 has a sample assigned for velocity range 0-126, but velocity 127 does not spawn a sample.

What you could do is to call fluid_synth_noteon() and watch it's return value: In the unlikely case that no preset is assigned, it will return FLUID_FAILED. Otherweise you'll usually get FLUID_OK. Then you would need to find out whether a voice has been spawned for that note / velocity combination that you just used. See fluid_synth_get_voicelist() to obtain a list of voices which you can search through the note / velocity combination. Then turn off the note, and try the next combination.

But again, a portable (or generic) solution for this would have to try every possible note at every possible velocity. Usually it's much simpler to ensure that the soundfont you're gonna use matches your needs.

[derselbst]

I would just like to know up front what range of keys is supported by the soundfont (at a given velocity), so I can take it into account when calculating which key to play.

Calculating what, why, how? Are you one of those microtonal tuning guys? In this case, see #932.

Your code snippet would have to be called for all 128 velocities to return 128 potentially different key ranges which you would have to administer somehow. Or does the "at a given velocity" mean that you're only every going to use a single velocity? (which would seem pretty strange to me from a musical point of view)

[noocsharp]

Haha, no I'm not a microtonal tuning guy.

I'm writing a clone of an iOS toy/game from many years ago (I forgot the name, and it doesn't seem to be on the app store anymore). It involves balls hitting surfaces, and producing notes with pitches depending on the velocity of the balls when they hit the surface. In this application, the exact pitches produced don't really matter, but it is vital that a pitch is produced whenever a ball hits a surface.

[derselbst]

Ok, understood. But this means that you have full control over the soundfont you'll be using. Even more: you probably want to use a few catchy soundeffects when hitting the surface. You probably don't want to distribute a Soundfont which is several 100 MB in size - merely, you want to set up a soundfont which contains only those few sounds that you really need to keep the size of your app small. So... why don't you simply make sure that all those particular sounds have assigned keys 0-127 and vel 0-127? Your use-case really is the job of the Soundfont designer (you) to make sure that it doesn't contain any non-assigned key/vel combinations. This is not the programmer's job.

[noocsharp]

I could have full control of the soundfont if I wanted, but I thought it would be interesting if the user was able to provide their own. It's meant more as a simple experimental toy, not as a standalone product to be widely distributed. I understand if you think this functionality has too narrow a use case to be included in FluidSynth, but I think I'm going to go ahead and implement it if only for myself. Thanks for your explanation about how sample selection works and pointing me to the relevant code!

[derselbst]

but I thought it would be interesting if the user was able to provide their own

Pls. keep in mind that malicious soundfonts in the past have successfully made fluidsynth crash. There's no guarantee that this couldn't happen again.

Also keep in mind that soundfont instruments have a few more parameter which affect whether a sound will be instantly audible or not, e.g.:

• volume attack: if it's too long, the sound will be played with a certain delay, and surely not when the ball hits the surface.
• sounds can be designed in a way that they are triggered when a noteoff is received.
• modulators may be added which expect certain MIDI CCs to be set in order for the sound to be audible.

Yes, these are pretty rare conditions. Just like unassigned note/velocity combinations are rare. But they have to be considered. In any case, checking through the note/velocity ranges is a nice gimmick, but it surely is no guarantee to produce a sound, which you seem to be looking for.

I think I'm going to go ahead and implement it if only for myself.

Ok, good luck with that. Pls. ensure to make the change to fluidsynth transparent (either by providing a patch or link to your modified fluidsynth fork at Github) to not infringe the LGPL. Could well be that others will find it useful as well.