Soundfont technology out-of-date?

[useruseruser]

I don't see any problem here, because the product- specific mapping data will be saved separat then.
And all samplers and soundfont players shouldn't be sample destructive in any way.

All the conversations and probably sample manipulations should be made online without touching the integrity of the original samples on our disks!

Thus, a kind of standard or "rules" could be very useful for all manufacturers of samplers and soundfont players.

But the discussion of the possible "cooperative level" and a possibly new soundfont format is a complete different question, I think.

We just want soundfont players with more professional and more actual "state of the art" features. So we can use all our *existing* soundfonts and play and edit them with higher level of realism and creativity on the fly!

That's, what I wanted to state with the poll.

(But the result at this time seems to be satisfied with the current situation. Maybe most don't understand right my intent or didn't even discover any problems with the good old soundfont formats.)

.

[Spratman]

While I'm here I might just muddy the water further.

When does articulation and "special sample playback" stop being something for a sampler/sample format to handle and something that a sophisticated vst/other host should be doing?

Some people might suggest it's the midi standard which needs a good kick in the rear, not sf2..

Spratman

[useruseruser]

While I'm here I might just muddy the water further.

When does articulation and "special sample playback" stop being something for a sampler/sample format to handle and something that a sophisticated vst/other host should be doing?

Some people might suggest it's the midi standard which needs a good kick in the rear, not sf2..

Spratman

That's simply wrong. MIDI is not the point.

I tried to compare *available* sampler technology (with satisfactory results so far) with the old-fashioned standard of the latest popular soundfont players. It seems, they implemented merely (but proudly) old average (partwise useless) technology into it, because the spec "didn't allow it", which is also wrong.

An example:
Normally you do a GrandPioano in soundfont this (cumbersome) way: You edit a countless (up to 128) layer of velocity mapping, to get this piano sounding natural. Probably you do it with new samples for each layer for more realism...

Or: You want make a string sample natural playing by doing the same thing. You mapp the low velocity with a layer that plays longer attack and map several additional layers with increasin attack rate, so that it plays with full attack on highest velocity.

You even do the same stupid thing for different filter amounts!...

Thats all dammed shit and gives unsatisfactory results. Layer crossfading and advanced modultion routing is the key here.

Rather you could do some really smart modulations by velocity (note on and note off velocity) to achieve even a much better and more realistic result with less resources.

Also aftertouch for swells, pitching and filtering while playing is a great modulator to really give the static samples live and natural articulation.

Even for real instruments.

Or switch it to monophonic playing with legato and portamento features...

With good samplers you can define a dynamic sample offset dependant of the velocity and so on...

The possibilities are endless by even implementing very easy and basic ellements to the currently limited situation...

But the soundfont spec don't support all this directly. Only some very basic things. It was written 10 years ago. Why accept this today?

That's why soundfonts often sound not as good as they could (in a pro grade sampler for instance).

Got the point?

We want those pro features now, because they are actually the state of art in samplers since years now. The old fashion and feature set cannot longer impress us for some obvious reasons.

The potential is still there. But unused.

Thesis: Legacy soundfont players (even new products) which merely simulate an old AWE soundcard in software have no justification anymore today and shouldn't ask for money therefore.

.

[Spratman]

All I was saying was that there were *other* things which need to be taken into account when it comes to making *great performances*, the sample playback is only one part of the equasion.

I agree that things like crossfading could be very nice to have, but you're still going to have lots of parameters to play around with when creating realistic piano samplesets etc.

The fact is I believe at least, that RGC's SFZ/SFZ+ is one of the best things that have ever happened to the format. Rendering via the "what you hear" type internal recording of songs with samples doesn't always field consistent good results..

Spratman

[useruseruser]

All I was saying was that there were *other* things which need to be taken into account when it comes to making *great performances*, the sample playback is only one part of the equasion.

I agree that things like crossfading could be very nice to have, but you're still going to have lots of parameters to play around with when creating realistic piano samplesets etc.

