Subject: Re: [linux-audio-dev] ReLoop-style sample splitting?
From: Lance Blisters (geoff_AT_ugcs.caltech.edu)
Date: Mon May 28 2001 - 19:10:54 EEST
> split a short drum loop into smaller samples
I've been adding this functionality to GDAM - you drop a loop onto
the 'sampler' tool, and it is automatically split into pieces. One can
adjust the detection parameters until each drum hit is marked, or correct
markers by hand if the autodetect makes a mistake.
The marked-up loop is exported to our sequencer as a sequence of single
drum hits, each at their original place. From there cubase-style
sequencing is possible... move/copy samples along the time axis, or drag
a sample along the 'id' axis to change the drum hits it represents.
There are also 're-rhythm' controls, which classifies the location of
each drum hit within the rhythm of the original loop, and allows
sets of samples to be modified. For instance, you can have every
drum hit which falls on the downbeat play twice with a 1/4-beat delay,
while everything which falls on the upbeat gets shifted forward 1/8 beat.
This is a fun, easy way to tweak up your loops.
Currently, i do beat detection by walking over the waveform, tracking
amplitude and locking markers to waveform zero crossings. It is
functional, but i'd like to replace it with something stronger.... looking
at frequency-domain data is probably the way to go. Although my eyes
do very well detecting beats in time-domain data!! i just wish my algorithm
were as accurate ;)
I have not tried time-domain analysis of lo/band/hi-passed copies, but it
is a good idea. It might help pick up hi-hats which get "lost" under
bass or snare drums in the original waveform. In my experience, however,
any impact which isn't clearly visible in the original waveform, is
usually left part of the sample which is "hiding" it. i.e., a bass/hi-hat
sample rather than a clipped bass sample and a muddied hi-hat sample.
I had much better results working with the full data set than working with
an overview.
I once kept a length for each sample, but now i simply keep start times, and
the length is the time until the next sample begins or the loop ends.
A bpm-guessing algorithm is certainly more difficult than a beat-detection
algorithm, and i've not seen one which is useful for rhythmically complicated
music. All it would tell you is the phase, tempo, and length in beats
of the loop... with most loops, this is already known. Besides, a successful
beat-detection algorithm will mark each beat regardless of the beat's
place within the loop, or the tempo of the loop... so knowing these
values doesn't help at all.
GDAM's sampler is still under development. It is available in cvs and
the most recent gdam packages, run gdam-launcher with "--define unstable"
to try it out. The beat-detection code is a little outdated, I've been
making improvements which haven't made it into CVS yet.
-geoff
> Hi,
> I was thinking for a few days about ways to split a short drum loop into
> a couple of smaller samples which should ideally begin at the bass,
> snare, hihat etc. points. I'm wondering what the best way would be to
> find this out - it's basically what ReLoop from the Propellerheads does,
> and judging from their freely available demo version, it's not too
> computationally complex - you can move a round a "coarseness" slider,
> and it will insert additional split points almost instantly.
>
> My first ideas would be to do something like:
> - Produce a shorter "overview file" of the loop so I have less data to
> look at
> - make a few copies (3 e.g.), of which one is filtered low-pass to find
> the bass drum, one band-pass filtered for the snares and one high-pass
> filtered for hihats/crash cymbals.
> - Now look through the data left-to-right and create some kind of
> histogram of energy over time so I can seperate the real hits from the
> remaining "noise".
> - In the end fine-tune the start/length value pairs so they align nicely
> with the original-size sample. Here I'd probably take some approach of
> looking at the differences between single sample points (in a small
> range of time) to find where "the kick takes off".
>
> Is this a feasible approach? If not, what flaws are in there, or what
> superior methods can you think of to perform this task? Please let me
> know of any ideas. E.g., I was also thinking if a speed detection
> algorithm (determine BPM) should be run first.
>
> Thanks,
> Frank
> --
> Frank Neumann (Frank.Neumann_AT_st.com), VIONA Development Center
> ST Microelectronics, Karlstra_e 27, 76133 Karlsruhe
This archive was generated by hypermail 2b28 : Mon May 28 2001 - 20:44:48 EEST