Re: [linux-audio-dev] RE: disk-based real-time sampler prototype released ! please try it.

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

Subject: Re: [linux-audio-dev] RE: disk-based real-time sampler prototype released ! please try it.
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Jul 13 2000 - 23:11:45 EEST


On Thu, 13 Jul 2000, Garth Brantley wrote:

> >
> Well traditionally with hardware samplers & with gigasampler, the
> filters are built in. They need to be applied to separate layers of the
> sound separately & are a fundamental part of what a particular program
> sounds like.

but nothing stoips us from firing up N instances of let's say a LADSPA
Lowpass filter and use them for each playing voice.
If would be very flexible since you can exchange the filters to suit your needs.
What has to be figured out is if it is efficient enough to do the job.

>
> >
> Well I have worked with Akai, Kurzweil & Gigasampler. With each system,
> one program can have a fixed number of Layers. A layer is defined as one
> sample voice & associated envelopes & filters. On akai S1000/s3000 you
> could have only 3 layers/program. On Kurzweil & giga you can have a lot
> more. The layer system was create to have different samples for different
> velocities. IE you record a piano key being struck light, medium & hard.
> If the keyboard is struck with a velocity between 0-40 you play the light
> sample, between 41-80 the medium sample, and between 81-127 you play the
> hard sample. Most samplers seem to provide a method for crossfading
> velocity layers. IE the light sample runs from velocity 0-50 and the medium
> sample plays from velocity 30-90. Between velocities 30-50 the light &
> medium samples are crossfaded.

Yes I am aware about "zones" ( key zones and velocity zones).
And if you look at my simple fileformat,
there is an array called:
char mapping[128][128]; /* velocity , pitch mapping */

(could be of type short int as well in order to support up to 65536)

with this mapping i can basically map each pair of velocity, pitch
to a different sample.
for example by doing this:

typedef
struct {
  short sample1; /* index of sample1 , -1 means no sample */
  float volume1; /* mixing volume of sample1 */
  short sample2; /* index of sample2 */
  float volume2; /* mixing volume of sample2 , -1 means no sample */
} mappint_t;
        
mapping_t mapping[128][128]:

with a memory consumption of 200KB (for each loaded instrument)
you can have unlimited velocity and key zones with crossfade capabilites.

all you have to do is to precompute these tables in the right way.
(you can even have non linear volume mappings since the effective
mixing volume is looked up in the table using velocity and pitch as index.
The advantage of this is naturally speed, since the audio thread will find
the right samples with a simple table lookup.
If it uses too much mem for you , then you have to compute the zones
using if() within the audio rendering loop, but that is not so flexible, because
the figures are more static.
(eg. I want linear velocity mapping for notes 30-50, but then logarithmic
velocity mapping plus a different sample each 20 velocity steps)
With a fixed algorithm this is very unflexible, and it will be unable to cover
all the cases.
What do you suggest.

> >
> So far the .Gig format seems like a big pain in the ass to reverse
> engineer! It doesnt seem anybody out there has even really tried so far.
> And a quick look at a few .GIG in a binary editor doesn't give me much
> confidence that it would be easy to do.

One way to figure out parts of the format would be to use their instrument
editor (do they have one ?) and generate simple instruments, and see how it
looks, then add more samples and see what differs.

Benno.


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 - 23:05:23 EEST