Multi wav fileformat?

[Midiworks]

thockin > Midiworks > Ever used a rompler.. like rolands JV synths .. Im sure you have, roland, yamaha and korg has released tons of them.
When you make a patch in a rompler you start out by selecting a "tone" from a list, like "dark piano". A typical rompler has a structure like so:

Tone generator -> filter env -> amp env -> pan -> effects -> output.

Ok, I skipped some stuff. Anyway, the point is that a "tone" is a series of samples mapped out on the keyboard. This file format would have that function.

Fine and you want to do this with SE ?

If so use:
CV to midi -> then connect soundfont osc to it
now add whatever you need "ADSR, Filters, LFOs etc."

If you try it with the wav player CPU load
will be too heavy.

[Rock Hardbuns]

Noooo! Dude! Thats exactly what I dont want.

Are we playing Mornington Crescent here?

[Midiworks]

C++ ?

[Midiworks]

C++ ?

[Markleford]

Should the file allow for more than one map or not?

Defnitely one. No banks.

So far as packing .wav files and mapping in one file, does anyone know the basic format that SampleTank uses? Any design template that they followed?

Of course, one of the bad things about ST is they need to store duplicate wave data to make another preset based on the same samples...

('Course, we're just talking wavesets here, nothing else!)

- m

[Midiworks]

Guys sorry I dont get what you would like to build...

A Rompler fine but why talk about ST format ?
That is the most secret kept format and very unflexible btw.

The only advantage I see with ST that it can
be used in a compressed form.

Please guys enlighten me !

[Rock Hardbuns]

Open keyboard-mapped samples file format.
Spec Draft 0.1 2003-10-29

File extensions under consideration
OKS, KMS


Description in Brief
The [OKS] file is a meta file that contains sample files. The samples are mapped to specified areas on a midi-keyboard that will be refered to as zones. A zone is delimited by a key-range and a velocity-range. The fileformat is deliberatly designed to be easy to implement and extensible.


Purpose
To allow for the easy sharing and transportation of multiple mapped sample files. The idea is to have a file format that can function as a basic building block in a rompler type VSTi. At the heart of this line of thinking lies a desire to bring back the good old rompler style of sound editing, but with a sharing of sampledata. (And without being locked into a proprietary format, or having to map all the samples up yourself every time you make a new patch.)

The purpose is NOT for this format to grow into a replacment for sound fonts or any other instrument file format. While its certainly possible to extend the basic structure accomodate such features, such an undertaking would have to a project in itself. The [OKS] file contain only data realting to the the waveform, and which waveform to play depending on the MIDI input.

********

Structure
The file is a standard zip file but with the extension [OKS]. The zipfile contains one XML file and the sample files in *.wav format. Every XML-file contains one map.

Mapping
Only one sample can be mapped to any point in key and velocity. Hence no crossfading or layering.
Such features can possibly be added as extensions at a later date.
(To allow for backwards compatabillity we stipulate the following rule. If two zones have overlapping key or velocity ranges, the later zone should take preceedence)

A series of alternate samples can be assigned to a zone to allow for rotation and radomization. (A feature wich can greatly enhance drumrolls etc.)
What to do with these alternate sample should be left to the VSTi or the user to select. The file format just allows for the possibility. (We have a rule here too: Make the first sample the most important one. If an instrument is only capable of handling one sample per zone it should be the first.)

Parameters

• Map Name
  Map Description
  Number of zones
  • Zone name
    Zone key upper limit
    Zone key lower limit
    Zone velocity upper limit
    Zone velocity lower limit
    Zone Muting Group
    Prefered sample switching type
    Number of Samples in Zone
    • Sample file name
      Sample root key
    ...
  ...

Map Name
The name of the map. 64 chars ASCII

Map Description
256 chars for information about the map

Number of zones in map
Not sure if its needed but it might simplify the loading

Zone name
The zones should have a name to allow for extentions that needs to refer to more than one zone but not all.

Zone key upper limit
Midi note number, inclusive

Zone key lower limit
Midi note number, inclusive

Zone velocity upper limit
Midi velocity value, inclusive

Zone velocity lower limit
Midi velocity value, inclusive

Zone Muting Group
A value between 0 and 255. If two zones have the same value only one of them should be able to sound at any one time.

Prefered sample switching type
If there are more than one sample in the zone, this parameter should set the default behaviour.(Rotate, random, are there others?)

Number of Samples in Zone
Once again, may help with setting up arrays and stuff.

Sample file name
Name of the wav contained in the zip that should be played

Sample root key
Midi Note Number. This is possibly redundant as wavs can store a root key. We may include other formats in the future.

[thockin]

Feedback:

Open keyboard-mapped samples file format.

Structure
The file is a standard zip file but with the extension [OKS]. The zipfile contains one XML file and the sample files in *.wav format. Every XML-file contains one map.

You might not say zip file, and say something more generic. It may be better to not use a compressed format, but instead use tar or something similar.

Mapping
Only one sample can be mapped to any point in key and velocity. Hence no crossfading or layering.
Such features can possibly be added as extensions at a later date.

