Best file format for instruments with round-robin samples?

[Chad@PA]

Like, what would you do if both "lokey" and "key" were defined in the same region, and they were different values? What if there was a "volume" opcode in the Region, and also one in a Group? The spec says nothing about precedence, nor if ganged opcodes are added or overridden. What about the "transpose"?

Hi Garth,

Here is how this works in sfz in my experience:

Precedence should be handled by the available <global> and <group> opcode headers.

<global>
Groups and regions inherit all opcodes specified here.

<group>
Global inheritance, however any new opcodes specified here will take precedence for the regions within this group.

<region>
global and group inheritance, also any new opcodes specified here will take precedence for the specific region.


So with that in mind:

Code: Select all

<global>
transpose=12

<group>
group=1

<region>
sample=sample1.wav

<group>
group=2
transpose=0

<region> 
sample=sample2.wav

Sample1.wav will playback with transpose=12, while sample2.wav will play with transpose=0.

what would you do if both "lokey" and "key" were defined in the same region, and they were different values?

Code: Select all

<region> sample=60.wav lokey=60 hikey=61 key=60 pitch_keycenter=60

The key= opcode is intended to set lokey, hikey, and pitch_keycenter all at the same time to a single note. When all of them are specified, it is intended that the <region> should still be stretched to specified lokey= and hikey=, so they take precedence.

What if there was a "volume" opcode in the Region, and also one in a Group?

The volume from the <region> will take precedence over specified volumes from <group>, and <global>.


I agree there should be better details and documentation on this. There is room for interpreting inheritance and precedence in ways that would result in some very bad ugliness of instruments playback/performance.

[pljones]

The spec says nothing about precedence

Last opcode affecting something wins. AFAIR.

[davidv@plogue]

The key= opcode is intended to set lokey, hikey, and pitch_keycenter all at the same time to a single note. When all of them are specified, it is intended that the <region> should still be stretched to specified lokey= and hikey=, so they take precedence.

In ARIA, what I do is I scan a <region> (and its inherited defaults) for the key= opcode which then serves as a default for lokey/hikey/pitch_keycenter. If either of these are then defined, they override the defaults set by key=.

In Dimension/DropZone using key= is risky because IIRC (from reverse engineering) it will scan opcodes in order they appear, so key=36 lokey=37 will not do the same as lokey=37 key=36

I fully agree with Garth that issues like these would have seen more rigorous definitions if SFZ were under a standards Body like the MMA.

While developing ARIA I treated many edge cases such as these like what made more sense to me, even if it meant- in rare cases -that it wouldn't behave like Dimension/DZ. But ARIA is just one implementation and certainly not the official spec.

Lovely thread BTW!

[chickeneps]

Xleth: Okay, makes sense. Yes, SFZ is definitely for you.

[chickeneps]

Concerning precedence:

Yes, that's all exactly correct. My point was that the spec does not reveal this, we all learned it from witnessing the behavior in a Rene-programmed engine.

OT: I should note that precedence shouldn't be relevant with duplicate opcodes; in every other format definitions on different instrument levels are additive.

Imagine if you have an SFZ, with 140 regions, all having the "volume" opcode, and you want to duck the overall level by 3db. A designer just drawing off the spec (and frankly common sense) would do volume=-3 in a group, but that doesn't work since the region volumes get precedence. Hopefully that designer figures out his mistake.

David/Plogue added an opcode in ARIA's SFZ reading (which Chicken Systems supports now) called "group_volume" that solves that problem for ARIA, and that's great, but adding to the amount of opcodes isn't the best solution. The further you go away from a managed spec, the more dangerous it gets, and the more engines become incompatible with more SFZ files.

I'd like to appreciate David for his studious approach on SFZ, it's really helped matters.

If anyone uses SFZ, it's vital that they understand which engines (and which versions of engines) support which opcodes and how they support it.

[pljones]

http://www.drealm.info/sfz/plj-sfz.xhtml is pretty explicit about precedence and stuff.

The linuxsampler guys have made a stab at documenting their implementation, too. Unfortunately, they seem to have limited it to saying which opcodes they think they support without really explaining how. It took a little while to work out that "complete support" for an opcode to them meant "it seems to work okay" rather than "works like X", for some explicit definition of X (whether than be some reference implementation or their own specification).

There's always fun things like using "end=-1" as a choke in drum kits, of course.

[chickeneps]

pljones: Thanks for your work, I'd seen it before and it was helpful.

[Xleth]

SFZ is definitely for you.

No, I don't really think so...


This might become an industry-standard and open format, but I'm not sure if it supports round robin: http://www.midi.org/techspecs/dls/dls.php

[Chad@PA]

Hello,

If you were to decide for the best file format that is capable of referencing at least 16 round-robin samples per zone (a zone may span one or more notes and one or more velocities), which would it be and why?

My criteria:

- The format should be popular, mainstream and widely-supported

