RE: [linux-audio-dev] RE: [Linux-audio-dev] Re: Gigasampler Clone

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: RE: [linux-audio-dev] RE: [Linux-audio-dev] Re: Gigasampler Clone
From: David Olofson (david_AT_gardena.net)
Date: Thu Jul 13 2000 - 04:27:36 EEST


On Tue, 11 Jul 2000, Garth Brantley wrote:
> I found the AIFF-C Spec at http://home.sprynet.com/~cbagwell/aiff-c.txt.
> However the only Keymap like info I found is the "Instrument Chunk" this
> specifies loop points, original pitch, detune, key range & velocity range.
> This is fine for one sample (although envelopes & filter settings will also
> need to defined per sample), however the file format we would need for a
> software sampler would include many individual samples (with all parameters)
> as well as global program parameters. Of course the sampled audio itself
> should be maintained in WAV or AIFF compatible manner.
> I am going to do a little research into the basic requirements for a file
> format. I will post a report to the mailing list when I have something
> assembled.

The problem with anything like this is that it'll either be way too
limited, or way too complicated to support and/or use. Look at
SoundFonts, for example. Cool for basic sampled instruments, but you
need to add extra information, or using a pro sampler will feel
like driving a Lotus (*) on endless american straight roads...

I'd prefer to see something that uses existing formats for data
storage, but allows more advanced machines/software to store data for
their special features in special chunks or separate files. That
would allow existing data and applications (editors, converters etc)
to be used, while still supporting new stuff.

Example:
* Store waveforms + basic key range, envelope and LFO data as
  SoundFonts.

* Define a way to strap on extra information, like controller
  routing, real envelopes, LFO sync, multivoice structures with
  extra filters etc.

Of course, this could be done through a file format that's basically
constructed according to the same principles, but that would have the
disadvantage that you need to make different versions of the entire
files to support the extended features of more than one playback
device, rather than supplying one basic data file (like a Doom WAD :-)
and small files that reference that file and add info to it.

Actually, stretching the "separate files" idea as far as to storing
all waveforms in a common "database" would be rather useful, as
SoundFonts (for example) tend to result in duplication of waveform
data...

//David

(*) Brittish sportscar maker known for designs with extraordinary
    cornering capabilities.

.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Jul 13 2000 - 05:56:36 EEST