The fact is I believe at least, that RGC's SFZ/SFZ+ is one of the best things that have ever happened to the format. Rendering via the "what you hear" type internal recording of songs with samples doesn't always field consistent good results..

Spratman

That could be right,
if there was not the possibility to to it with an average sampler significant better.

So I finally don't agree, that it was "the best thing" for soundfonts. It was a good thing and maybe a prima start. And was merely a question of time that is was done (by whoever).

Software samplers are actually the best thing for soundfonts. Nothing has changed.

So I actually prefer to use my Kontakt rather than to play anything more complex (i.e. orchestra soundfonts) with sfz+.

That's the point.
It is fine, that we have it, but it is unsatisfactory in the final results (if you have a claim to achieve best quality possible).

.

[SparkySpark]

Hi J&H and others,

I find this a very interesting thread, although I wouldn't care so much for the poll itself - I don't think it's worded the way J&H intended to.

An open expandable XML-based or XML-like format would be great. Then more things could be added later on by the developers, and other developers could use the same format (as the standard would be open). I guess some of the highly competent developers at KvR could make this happen together, and also develop a "XoundFont" ( ) sample player/sampler that could be free of use. A very clever batch converter program for coverting old SoundFonts (and more formats perhaps) to this new format would be necessay of course, but I don't think it would be hard to write such an application (naturally, this app should also be included in the new sample player/sampler directly, as opposed to only be available as an Awave-ish stand-alone program).

If this becomes successful, sample CD companies who are not also selling samplers/sampleplayers would most certainly back us up and what would we gain?

1. A sample format with more flexibility and power than sfz+.
2. A standard that could be used for years to come.
3. A semi-automatic way to convert previous files (sfz, sfz+, AKAI, wavs, aiffs, etc) to this exciting new format.
4. The first sample format ever that would actually get its support from users, hence being "asked for" as opposed to being "put out" by companies.
4. A FREE sampler/sample player!