- The round-robin samples should not be any kind of "hacks" (such as EXS24, where it's some kind of a trigger-chained-group kludge labyrinth). It should be a clean, simple and straightforward list of samples that are assigned to a zone, forming a round-robin group.

Thanks!

Here is the answer to your original question as an sfz solution:

Code: Select all

<group>
 seq_length=16 

<region> sample1.wav seq_position=1
<region> sample2.wav seq_position=2
<region> sample3.wav seq_position=3
<region> sample4.wav seq_position=4
<region> sample5.wav seq_position=5
<region> sample6.wav seq_position=6
<region> sample7.wav seq_position=7
<region> sample8.wav seq_position=8
<region> sample9.wav seq_position=9
<region> sample10.wav seq_position=10
<region> sample11.wav seq_position=11
<region> sample12.wav seq_position=12
<region> sample13.wav seq_position=13
<region> sample14.wav seq_position=14
<region> sample15.wav seq_position=15
<region> sample16.wav seq_position=16

The <group> can be your 'zone' for any velocity range, velocity xfades, keyrange, etc.


I also wanted to share that I've had really excellent results with sfz round robins that utilize smaller round robin groups 3-4 positions, then there are 3 or 4 variations of those groups which each have a chance of being triggered randomly.

[pljones]

but I'm not sure if it supports round robin: http://www.midi.org/techspecs/dls/dls.php

No mention of round robin on that web page. You'll find plenty of coverage of SFZ using round robin if you do a little bit of reading of the documentation of for it. Or read Chad's post. It's trivial.

[chickeneps]

Xleth, I think you might be misunderstanding a bit - yes, SFZ completely supports round robin. And SFZ isn't going away, and even if it does, you almost certainly would be able to convert it into what will replace it.

Maybe we have supplied to much information on this thread... =) but IMHO there's never going to be such thing as an "industry standard" for instrument mapping until the operating systems (OSX and Windows) include a dominant-quality playback engine in their distributions, and that just isn't going to happen. Apple came closest with GarageBand (containing EXS24). But it'd have to be BOTH operating systems.

Lets look at some standards: MIDI and WAVE/AIFF. The only reason the MIDI standard occurred was mutual benefit of different manufacturers of hardware musical equipment (back then that's all there was). For single sample playback, there have been tons of standards, but over many years WAVE and AIFF became "de facto" standards. And even so, we couldn't agree on one - it had to be WAVE for Windows and AIFF for Mac. Apple even couldn't agree in WAVE, they had to try to push CAF. Now it's WAVE that has triumphed, not completely, and we are going on 30 years of use!

Manufacturers have no serious interest in interoperability, although they have some - note the usual inclusion of "we load these formats" as a top-tier feature. But a file format goes hand-in-hand with what a playback engine offers.

If you desire to have SFZ (a public format) to be the "industry-standard", look at it from the manufacturers point of view. They want to define their engine as something unique - but it they use SFZ natively they just become a "SFZ_player". Plus they become copycat in their design - the goal isn't to do something unique, but just to make sure they support the features supplied by the SFZ spec, written or implied.

Something else too - NI recently changed the Kontakt format, they didn't have to, but it was to their advantage to (I believe) because load time was of primary importance to them and getting the format to play ball helped matters. It takes time to parse a SFZ file, the bigger it is, the more time it takes to parse. NI wanted every millisecond.

Conversely, lets look at Garritan - they adopted the SFZ standard but that wasn't a cakewalk (pardon the pun) either, and (forgive me David) there was a bit of Kontaktization of the spec that needed to happen in order to support Garritan instruments properly; e.g. curve lists, pragmas for MIDI support, other things.

Lets look at SoundFont, which is really the last industry-standard mapping format there ever may be. That was created from one company that wanted a standard for soundcards. They published it, but to the companys detriment they bought all their competitors or put them out of business. (Talk about a gift horse!) So there was no one left to adopt the standard, and the pro MI community sort of adopted it.

Gigasampler was the first of the behemoth software samplers, and the .gig format is actually based on DLS (the MMA standard you mentioned), NOT SoundFont. However, it's not pure DLS. DLS (eventually) became open enough to handle any incoming features (conditional chunks) but I believe Nemesys (Giga's maker) didn't have patience with the MMA and simply used DLS as a template but made their own chunks without adopting DLS's methods, which may have not existed at that time. I think they missed each other by perhaps 6 months to a year. If .gig files were .dls files, we may all be using .dls today. But now, no one uses DLS, for quite a few reasons it did not keep pace with the changing needs of pro MI.

Thus the last opportunity for for a "industry-standard" mapping format was squandered away. But it is arguable about its place, there are too many variant needs for JUST ONE FORMAT to exist that handles everything. I like that SFZ is open and easy for anyone to write - it's more like a scripting language really - so it's really became a "de facto" format, which I think is more of the public's taste these days.

[Xleth]

Maybe we have supplied to much information on this thread...

