Subject: RE: [linux-audio-dev] Re: EVO-Linux Physical Modeling HD Sampler
From: MOULET Xavier FTRD/DMR/ISS (xavier.moulet_AT_rd.francetelecom.fr)
Date: Tue Jul 18 2000 - 11:09:50 EEST
> > 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.
fine algorithms exist for this, but you can never get too accurate with
noise or weird signals. Or get some predictive filtering with AI, which I
don't know how to compute realtime. Not all samples are pure, perfect sine
at 440 Hz. I mean, if I have a sine at 440 Hz and another one at 480Hz, what
pitch is this signal ? You need rather complex AI for this to determine if
you need to determine what pitch are here in a sound you don't know anything
about. What you have basically is a possible convolution of a signal
("instrument") by another one ("notes"). You need to remove the "instrument"
information from the complete one . Even when you do know the instrument
(which you don't here), it's difficult to make decisions. What if you have a
sine sin1(t), which pitch controlled by another sine sin2(t) ? (tremolo,
...) do you plan to recover the first easily ? What if sin1 is a noisy
signal ?
(hihat for example or a "shhhh" sample ...)
>
> > 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.
>
RMS is good of course. for a signal f(t), you need to know its power. but
RMS is static and slicing the signal may not be optimal for envelopes for
example. We really need to have a signal b(t) which represents the low
variations of the power of the signal.
f²(t) is the local power of the signal. sqrt(mean(f²(t))) is the root mean
square. but instead of making a mean(), we could lowpass this signal f²(t)
and make envelope detection. (because making the mean of a signal is a first
order lowpass filtering in fact)
> > 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)
This is really self correlation. You can get this accurately by multiplying
the signal with itself , delayed by delta, and summing the products of each
sample. this give you a (rather long to obtain ) value. let's call these
value(delta). now, it's a function. this function has peaks, for example, at
delta = 1s, delta = 2s and so on : then you signal is looped at 1s. this
works even with high noise. to make it realtime, you need a cray.
All of them are really lenghty algorithms and I would NOT include them
inline in the sample player.
Not that they are not good things to have. But I think to be really useful,
this has to be precomputed and not calculated "on the fly", because you
cannot do this accurately, I think.
They may belong to the ".raw data to .evo" guesser-app.
>
> > 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.
Of course, you have to apply a noise gate there.
> > 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 ...
rather agrees with this
but i would prefer to have basic computation on the kernel side, such as
envelopes, looping,
A cool feature would be pitching. Not by playing a sample faster. pitching
BY KEEPING THE SAMPLE ITS LENGTH. This may be useful in the common useful
denominator that could be this sampler. This can be done by granular
analysis/resynthesis. But (as everything about DSP) it is even more than
CPU-greedy. Or with good optimizations .... ?
This archive was generated by hypermail 2b28 : Tue Jul 18 2000 - 13:28:28 EEST