Subject: [linux-audio-dev] Re: EVO-Linux Physical Modeling HD Sampler
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Mon Jul 17 2000 - 21:31:29 EEST
On Mon, 17 Jul 2000, larry d byrd wrote:
> Hey Guys,
> Im going to jump the gun on the development of the gigaclone and take it
> a step further to see what you think...
Hi,
very interesting your mail ...
>
> Outside of porting various formats over (which I have about every sample
> library created in AKAI and GIGA format) how about a sampler that is
> based on physical modeling or in the case Im discussing gesture modeling.
> Kind of like the behavior sampling of giga but more complex..
> [A yamaha VL1 meets GIGA meets K2500 meets EMU Morpheus type of thing]
physical modeling ... nice, but first we need expert in these fields, plus
it is very expensive from a CPU point of view.
Anyway I am using function pointers to render audio fragments of every voice,
thus the algorithms are interchangeable as soon as they become available.
So adding physical modeling (if someone comes up with algorithms/code), will
not be a big problem.
The fun thing of function pointers is that you if a voice let's say does not
need the pitch modulation and the LP filter modulation the sampler uses
a simpler version of the function thus saving precious CPU time.
>
> Take the DSP process called audio convolution or morphing and integrate
> the function as either a real-time performance feature (I doubt we can
> pull that off) or a sample level DSP to the equation and you have a new
> breed of HD sampler that can be very expressive.
> You could apply the morph to say two opposing waveforms in a particular
> instrument technique.( Soft Blown Sax sample) and (Overblown Sax sample)
> and come up with
> the inbetween states of these two physical states to be used to model the
> physical elements of an instrument or come up with new unreal techniques
> by interpolating
> different techniques from different instruments at the two poles .
that would be nice but unfortunately it is easier to say than implement it.
If morphing algorithms are publicy available (not a secret of an evil-synth
company), and if someone has a clear idea in mind how the sampler
should "crossfade" the samples then it can be done.
>
> Now the problem with conventional samplers is that you cannot crossfade
> between more than two keymaps.(not to be confused with cross-switching
> which waits for a new midi note on before a new sample is triggered) .
What do you mean with keymaps ?
midi pitch key crossfading or velocity crossfading ?
I have a nice structure which is already partly implemented
See end of this mail for a description, and I'd like to hear some comments
from you if will be enough to meet the basic requirements of a professional
sampler.
> we can develop a structure that not only fades thru multiple keymaps thru
> discrete zone enabling but use the morph DSP to create the inbetween
> states of the two sampled techniques for smooth interpolation and realism
> I think we have a new breed of sampler.(Breath Cntrl amplitude morphs
> between states without re-trigger).
in my model all parameters are manipulable in realtime without the need of
retriggering see below.
>
> I have some HTML files on a very detailed interface blueprint for that
> sampler which for the sake of discussion I would like to call it EVO
> (Evolution or Evolver).
> Evolver could be the name of the control source that enables the morph.?
Let us know when and where you put them online.
>
> I think the VAST style matrix program structure is the best place to
> start for the sampler engine what do you think?..(Anyone own a K2000?)
No K2000 here , but webpointers and/or a detaliled description about the
structure should give us some insight
Are they available somewhere ?.
>
> I have many features that would make this sampler a winner but it would
> take time to integrate them all properly..
My questions are what kind of contributions can you give to the project ?
I mean .. you have very clear ideas how it should work and that is a good
thing. The problem is that these features have to be coded into working
algorithms, and that is ofen not trivial.
> One feature I also wanted to mention was something Im calling
> auto-mapping which is basically a collection of DSP proccesses and macro
> filing tables that make recording huge amounts of samples more of a
> reality than a chore.
the features below do not belong to the playback engine, because
that kind of task will be handled handled by external applications.
> 1.PITCH DETECTOR
> [Detects the pitch of a recorded sample and files it in a temporary
> keymap at the appropriate single zone automatically]
I think that there are some algorithms around which should detect
the pitch at semitone level.
> 2.VELOCITY DETECTOR
> [Detects the amplitude of each sample and stores it in a temporary keymap
> at the appropriate velocity range automatically]
Peak detection does not work well in this case, I think RMS (root mean square)
over short intervals might be a solution especially if the sample is always the
same.
> 3.LOOP DETECTOR
> [Finds a suitable sustain loop for infinite looping samples by comparing
> ratio of size of sample and typical loop points for various instrument
> groups and snaps to zero crossing
no idea how to implement this that it will work in a satisfactory way ..
(eg you cannot hear when the sample loops)
> sections].
> 4.AUTO-LENGTH
> [Sets the amount of memory or length of time a sample will be recorded
> when the thresh hold function is enebled.] To save memory and to match
> sample lengths together.
> 5.AUTO-FADE
> [Applys automatic crossfades to the decay section of specific samples so
> that all of the samples recorded in a program can be exact.]
Interesting, but I do not understand fully what you mean:
if you sample a note of a piano the decay will be automatically builtin,
why do you want to apply an additional decay ?
Especially because at runtime the sampler applies the decay envelope
anyway.
(Or does your auto-fade only make sense on static samples like
let's say a constant-amplitude SAW-wave , eg one which does not
decay ?)
> 6.THRESH HOLD RECORD
> [A function that enebles the built in sample recorder when a preset
> loudness is reached]
> Should be in decibels and have a pre-roll state so that there is no
> snipping off of attack sections...
again this task belongs to the recording app, and not the playback
engine , but interesting anyway ...
this feature is quite trivial to implement (I think most HD recoders support it,
although perhaps without preroll feature)
Implementing the preroll feature is quite easy too, because since we sample
the data into ram, we simple have to keep a certain history in order to
recover the data which came before the trigger point.
> I would love to be the first to make a 4 gig YAMAHA MIDI GRAND CD-ROM in
> .evo
> fformat..In fact I have a method of sampling the piano that could allow
> for up to 32
> velocities in pedal up and pedal down and release triggers and hammer
> knocks as well
Tell me more please, about the release triggers and hammer knocks.
Would it be ok to implement a feature which when you release
a certain note, it starts up a new voice-set , and quickly fades
out the playing ones (or alternatively you can stop them abruptly) ?
> as tone control and mic placement modeling..
> Anyway ,...Just some food for thought ..
> We will post some more details later and I would love to get some
> feedback on this.
> MIKE BAILEY (NeXuS Studio)
>
> *I can come up with a detailed block diagram of the program structure and
> we can all hone in on it and work out the bugs...
yes please publish this diagram, I am very interested, I have currently
developed my own and I am not sure if it suits your needs.
Let me know your thoughts, fatal flaws , inconsistencies, advantages
disadvantages etc.
Ok let's start:
VOICE:
a voice is basically a sample played back by the engine which has the
following characteristics:
- pointer to sampled data
- len of sampled data
- loop point begin , loop point end
- oneshot / looped
- base volume
- base pitch
- base panorama (balance)
- base filter cutoff
- base filter resonance
for each parameter
(volume , pitch , pan , cutoff and resonance)
there is an:
attack envelope
sustain envelope
release envelope
each envelope is an arbitrary succession straight lines
which consist of:
validity in number of samples
starting value
delta per sample ( can be positive and negative,
higher values will produce steeper , lower values flatter lines)
This way the envelope can have an arbitrary for man
the various sections do not need to be interconnected,
that means the value can jump abruplty between two
sections.
You can even simulate a custom sampled envelope
by setting the number of sampler to 1 , delta to 0
and provide a new start_value for each sample.
There is basically no limit to the envelope form,
with the big plus that you need very little memory because
it most cases successions of 10-100 straight lines will
suffice to form even a very complex envelope.
When you press a key , then the attack envelope
modulates the associated parameter.
As soon as there is no more data left in the attack
envelope structure, the envelope code switches
to the sustain envelope.
The sustain envelope will be looped during the
note-sustain phase.
(as soon there are no envelope points left,
the table will be scanned from the beginning)
When the key is released , the release envelope
becomes active.
Notice that all the above parameters can be
modulated by such envelope structures,
in a completely independent way.
eg: the volume attack envelope could for example
only last 100msec , while the pitch attack envelope
lasts for 500msec.
This will allow complex tremolo , vibrato or filter wah wah
effects.
All the above parameters can additionally be modulated
by an external source, which could be an LFO or a
MIDI controller.
Another thing we could do is to map a MIDI controller
to different envelope structures, so that
differen controller values (the modwheel or breath-controller)
could for example change the attack behaviour of the sample
at the next note trigger.
(would this feature be useful ?)
So far for the voices:
PATCH:
is the combination of an _arbitrary_ number of VOICES.
it is a structure which says:
play voice1 with parameter set 1 along with voice 2 with parameter set 2
and so on.
since the parameter set contains the base_volume for example,
you get volume crossfading automatically.
For example if you need a velocity crossfading with 4 sections,
just fill out the MIDI mapping table (velocity, keypitch) with pointers
to the PATCHes with the right voices and appropriate volume values.
You could even construct a velocity layering which at
let's say velocity 1-32 plays ony one voice,
at velocity 32-63 two voices and at velocity 64-127 four voices
all nicely crossfaded by arbitrary values.
The only thing I have still to figure out (at techincal level) is a way
to avoid to waste memory with empty pointers in the case you do not
need all the complex mapping features.
an insrument file is basically a file containing:
-all the samples
- the mapping tables: velocity,pitch --> patch
- the PATCH entries (all with their own parameter sets and pointers to
sampledate)
- the envelope structures used by the PATCH set
Obviously the voices will be routable through a FX section
(the FXes should be loadable plugins) , with dry/wet parameter.
Ok, finish for now.
let me know what you think about the above model.
Benno.
This archive was generated by hypermail 2b28 : Mon Jul 17 2000 - 23:05:52 EEST