Soundfont technology out-of-date?

[pljones]

For the player developer, having support for extensions is all well and good: they can tout the advanced features to entice users to use their software. No problem. (Well... we'll see...)

For sound designers, though, it's a nightmare. Do you:
a) develop for the base standard everyone can use and so have the largest available market
b) use advanced features, meaning only a small part of the market will get the best from your work (the rest perhaps thinking "this sounds useless, I'm not buying XXXX's soundfonts again")
c) use a proprietry sound engine (such as Kontakt, etc) and deliver this as part of your soundware?

Clearly, option b just isn't in their interests.

Option a is the easy way forward.

However, as there are limitations explicit in option a, option c seems to be the way many people are going (unfortunately). I'm not _that_ concerned so long as the sampleset isn't encrypted and only readable with the bundled software. But I get the impression, that's happening (I've never bought soundware - the free stuff's doing me okay so far). (An example: ns_kit7 has a free version in soundfont - and other - formats. Douglas is going to release a "full" version - a Kontakt mapping of the full sampleset. This will be my first non-free soundware... Of course, I'll be producing one or more sfz format mappings once it's out and I'll be able to distribute my mappings for free.)

But you can understand why: option c means the soundware developer knows everyone buying the sampleset will hear it as intended.

And, given that there's little content that requires option b (which is what you're proposing, J&H), I can't see there being much demand from end users. And hence nowhere near the commercial pressure for developers to go that way. There's more reason to develop a proprietry soundware engine.

Of course, once there's an sfz format player that (a) has direct-from-disk mode and (b) (as you've pointed out, J&H) allows parameters to be tweaked in real-time, then proprietry solutions might no longer be needed. However, I can imagine René might see the commercial advantages of such a player and make it payware rather than freeware (like the differences between sfz+ and sfz). Any other developer would, however, be free to produce such a player and distribute it, too, either as payware or freeware.

(Indeed, about the only reason I can think René might be convinced to do a Mac port of an sfz format player would be if a soundware developer was prepared to pay for the work so they could use it as the bundled player.)

[René]

And specially to Renè (because you asked): No. It is not my intention to present a new format, nor to develop my own soundfont player. There are other ppl, who claim to be "experts" in that area (but obviously all merely "hot steam" so far).


We expect a (professional) Soundfont player to extend and expand the old feature set and being able to play our soundfonts with an professional editor interface, if someone want's our money for that. We want the features, which are the standard for years now in average sampler units. And we want to be able to save our new patches without losing the integrity of our existing soundfont banks.

I see. So you're not going to do it yourself, but you're trying to convince "not hot steam" developers to do it for you, right?

You're trying to present a certainly valid point of view of what you want, and have someone to do it as it doesn't exist today, correct?

I'm seeing clearly that your selected way to get what you want will work for you very soon. Good luck!

-René

[steveholt]

I think there confusion between the format and the player. Every player will have knobs and dials to tweak and each will come up with special features. More to the point, each will have its own signal path and way in which the way in which different parts of the player relate to each other. The Soundfont format makes some assumptions in this respect and I can tell you from experience having written a Soundfont to sfz format converter that the sfz format cannot do everything a Soundfont can. Given that the sfz format is vastly more sophisticated it points up the futility of looking for a common standard.

Soundfont is relatively simple and makes a really good "lowest common denominator" across all players, but even that is rendered differently by all of them.

If you are looking for a truly common standard, throw away everything we have today and define a format which says WHAT YOU WANT, not HOW TO GET THERE. An LFO will somewhat emulate a tremolo, but a real violinist will produce something less regular. Find a way to say exactly what you want to hear, and let the software figure out what envelopes and filters to apply to approximate it. Then we would have a standard people would be keen to support.

As to the Soundfont standard, I think it does a good job right now, like an old pair of shoes.

Steve

[rpc9943]

Extreme Sample Converter will soon be it's own editor, so no more worries. It supports sfz and sf2.

RonC

[pljones]