The opposite is true actually. Your posts especially were very eye opening, as regards the illusion of future-proof "openness" of SFZ.

Sorry if this sounds too harsh to anyone, but compared to DLS, the status of SFZ (as regards standardization, documentation, and openness) is... well, a bad joke. Sorry. I am going to be avoiding SFZ (I will also avoid Kontakt, because when they go out of business and their software doesn't run on new versions of operating systems, people will not be able to load their instruments correctly -- reverse engineering just doesn't cut it for me).

IMHO there's never going to be such thing as an "industry standard" for instrument mapping until the operating systems (OSX and Windows) include a dominant-quality playback engine in their distributions, and that just isn't going to happen. Apple came closest with GarageBand (containing EXS24). But it'd have to be BOTH operating systems.

It's interesting you say that. Because, according to its Wikipedia page, DLS actually appears to meet all of your criteria:

"DLS is supported by the music synthesizers built into Windows and Mac OS X."

https://en.wikipedia.org/wiki/DLS_format


So, instead of wasting your time on SFZ, get together guys, and start supporting DLS in your applications. If DLS doesn't support round robin now, submit a request for enhancement to the MIDI Manafacturers Association. It should be trivial to add it. Eventually DLS might become the real open industry-standard format we need (just like WAV and MID).

SFZ is already half-proprietary/closed. It has no standardized future (the only future I see is either reverse-engineering and/or Wild West were anyone is adding his favorite custom stuff to it as they like). Don't waste your time with SFZ, seriously.

which I think is more of the public's taste these days.

Nope. It's not my taste. Think of WAV and MID. They are not like SFZ, they are like DLS. And that's the right path IMO.

[audiojunkie]

Maybe we have supplied to much information on this thread...

The opposite is true actually. Your posts especially were very eye opening, as regards the illusion of future-proof "openness" of SFZ.

Sorry if this sounds too harsh to anyone, but compared to DLS, the status of SFZ (as regards standardization, documentation, and openness) is... well, a bad joke. Sorry. I am going to be avoiding SFZ (I will also avoid Kontakt, because when they go out of business and their software doesn't run on new versions of operating systems, people will not be able to load their instruments correctly -- reverse engineering just doesn't cut it for me).

IMHO there's never going to be such thing as an "industry standard" for instrument mapping until the operating systems (OSX and Windows) include a dominant-quality playback engine in their distributions, and that just isn't going to happen. Apple came closest with GarageBand (containing EXS24). But it'd have to be BOTH operating systems.

It's interesting you say that. Because, according to its Wikipedia page, DLS actually appears to meet all of your criteria:

"DLS is supported by the music synthesizers built into Windows and Mac OS X."

https://en.wikipedia.org/wiki/DLS_format


So, instead of wasting your time on SFZ, get together guys, and start supporting DLS in your applications. If DLS doesn't support round robin now, submit a request for enhancement to the MIDI Manafacturers Association. It should be trivial to add it. Eventually DLS might become the real open industry-standard format we need (just like WAV and MID).

SFZ is already half-proprietary/closed. It has no standardized future (the only future I see is either reverse-engineering and/or Wild West were anyone is adding his favorite custom stuff to it as they like). Don't waste your time with SFZ, seriously.

which I think is more of the public's taste these days.

Nope. It's not my taste. Think of WAV and MID. They are not like SFZ, they are like DLS. And that's the right path IMO.

I really don't see DLS becoming the standard for sampling. I think that is overly optimistic. SFZ is currently the best we have as a "de facto" standard. The way I see it, is that the LinuxSampler team has published the closest thing we have to the full open standard--the most complete list publicly in existence. Considering that it is being supported by them, I think there is a better chance of their list becoming the accepted standard, since Cakewalk don't want to take the lead on this.

--Sean

[Ben [Camel Audio]]

I agree with the consensus on this thread - SFZ format is the best we have as a 'de facto' standard. Like Sean I really don't see DLS becoming the standard for sampling.

We support SFZ as the only sample format in Alchemy and Alchemy Player (which as well as having its own sounds, is also a free SFZ player) and are working on fully supporting all op codes in Alchemy v2. Thanks to everyone who's posted with information on interpretation of the standard especially Garth and David

Cheers
Ben

[chickeneps]

One huge problem with DLS is the monolithic nature of the format; that the samples are included in the file. That means no sharing of samples between files. That alone eliminates DLS as contender.

The native sample playback machines of OSX and Windows aren't anything anyone would want to use, and they have little incentive to improve them. Their base are people who can turn up their iPods, that's about it.

Look on the web and see the amount of DLS files available. Not many, perhaps zero.

Lets not forget what we are talking about. Why is a "standard" necessary anyway? Any major sampler loads in the most popular formats, and any future sampler will too. All major samplers save in a format where it can be disassembled (the exceptions mentioned previously). There is zero danger of loss or obsolescence.

Use SFZ.