TEMPO MAPPING !!!

[pjeudy]

Inspired Music Making with Discover and Reason


https://www.youtube.com/watch?v=at33phHJOcA

TEMPO MAPPING !!! Maybe some of you knew this already..but that's a cool trick for me to learn.

[Ronin]

This is new



wait a sec.....

[pjeudy]

This is new



wait a sec.....

To me it was ! Not sure if it's old news..to you guys. Might be logical from there point of view to show people how to do this trick, specially when a singer is recording live into TAKE at a grocery store or while driving with no Tempo. Ergo TEMPO MAPPING  :s0238:  I was doing it the other way around..will try this method, seems to offer a smoother Sync!

[Gaja]

This is new



wait a sec.....

To me it was ! Not sure if it's old news..to you guys. Might be logical from there point of view to show people how to do this trick, specially when a singer is recording live into TAKE at a grocery store or while driving with no Tempo. Ergo TEMPO MAPPING  :s0238:  I was doing it the other way around..will try this method, seems to offer a smoother Sync!

I think he meant that this video has been posted something like six times in the last few days. It's an amazing video showcasing an amazing technique to get control over out of sync material.

[pjeudy]

Aah got it..

[selig]

There's also this video (see below), showing how you can do exactly the same thing to the same source file in a fraction of the time. I made it as a "response video" to Ryan's to show that his approach isn't without it's "issues"!

One "issue" with Ryan's approach is that IF you need to to any further timing correction, you are no longer working on the original source file - you are stretching a file that's already been stretched. I'm the type of person who often changes my mind, so this approach isn't for me.

