[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Date Index][Thread Index][Author Index]

RE: 1st Loop Workaround in Ableton's LIVE 4.0

Maybe we're actually saying the same thing and I'm just reacting
strongly to the phrase "virtually impossible." Yes, it would have to be
a new "first loop feature" but no, I don't understand why it would be
programming stretch, because Live already wants to know how long your
loops are (# of beats) anyway. It would be as simple as adding a feature
that sez: 
extract tempo from this loop, given this loop length in # of beats,
which would replace typing a new tempo into the tempo field. The only
thing you would need to deal with in terms of a first loop function
would be the ability to define # of beats for the newly recorded loop
before and/or after it has been recorded. 
AND/OR, it could be an ongoing setting, replacing other sync settings,
wherein ONE looped sample, does not have the granulation applied, but
instead acts as the master tempo sync for the rest of the samples.

I know it would require additional coding, I just think (from my layman
POV) that such coding should be relatively concise and straightforward.
And that the feature could actually come in handy for quite a few people
other than live loop fanatics. Often in a production setting I have a
loop I would like to use as a master, and as such I would prefer that it
not be granulated (even subtly), and that all the other loops sync to

-- Sarth

> -----Original Message-----
> From: Tias [mailto:tias@condomo.com]
> Sent: Tuesday, June 08, 2004 3:21 AM
> To: Loopers-Delight@loopers-delight.com
> Subject: Re: 1st Loop Workaround in Ableton's LIVE 4.0
> > With all deference to your greater expertise, I don't believe this
> > true. Perhaps I misunderstand what you are explaining,
> Indeed you must have missunderstood. Let's say you have a sample of a
> quitar-accord that is 2 seconds long. How do you decide what tempo
> sample is? It could be 1 BPM or it could be 100 BPM.
> There's no tempo reference in the sample what so ever, so to be able
> calculate a tempo you simply have to decide what base in meassures you
> working in (this is what you do in the EDP). So you say: "Ok, my
> tempo-base for the first thing i record is 1 beat long." - This
results in
> the tempo for the sample beeing 1 beat in 2 seconds and the resulting
> tempo
> beeing 30 BPM.
> Now instead, this is what Live does when you record a new sample. It
> allready have the Tempo (for example, 120 bpm) and then it sets the
> recorded Unstretched sample to 120 bpm. Then if you decide to change
> tempo to 60bpm, Live pretty much calculates that it has to chop up the
> sample is little bits (grains) and then play each bit 2 times over,
> giving you a timestretched sample with that Chopped up effect
> The timestretching method is called Timestretching by Granular
> and
> that is indeed based on sample-length in the Tempo-domain and not the
> Time-domain.
> > Live has the ability to defeat the time-stretching functionality on
> > sample. So having the software extract the tempo from the object
> > on a non-timestretched sample should actually be a relatively simple
> > task. This is a one-click operation in Logic, a drag and drop in
> > and a two footswitch press on the Adrenalinn.
> >
> > Cheers,
> >
> > -- Sarth
> >
> > >
> > > And the problem is that the Ableton Live time-stretch engine is
> > > based,
> > > that is, it takes the current tempo and "lock" the recorded sample
> > that
> > > tempo and then use that as a base for the realtime time-stretching
> > > calculations.
> > >
> > > So based on this it's virtually impossible to include a first loop
> > > function
> > > into Live unless they rewrite the whole sample-engine. OR just add
> > > separate FirstLoop function that can be turned on instead of the
> > > Tap-function.
> > >