From what I've seen in the demo, ESC doesn't process all the soundfont parameters into the matching sfz parameters. Maybe the demo didn't show it off but it's made me want to wait for a newer version before considering buying it... (I still prefer sf2comp and my perl scripts... I know what they leave out . Or Steve's editor.)

Steve, by the way, do you (or are you planning to) support the [url=file:///D:/Dynamic/Projects/www.drealm.org.uk/sfz/plj-sfz.html#newCC]"unofficial" opcodes[/url] in the current version of sfz.exe in sfZed?

[steveholt]

Steve, by the way, do you (or are you planning to) support the "unofficial" opcodes in the current version of sfz.exe in sfZed?

Well ... you can work with any opcode you want, even those not on the list. Just Choose "Named..." from the Opcode menu and type in the opcode name you want. Very bacic editing. Otherwise I am not keen to add unofficial opcodes.

You may also be interested that my Soundfont converter actually creates a complete Soundfont sfz format which you never see, with all the Soundfont parameters as "sf2..." opcodes, and then it does a conversion to the "real" sfz format.

Steve

[pljones]

Yes - I was meaning do you use them for the SF2 conversion... Maybe you could expose the mapping rules somehow?

(Heh, thread hijack... oops...)

[learjeff]

I thought of a feature that a sample player really should have: Mid-side format decoding. This would allow us to build a beautiful stereo soundfont that has a mono preset, where the mono sound is exactly what we want it to be, without requiring additional samples.

Mid-side arose as a means of stereo miking, where you use one mike (cardioid/unidirectional) pointed at the center of the soundstage, and the other (with a figure-8 pattern) at right angles, and record two channels. When remixing the two channels, the first channel ("mid") is panned center. The second channel is panned hard left and also inverted and panned hard right.

A nice thing about a mid-side pair is that you can control the width of the resulting image by adjusting the volume on the "side" channel.

Any stereo track can easily be converted to mid-side format (for example, using MDA's "image" VST plugin). Mid side is often used during mastering to adjust the soundstage width. I like to use mid-side for stereo imaging effects when I want them to cancel out to nothing when summed to mono.

Supporting mid-side format in a sampler give the sound designer the ability to carefully design the sound in mono and stereo. The sound designer (or the player itself) could give the musician the ability to choose from pure mono to full stereo, anywhere inbetween, or even beyond. Without requiring any additional samples over what's already needed for stereo.

Of course, without mid-side support built-in, the user can always play a stereo sound and pan both channels center to get mono. So, the only real advantages to supporting it in the format/player are:

(a) the ability to easily get a wider image
(b) a mono preset would only use half of the samples (the Mid channel only), freeing up CPU time.

[René]

I thought of a feature that a sample player really should have: Mid-side format decoding. This would allow us to build a beautiful stereo soundfont that has a mono preset, where the mono sound is exactly what we want it to be, without requiring additional samples.

MS is so cool. It's been in Gigastudio since the beginnin. Too bad there's no soundlibs using it.

-René

[Vradash]

It IS outdated. Look,some ideas:
1.Compression: MP3 or OGG
2.Better Stereo

I think the first is the important one.
There is a Format that supports compression,but there are no SoftSynth´s that are Supporting this Format.
It is DLS2++. It supports:
-Full Stereo
-MPEG Compression
-16-Bit sounds

[learjeff]

What do you mean by "better stereo"?

[pljones]

And what's so good about "Full Stereo", "MPEG Compression" and, particularly, "16-Bit sounds"?

[learjeff]

Well, it would be nice to have compression capability built-in, to allow smaller files (for performance, not just for exchange like sfArk/sfPack). Might reduce memory profile, and also improve disk streaming performance.

But it would be best to support Monkey's Audio compression, because it's lossless. Of all the lossless compressions I've found, it's the best (compresses the smallest) for either mixed music or for single instrument tracks, which tend to be less complex and compress better. Best of all, it's a trivial process to decompress, very efficient (being a linear-predictive encoding).

I missed the "16 bit sounds" part! Of course, sf2 is entirely 16-bit sample based.

So, other than MP3, what does DLS2++ support?

BTW, the SFZ softsynth supports compressed samples, when using the sfz format.

[gunnare]

I woted NO. Its not out of date. I played with the wizoo fender rhodes translated to soundfont today in sfz. I played with it for 3 hours, it just sounded so good.

The sfz is a miracle. How can it use so little resources? It is the most cpu effective vst-instrument in my machine. I always use it when i write a song. I also use it for live playing. The cpu-load is so low, that the risk for crashes live is minimal.

[marce]

Hi Jeff. About the use of lossless formats, i prefer flac instead of ape (i have some bad/corrupt experience with ape, and flac is gnu if i correctly remember) but beyond wich one is better, i remember to require to a sample player developer to support flac, and he gave me some reasons that are interesting to know, you can read it here:

http://www.myriad-online.com/cgi-bin/bb ... 3;start=34