By using the more common "line it up and quantize" approach you're not only using the same technique you may already know from working with MIDI tracks, you're keeping the original audio since there's no "bounce to new recordings" stage involved. You can keep adjusting timing without further artifacts from stretching being introduced, which is even more important when you have a vocal in a track but can't use the awesome "vocal" stretch algorithm (because there's also a guitar in the mix). 

Just my 2 cents - learn something new, or use techniques you are probably already good at. Here's my video:

[pjeudy]

A fraction of the time Selig?! Great,TEMPO MAPPING can be time consuming. I will take a look at youre method.

[Theo.M]

A fraction of the time Selig?! Great,TEMPO MAPPING can be time consuming. I will take a look at youre method.

What Giles has done is cut the blank part of the file, moved it so the start time of the part is snapped to a bar and hit quantise. This works only because the original take was indeed apparently recorded against a click at specific tempo, and Ryan was mistaken that it hadn't.

Ryan's method is the most valid for certain scenarios, particularly when the original audio has tempo fluctuation. Ryan has showed us how to properly tempo map in Reason.
Giles method is the one to use when there is a basic tempo present but you just want to tighten up the timing.

[selig]

A fraction of the time Selig?! Great,TEMPO MAPPING can be time consuming. I will take a look at youre method.

What Giles has done is cut the blank part of the file, moved it so the start time of the part is snapped to a bar and hit quantise. This works only because the original take was indeed apparently recorded against a click at specific tempo, and Ryan was mistaken that it hadn't.

Ryan's method is the most valid for certain scenarios, particularly when the original audio has

tempo fluctuation

. Ryan has showed us how to properly tempo map in Reason.
Giles method is the one to use when there is a basic tempo present but you just want to tighten up the timing.

Great points! But there's more…

I use my method all the time on non-tempo files - just used it on a MIDI and audio file a few days ago with great success. With Ryan's approach, unless you align each and every beat you'll not get precise timing. This leads to often needing further correction later, which unfortunately means you are stretching an already stretched audio file. 

If you just align slices visually (to get close) and then only quantize (if needed), you are always operating on the original audio file. Again, with Ryan's method you are stretching twice if you do ANYTHING after the tempo correction. This is made worse on a file that has guitar and vocal, since you can't use the preferred "vocal" algorithm and probably don't want to stretch a vocal twice using the "all around" algorithm. 

The slice method isn't any more work than Ryan's - the most impressive thing about Ryan's method IMO is that most folks wouldn't think it WOULD work (technically). But the actual workflow has "issues" (mentioned above) that aren't obvious to some. I'm just pointing out that there are other methods to align non-tempo audio/MIDI which would be preferable to many if they were aware of all the issues. 

I'm all about the "non-destructive"! 

[selig]

A fraction of the time Selig?! Great,TEMPO MAPPING can be time consuming. I will take a look at youre method.

Sorry if I wasn't more clear - this method is only THIS quick because the original file is not a "non-tempo" file. But there are other reasons to want to avoid the tempo technique, mainly the fact that any further stretching is applied to an already stretched file and not the original.

[Theo.M]

If you just align slices visually (to get close) and then only quantize (if needed), you are always operating on the original audio file.

well I am lost then. Doesn't aligning slices use stretch anyway?

[Gaja]

A fraction of the time Selig?! Great,TEMPO MAPPING can be time consuming. I will take a look at youre method.

Sorry if I wasn't more clear - this method is only THIS quick because the original file is not a "non-tempo" file. But there are other reasons to want to avoid the tempo technique, mainly the fact that any further stretching is applied to an already stretched file and not the original.

what if we combine the approaches? Map out the tempo like Ryan did and instead of bouncing to new recording, you quantize the audio (I haven't tried either approach, so I'm just guessing)?

[selig]

If you just align slices visually (to get close) and then only quantize (if needed), you are always operating on the original audio file.

well I am lost then. Doesn't aligning slices use stretch anyway?

Yes, but non-destructively. Once you bounce to new recordings, you are starting over and adding any artifacts to any existing artifacts. Make sense?

[LudvigC]

Hi,

well no, it doesn't really make sense to me actually.

As far as I can tell, Ryan does 1 "bounce to new recording" and so do you. In both cases, this is done before anything has been stretched (audio clip still has Stretch Disabled at this point). No artifacts added at this point.

What the "Bounce to New Recording" does here is create a new audio recording (playing back exactly like the original, but with start trimmed), and stamps the current tempo map into that recording. In Ryan's case, this is a varying tempo map, in your case it's a static value of 55 bpm. After this, you quantize, which is another way of changing the tempo map in the recording.

In both cases you can keep on adjusting the timing (slicing or scaling) and/or the tempo - the audio will be re-stretched on the fly, based on the recording created by "Bounce to New Recording" earlier. The recording itself isn't affected by these timing and tempo changes.

So, to my eyes, both methods are equally non-destructive. Am I missing something?

Cheers / LudvigC

[LudvigC]

Reading the above, I realize that not all users may understand how stretch works in Reason.

It's like this:

* Each audio recording includes a tempo map - like a tempo automation curve that spans the whole recording. In many cases this is a "straight line" - a single tempo value, but it can also be varying.
* A Reason song also has a tempo map, again either a static value or varying tempo automation.

* When you place an audio clip (with Stretch Enabled) on a position in the song, Reason looks at the tempo map inside each audio recording in the clip, and compares this to the song's tempo map at the same position.
* If the audio recording's tempo is different from the song's tempo, Reason stretches the audio so that it fits.

* The stretch is done on the fly so you can hear it right away, but in the background a high-quality stretched version is rendered. The result is a new audio file, which is stored in the scratch disk folder. When done, Reason starts reading from that file.
* However the original recording is still in the song file, and remains there unaffected. If you change tempo and timing later, the audio will be stretched again, working from the original recording.

Ways of stretching:

* If you change the song tempo, this will cause a difference between the audio recording's tempo and the song tempo. The audio will be stretched to fit.
* If you use the Scale Tempo function on a clip (or resize it with Option / Ctrl pressed), you will scale the audio recording's tempo map. Again causing a difference compared to the song tempo = stretch time.
* Quantizing slices or moving them manually is a way of editing the tempo map in the audio recording. Again causing a difference and resulting in stretch.

/ LudvigC

[Theo.M]

If you just align slices visually (to get close) and then only quantize (if needed), you are always operating on the original audio file.

well I am lost then. Doesn't aligning slices use stretch anyway?

Yes, but non-destructively. Once you bounce to new recordings, you are starting over and adding any artifacts to any existing artifacts. Make sense?

Ludvig's explanation helped, but I am not sure regardless that i understand your method.. there has been a song i have been wanting to remix for a while - I effectively isolated the vocals to a reasonable quality, but i haven't been able to work out the tempo. I got it close with tap tempo agains the original song but it's not quite right. Just dragging where the audio starts and hitting quantize at the closest tempo i have so far to it does not make it usable.

The method shown in the video does. Could you perhaps do a more detailed video, if you get any time, showing more uses for your method? Or is it only in the case when one already knows the tempo of the file?

[pushedbutton]

It would be cool if you could import audio, correct the tempo to work with then in some way undo the original mapping so that reason yielded to the original drift....or would that just sound crap?

[FATCheese]

This is a really great tutorial!

Thanks Ryan & Giles!

[kloeckno]

It would be cool if you could import audio, correct the tempo to work with then in some way undo the original mapping so that reason yielded to the original drift....or would that just sound crap?

If you leave the tempo automation, then the sequencer will drift with the recording like you want. Just don't do the part where you bounce the clip to a new recording and don't delete the automation lane.

[Ostermilk]

The method Ryan is using is very akin to a method I've been using for years and is guaranteed to work on any material. 

On this particular example it was an easy fix to find the original intended tempo and quantize to that but you will find as Theo and myself clearly have where a straight quantize simply won't work. whereas with Ryan's method it always will.

How I used to do it was simply play midi quarter notes along with the audio I wanted to map and generate a tempo map from that.  A few years ago I came across a java tool that took all the messing about out of that process after reading this article.

http://soundbytesmag.net/tempo-thelastdawfrontier/

On that page is a little tool called Maestrolizer which is a little Java app that will calculate a tempo map from you simply tapping in time to the music.  I still use this MaestrolizerExecutable.jar to create a ball-park tempo map (midi import it into Reason) for the audio I'm going to import then it's a case of just fine tuning that map in exacty the same way as Ryan describes to get it all bang on.

Sometimes it's easier just to use Ryan's method completely as described if the tempo is reasonably constant but if you can 'feel' the quarter notes when the tempo is very varied you might find the ball-park tempo map a better place to start from.

[selig]

It would be cool if you could import audio, correct the tempo to work with then in some way undo the original mapping so that reason yielded to the original drift....or would that just sound crap?

If you leave the tempo automation, then the sequencer will drift with the recording like you want. Just don't do the part where you bounce the clip to a new recording and don't delete the automation lane.

Yes and yes. Yes you can (as kloeckno says) and yes it will more than likely sound like crap if you load up a drum loop etc.

However, that's not the only use for that technique - in fact, this is exactly how you prepare a MIDI performance so you can print sheet music for a session, if it wasn't recorded to the click in the first place. I've done piano/string projects where the piano part is extremely rubato (no strict tempo). Before you start writing the string parts, you record a click (MIDI or Audio) and use something like Beat Detective to re-map the tempo to this new click automatically. This is handy in Reason as it allows you to fill in beats between notes and provide a downbeat even if nothing plays on that beat, and I suggest it for important "re-timing" projects. Then you can record the MIDI string mockup and when you print the score the notes and bar lines will fall on all of the right beats.

The only difference in Reason is that you have to do this manually! This is the one place where Tempo Mapping really shines IMO, and where I use it frequently with great success. 

[Gaja]

Well I have tried the tempo mapping on a very off tempo project, and it was pretty intense. He intentionally changes tempo once, and unintentionally all the time. He had a tempo range from 80 something to 200. I have a drum loop to go along his tempo, and it's pretty funny... If you have time stretch enabled, you can hear the changes by the intensity of the artifacts. Funny stuff...

[pjeudy]

A fraction of the time Selig?! Great,TEMPO MAPPING can be time consuming. I will take a look at youre method.

Sorry if I wasn't more clear - this method is only THIS quick because the original file is not a "non-tempo" file. But there are other reasons to want to avoid the tempo technique, mainly the fact that any further stretching is applied to an already stretched file and not the original.

Got it.Yea the method you described is how I used to tempo Map..basically I would find the relative tempo of the vocal using the Tap Tempo button,Import the Wave audio (vocal) at the that tempo, then slice and slide it to make it fit!,.

Works best like TheoM and you say if the tempo is more or less on a click,I'll use the method in Props video if the vocal sample is all over the place as in the case of old disco and Soul records etc...from back in the day! Thanks to you both!

[mbfrancis]

None of these methods are optimal for building a tempo map for a song with tempo fluctuations.  It's pretty standard in other DAWs for >10 years that you can play in a MIDI click over the audio and then build the map from that, which is really the optimal solution, no?  Ryan's method works, but seems tedious.  

Rendering a time-corrected file is cool though, didn't know about that.

[Gaja]

None of these methods are optimal for building a tempo map for a song with tempo fluctuations.  It's pretty standard in other DAWs for >10 years that you can play in a MIDI click over the audio and then build the map from that, which is really the optimal solution, no?  Ryan's method works, but seems tedious.  

Rendering a time-corrected file is cool though, didn't know about that.

From what I understand the methods differ in the fact that with Reason you can decide whether or not you want to keep the tempo changes, even though it enables you to actually have a quantizable grid in time with the tempo changes. As opposed to a click with tempo changes that is quite as predictable as a song with tempo changes without a click.