None of the development stages seem unreasonable to me, having seen what others have coded here at KvR. There are so many products developed by really competent developers here, and still such products may only find a few hundred users. The things I have been talking about would yield a user base of many thousands (or many millions if Creative would replace their soundcards' SoundFont technology with XoundFont).

Think greatness. Think fame. Think Linux hype - only more useful.

/SparkySpark

[useruseruser]

XoundFont!
[ speak: exchange sound font ]

.

[pljones]

An open expandable XML-based or XML-like format would be great. Then more things could be added later on by the developers, and other developers could use the same format (as the standard would be open).

sfz format allows implementers to extend it. It defines the behaviour for unrecognised opcodes (silently ignore). The format is very readable, too. And, while it's not XML, it's very easy to parse and process.

I guess some of the highly competent developers at KvR could make this happen together, and also develop a "XoundFont" ( ) sample player/sampler that could be free of use.

A bunch of KVRers did have a go at this but I don't seem to be able to find a thread reference to quote. This was shortly before René issued sfz format, which rather killed the idea.

1. A sample format with more flexibility and power than sfz+.

sfz format gives you this.

2. A standard that could be used for years to come.

sfz format gives you this.

3. A semi-automatic way to convert previous files (sfz, sfz+, AKAI, wavs, aiffs, etc) to this exciting new format.

Various tools for sfz format give you this.

4. The first sample format ever that would actually get its support from users, hence being "asked for" as opposed to being "put out" by companies.

sfz format gives you this - go read the thread .

4. A FREE sampler/sample player!

sfz.exe gives you this.

[useruseruser]

edit:

The sfz+ format is currently in it's childs shoes. Not even an editor by the inventor available.

And it's not an very poular format yet. Isn't it? It's seems to be more a company spezific project to feature commercial product(s).

And its probably intended to be a very general generic format for all kind of different sound generators.

However,
the free sfz (at current state) don't even allow approximately, what we are lookin for. In fact it allows NO user interaction of the sounds via GUI in a comfortable way.

The format may be there, but not an implementation yet.

Not even sfz+, the pro version, does this satisfactory. It's a soundfont player with merely less improved legacy features and just simulates the AWE functionality. Not really anything revolutionary.

.

[SparkySpark]

XoundFont!
[ speak: exchange sound font ]

.

...or short for XML-SoundFont, but either way is fine with me (I'm not capable of implementing it anyway so who am I to speak up?!).

/SpSp

[SparkySpark]

pljones - thanks for clarifying. I'm not the one to say which way is the best one from a technical point of view, I was more thinking marketing and usability.

I'm glad to hear most of the things I mentioned are indeed in place. Perhaps it's not the tech stuff that are lacking but the market stuff. Now THAT's a thing I can handle!

/Sp-Sp

[whyterabbyt]

jackle&hyde quoth

The sfz+ format is currently in it's childs shoes. Not even an editor by the inventor available.

And so what? You're saying you want an updated and improved soundfont-type format, but when there's one available you dismiss it because the preson who actually sat down and did some work on it didnt build an editing package?
There's a spec and an implementation. What have you done, precisely?

And it's not an very poular format yet. Isn't it? It's seems to be more a company spezific project to feature commercial product(s).

Your 'extended soundfont' is so popular it doesnt even have a spec, let alone users.
And its an open specification. So no, its not company specific.

Or is the issue because its someone else's specification and its already pre-empted most of what you're talking about?

And its probably intended to be a very general generic format for all kind of different sound generators.

Ah I see; you havent actually looked at it all then.

However,
the free sfz (at current state) don't even allow approximately, what we are lookin for. In fact it allows NO user interaction of the sounds via GUI in a comfortable way.

So? That has nothing to do with the specification; the free version is a proof of implementation. The spec is an open standard.

The format may be there, but not an implementation yet.

Yes there is. Just because the free implementation doesnt have a GUI which suts you doesnt mean there's no implementation.

Not even sfz+, the pro version, does this satisfactory. It's a soundfont player with merely less improved legacy features and just simulates the AWE functionality.

And excellent quality. Certain versions even support the Gigasampler format.


Not really anything revolutionary.

Doesnt have to be revolutionary. Evolutionary is fine. Your 'improved soundfont' idea isnt evolutionary either. In fact its highly derivative of the sfz spec it seems. So we'll just forget about your ideas completely, okay?

[marce]

Talking about see the future, i saw Synthfont more powerfull and open to improvements than sfZ, that's MHO. The developer has opened a lot of "battle fronts" at the same time, that makes that it have a lot of feature but some of them a little buggy/beta yet. Give it a little time, i believe that you will surprise with it.

I love sfz and synthfont, anyway. The first step i expect from a sample player is that it emulate 100% or closer my old awe64/sblive. And from there, you can improve.
I have tryed a lot of "soundfont players" that only read the waves and lost most of the parameters and filters that makes a soundfont a soundfont and not a wave file. Make a sample player that "only" emulates a soundblaster card is not easy, it has merit.

[birrbits]

That's why soundfonts often sound not as good as they could (in a pro grade sampler for instance).

Ok, I agree the spec has limitations, but a real eye-opener for me was how many of these modern "pro grade samplers" have problems with aliasing. Your beloved Kontakt is not alone in being just 'alright' at simple pitch shifting.

http://www.simonv.com/music/quality/

Notice that the 'old' SBlive actually does a better job at this simple task?...hmmm

Better standards are great, but I'll take quality over flexibility most days of the week.

[marce]

Good point birrman. I believe that maybe they simplify the "anti-aliasing" power to avoid rest performance.
Since we are requesting "open standars" for samplers, a good idea too is request from soundcard developers a "open standard" in their dsp chipsets, that makes sample players more related to hardware.

I can run without problems a big soundfont with my PII 300 mhz with a sblive. To do the same with a softsoundfontsampler you need really a lot of horsepower.

Any one have news about this project that allows you use the powerfull Graphics DSp of graphic cards for process audio?