I see no reason at all to disallow layering. X-fades require more info, but layering seems useful.

A series of alternate samples can be assigned to a zone to allow for rotation and radomization. (A feature wich can greatly enhance drumrolls etc.)

Good idea, needs to be more clearly defined. Something like:

The sample or samples (if layered) which correspond to a Range are called a Tone. Each Range may specify multiple alternate Tones. This allows the plugin to rotate or randomize which Tone is selected. Only one Tone at a time may be played.

Map Name
The name of the map. 64 chars ASCII

Map Description
256 chars for information about the map

This is XML - no need to limit the strings.

Number of zones in map
Not sure if its needed but it might simplify the loading

Not needed - this is XML.

Zone name
The zones should have a name to allow for extentions that needs to refer to more than one zone but not all.

Hrrm, I don't see any use for this. Make the name optional.

Zone Muting Group
A value between 0 and 255. If two zones have the same value only one of them should be able to sound at any one time.

Explain more. I understand, but be CLEAR.

Prefered sample switching type
If there are more than one sample in the zone, this parameter should set the default behaviour.(Rotate, random, are there others?)

Dump this - leave it to the plugin.

Number of Samples in Zone
Once again, may help with setting up arrays and stuff.

Dump it.

Sample root key
Midi Note Number. This is possibly redundant as wavs can store a root key. We may include other formats in the future.

Be clearer on what this means, if it is needed at all.

[Midiworks]

Thanks, but there are missing
the sample start, loop and end points.

Or have I overseen that ?

Anyway, I don't really see the point in introducing
another format.
There are more than enough already...

Highly transportable are:
HaLion
Kontakt
VSampler
S-5/6000
EXS24

All those use seperated wav files and a program file.
So you could store all those formats together using
only one time the wav files.

And all those program specifications are much more flexible than what I read above.
To figure out the S-5000 format would not be such a big deal...

Cheers

[Rock Hardbuns]

thockin >
Good thoughts.. ill work it over.

As for layering, allowing it would bring the format into the next level of complexity. My thought is that layering should be handled by loading several maps.

Or possibly as an extesion where the map becomes a subelement of a larger structure containing more than one map. 1 map on 1 note = one playback channel.

Midiworks >
Ever heared the expression "less is more"?. The idea is to simplify.

[pljones]

Pukeweed - looks good. Keep it simple and unconstrained - as thockin says, XML doesn't need to specify bounds. Maybe allow for MIDI cent-note samples for microtonal instruments, somehow, rather than just per MIDI note number? Support the highest possible demands initially rather than having to kludge it later .

I'd still go for ZIP rather than TAR, because of Windows... although I'd perhaps allow for various wave compression algorithms - perhaps by file extension/content, i.e. up to the plug/host to support. I'd mandate support for AIFF and WAV, 16 bit 44k1Hz.

Base note is optional, need to specify a default note where not found either in the XML or the sample. Similarly, it would be useful to allow overriding wave/loop start/end points (maybe to have a single wave file with an entire drum kit in, for example), with default (whole wave unless found in the ("acidized"?) sample).

[thockin]

What was that you said about keeping it simple?

All that other stuff is cruft, as is layering.

[Rock Hardbuns]

Zip tar rar etc..

It doesnt matter one bit to me really. Id prefer the format that has the most widely available royalty free libs for the largest number of platforms/languages. But not GPL..
Im going to investigate this a bit.

[Markleford]

As for layering, allowing it would bring the format into the next level of complexity. My thought is that layering should be handled by loading several maps.

I was thinking along those lines as well. However, I was even considering the notion that perhaps even *velocity* mapping should be considered outside of the scope of this format!

This would give more flexibility to the plugin to decide where velocity zones were deliniated. If you put hard-coded velocity values in the map itself, they will probably be set to how your keyboard responds and how heavy-handed you are with the keyboard, right? This could be entirely inappropriate for someone else's situation.

Again, though, I'm thinking of these maps as a "sample oscillator" to be selected by the synth, as one might choose between a square or sawtooth waveform. This might be different than what you all are thinking...

- m

[Markleford]

Other bits:

1) I don't think any particular existing archive format is necessary, is it? Roll your own and make a utility to pack and unpack them (as well as convert from SF2, etc)

2) Compression should be left to an external app, sort of the way sfpack and sfark do things.

3) Are we keeping an eye towards platform-interop for the binary portions? Should samples be allowed in aiff, as well? mp3, ogg?

4) As pointed out, where are sample lengths and loop points? Of course, these could be embedded in an internal .wav or .aif file, but how will the other formats cope?

5) Muting group? Hey, this ain't no stinkin' drum machine!

6) More important than the file-format is perhaps the API for use in the synth's development! I'd naturally gravitate to providing a solid C++ class first of all, which could be ported later to other popular audio dev languages. Methods for load(filename), save(filename), release() and fetch(notenum, *sampledata) are obvious choices. Then we get to define what would be handy for the sampledata class/struct: many fights will ensue!

- m