changing tempo without loosing sync points

[TBR]

Hi,

 

I'm working on a 5 episode tv series. I'd like to have all the episodes in 1 session in Logic. But now when I change the tempo of a part in the beginning, everything after that gets screwed regarding there sync points. Sure I can lock the regions so they will stay put on the correct timecode, but the other tempo changes and the beats all change.

Does somebody know how too do this correctly?

Thanks, TBR

 

 

____________________________________________________________________

8-core: Two 2.66GHz Quad-Core Intel Xeon 5500 series processors

OS X 10.6.2

16 GB RAM

____________________________________________________________________

[fuzzfilth]

Unless you score everything with the same three sounds and always the same tempo, one big Project will inevitably morph into an unmanageable monster.

 

You use one Project per episode. Actually, you use one Project per cue. I'm serious.

You bounce the mixes or stems in the separate Projects and then assemble just those in one long 120bpm Project per episode, then generate an OMF from that.

 

Christian

[TBR]

I think the amount of music with the given instruments allows me to keep everything in 1 session. The good thing is that I can easily "steel" melodies or sections from the other episodes. Besides it helps me to keep a flow.

The only thing I don't know how to solve is this tempo issue. You say there is no way around this?

 

TBR

[fuzzfilth]

No.

 

Christian

[Jordi Torres]

I think you should listen to Mr. fuzzfilth.

If you're on Logic 9, it's easy to "steel" melodies, etc from other Logic projects using the new "Importing Data from Another Project" feature.

 

Regards,

 

J.

[TBR]

1 session for 1 episode is something I could work with, but 1 session for every cue? How are you suppose to see the music in the big picture, you have to bounce all the time and paste it in a test session. I want to see it all and then fine tune or radically change stuff .....

TBR

[ghostly]

You can automate tempo. Or am I understanding the problem all wrong?

[TBR]

the problems is that when I change the tempo in the beginning, using the tempo automation in the global track on top of the edit window, the absolute location of edit points in this same automation track further on change to. If only you could lock an single automation point .......

TBR

[fuzzfilth]

1 session for 1 episode is something I could work with, but 1 session for every cue? How are you suppose to see the music in the big picture, you have to bounce all the time and paste it in a test session. I want to see it all and then fine tune or radically change stuff .....

TBR

 

It obviously depends on the size of the project you're working on. For a feature film, you sit down with the director and spot the movie, that is, you agree where music starts and stops and what it should do emotionally. This can easily be 70-130 separate cues. There is no way on earth you can do this in one single Project.

Also, it is here where you outline the dramaturgical development of the music with/against/lateral to the dramaturgical development of the plot/characters, etc. This is the big picture you're working towards.

 

Then you begin filling this skeleton with music. Could be sequentially, could be non-linear sorted by theme, could even be backwards, depending on your approach.

 

Then, and in parallel to working on new cues, you have the approval phase where you send bits and pieces to the director and get change demands in return. By now you're already in tempo and meter changes knee deep, for several cues at once cause they need it now and by the way when is the new stuff arriving anyway cause we need that too ?

Doing changes in cues 5, 12 and 23 is easy if they are in separate Projects as outlined earlier, but it will be a total nightmare in one large Project, given that you're already in an altered state by sleep deprivation.

 

But you knew that already.

 

Christian

[45rpm]

when I change the tempo of a part in the beginning, everything after that gets screwed regarding there sync points

 

I ran into what sounds like the same problem. And it was not a long composition. The duration was about 10 minutes, but there were lots of tempo changes. When I fiddled with tempo changes in the first 1-2 minutes of the project, I noticed that certain subsequent regions got messed up. But some other regions were OK. I tried really hard to figure out why, but I couldn't. I also couldn't recreate a bug in a consistent way.

 

I ran into the same thing when I cut/insert time early in the project (and I remember seeing a similar report on this forum).

 

Now I keep plenty of backups, especially when I make a change like that (because I don't want to rely completely on Logic's own undo/backup system).

 

I think Christian is right, that you're asking for trouble by putting everything in one project. But I understand your motivation for doing so. Maybe you can get away with it, as long as you keep lots of backups, and are especially careful with certain kinds of changes. Now when I make tempo changes, I try to do a spot-check audition of the rest of the project (subsequent to the edit), to hear if something got messed up. I find that when the problem happens, many (but not all) regions are affected, and it's really easy to hear. It sounds like certain band members came back from lunch drunk. (I guess we could all it the Drunk Lunch Simulator and treat it as a feature.)

 

the problems is that when I change the tempo in the beginning, using the tempo automation in the global track on top of the edit window, the absolute location of edit points in this same automation track further on change to.

 

Are you sure it's that simple? I think the bug I ran into is more complicated than that, because only certain regions were affected, while other regions were not affected. Even though the regions were at the same point in the arrangement, and were of a similar type. I think it had to do with whether the region had ever been copied from some other place in the arrangement, or something weird like that.

[ski]

Trust the voices of experience here and do not attempt to use the same song for an entire episode. Sure, it's possible to write multiple cues in one project, but it's highly inadvisable for many of the reasons already expressed here.

 

I ran into what sounds like the same problem. And it was not a long composition. The duration was about 10 minutes, but there were lots of tempo changes. When I fiddled with tempo changes in the first 1-2 minutes of the project, I noticed that certain subsequent regions got messed up. But some other regions were OK. I tried really hard to figure out why, but I couldn't. I also couldn't recreate a bug in a consistent way.

 

This is totally understandable and not a bug AFAICT. If you mess with the tempo at the beginning of a project, what else would you expect other than for the remainder of the song to move? If nothing else, the sections that come afterward would definitely move unless, prior to moving the, you SMPTE-locked them, or, their regions started from the very beginning of the piece. So I don't think there's much of a mystery.

 

[EDIT: See below for correction]

So the only way to affect with this kind of tempo change is to first SMPTE-lock all events AND automation from the point AFTER you want to mess with the tempo. Then you can change the tempo in the beginning and the rest of the music will occur earlier or later than it did before, but, it remain in sync with itself. If the music after the point of change is out of sync with picture, then it's up to you, the composer, to bridge the gap (whether it ends up being shorter or longer) compositionally.

[Illyaas]

Hello, I think I can help.....

 

What you are trying to do is possible in logic 8 and 9. I don't know if putting all 5 episodes in one session is the best idea but one episode is no problem at all no mater how many cues, and with that said the 5 episodes in one session could work if you work in order from beginning to end. I will try to explain.......

 

In logic you can on your global video track you have an option to detect scene cuts so when the film director tells you that he wants a music cue at a certain scene cut that happens at a specific SMPTE time say, 01:00:30:00 you can place your playhead near that SMPTE time and then make a selection on any track in your session around that play head with your marquee tool and then tell the global track to detect the scene cut. Hopefully it will look at the video and find the scene cut and create a scene marker on our global marker track. if it doesn't you can always add a marker at the exact spot your self. Either way the marker is mandatory to make this work.

 

So lets say the first music cue happens right at the beginning of the film at 01:00:00:00 in SMPTE time code. So you compose your first cue there and set the tempo of your session to how ever you want that cue to feel. Now when you get to the second cue at the scene cut that the director wants at 01:00:30:00 and you have your scene marker created by detecting your scene cut. You will use that scene marker with global beat mapping track to align the specific Scene cut to the first beat of a measure to start creating your second cue at that point (lets say that measure is bar 7). Now what's going to happen is Logic is going to adjust the tempo of your first cue by some amount, usually not significant enough to feel different (depending on how far away from the end of your last cue you beat mapped your scene marker). Once you align the scene marker to the measure that you want to create your second cue you can start creating your cue at that measure and it will always be in line with the scene cut that the director asked you to create the music at.

 

Ok, now if you want to change the tempo of the music in the second cue your your global tempo track you need to double click on the grid line that is aligned with the scene you mapped to the first beat of measure 7. When you double click at that point the tempo track will create a node which will allow you to adjust the tempo of your second cue without affecting the tempo of the first cue. You can continue this process for the whole episode and theoretically all 5 episodes (though I question how you imported 5 different videos into one session).

 

Here is the rule that you have to follow. You have to work from left to right with your tempo mapping. in other words you have to do your first cue, set the tempo for that, map your next cue, create at node for the tempo track and set the tempo for that cue and keeping working to your right. IF YOU GO BACK AND CHANGE THE TEMPO OF A CUE TO THE LEFT OF ONE OF YOUR CUES IT WILL TAKE EVERYTHING OUT OF SYNC.

 

I know thats a lot and maybe confusing but it works, I use it all the time and actually teach it as part of the certification class for Logic Pro. If you have Davids Logic 8 certification book it is lesson 11 scoring movies. It is not in the Logic 9 certification book for level 1. I think it will be in the Advanced Logic 9 certification book.

 

Let me know if this helps. If you need more clarification maybe I can do a video that demonstrates it but I probably wont be able to do it until after the holidays.

 

Good Luck

[45rpm]

If you mess with the tempo at the beginning of a project, what else would you expect other than for the remainder of the song to move?

 

I appreciate this chance to learn something from you, so let me describe my scenario more clearly, in simplified form.

 

Imagine a song with a length of 100 bars. There is a global tempo track indicating that the tempo for bars 1-4 is 80, and the tempo for bars 5-100 is 120.

 

The song contains 10 tracks. Tracks 1-5 are audio, and tracks 6-10 are software instruments.

 

Tracks 1-5 contain, respectively, regions A-E. These regions are one bar in length, and appear in bar 99. They are blue Apple Loops.

 

Tracks 6-10 contain, respectively, regions F-J. These regions are one bar in length, and appear in bar 99. They are green Apple Loops.

 

Audition bar 99. All 10 regions are playing in time, relative to each other, and relative to Logic's grid (as expressed by Logic's metronome).

 

Now alter the global tempo track so that the tempo for bar 1 is 90, instead of 80. The tempo for bars 2-4 is still 80, and the tempo for bars 5-100 is still 120.

 

Now audition bar 99 again. It should sound exactly the way it did during the first audition, right? And that is indeed what happens when I create this scenario in a simple test file. But when I tried this in actual project (with about 30 tracks containing 100-200 regions), I got something like the following result: regions A, C, E, G and I were all shifted slightly. The shift was visible and audible. They were now in time relative to each other, but not in time relative to B, D, F, H and J, and not in time relative to Logic's grid.

 

It was easy enough to snap them back into position, except for the fact that there were so many of them, and the fact that some regions were effected and others were not, according to a pattern I could not decipher.

 

what else would you expect other than for the remainder of the song to move?

 

It depends how you define "move." Yes, I expect the remainder of the song to "move" in the sense that the time elapsed between bar 1 (first beat) and bar 99 (first beat) is not the same as it was before (if one were to sit and listen to playback for the whole song). But I expect all the regions that used to start exactly at bar 99 (first beat) to still start exactly at that position. And that's what happens when I create this scenario in a simple test.

 

If nothing else, the sections that come afterward would definitely move unless, prior to moving the, you SMPTE-locked them

 

With all due respect, I think you have it backwards. In the above scenario, if I SMPTE-lock region A, and then make a change to the tempo for bar 1, the lock will have the following effect: region A will no longer start at bar 99 (first beat). It will have moved, musically. It is locked in the following sense: it appears at the same position, if one measures the elapsed time between the start of the song and the start of region A.

 

So the word "move" is ambiguous and confusing, because we don't know if it means relative to a musical grid, or relative to an absolute time scale.

 

So the only way to affect with this kind of tempo change is to first SMPTE-lock all events AND automation from the point AFTER you want to mess with the tempo. Then you can change the tempo in the beginning and the rest of the music will occur earlier or later than it did before, but, it remain in sync with itself.

 

If I SMPTE-lock region A, and then change the tempo for bar 1 (i.e., only for bar 1), region A will then NOT occur "earlier or later than it did before," if by "earlier or later" we mean at a different position on an absolute time scale. If region A used to play exactly 43 seconds after the song began, it will still play at exactly that time (and that's the whole point of using SMPTE-lock: to maintain sync with a film that is presenting a specific event at a specific moment). And I don't know what you mean by "remain in sync with itself." Because it will now definitely be out of sync with Logic's musical grid.

 

If I want region A to be locked (with regard to absolute time), and I also want to change the tempo in bar 1 (i.e., only for bar 1), and also have region A still be sitting properly on Logic's musical grid, I have to insert a compensating tempo change somewhere prior to bar 99. And this is closely related to what the manual is talking about on p. 1191 ("Positioning Bars to Frames").

 

If the music after the point of change is out of sync with picture, then it's up to you, the composer, to bridge the gap (whether it ends up being shorter or longer) compositionally.

 

Yes, and bridging the gap compositionally can mean doing something as simple as inserting a special 1-bar tempo during some silent passage.

 

I understand that, and I think TBR understands that. And I realize he's doing a score, and he has to keep that issue in mind. In my example, I wasn't doing a score, so the issues are different. But I think that's all beside the point. The point is that I saw Logic move regions when it shouldn't. And I think TBR saw the same thing.

 

IF YOU GO BACK AND CHANGE THE TEMPO OF A CUE TO THE LEFT OF ONE OF YOUR CUES IT WILL TAKE EVERYTHING OUT OF SYNC.

 

I think it would be helpful to define what we mean by "sync." Yes, obviously if we change the tempo for bar 1 (i.e., only for bar 1), bar 99 will appear at a different point in absolute time, which means it will be out of sync with the film. But I can fix this by inserting a compensating tempo change that is, let's say, 1 bar in duration and appears in bar 98.

 

So it really shouldn't be necessary to do a score strictly from left to right, as long as one understands the importance of inserting a compensating tempo change later in the arrangement, when altering a tempo early in the arrangement.

 

I suppose it's possible that this is TBR's problem, that he doesn't understand this. In that case, I misunderstood him. I thought he was seeing what I was seeing: a situation where certain regions shifted for no reason I could comprehend. Not relative to the film; rather, they shifted relative to Logic's musical grid.

 

So think there are two possibilities: TBR and I are both seeing the same bug, or TBR shouldn't be told he has to work strictly from left to right. Instead, he should be told that he needs to understand the importance of inserting a compensating tempo change when he makes certain tempo edits.

 

If I understand how to insert a compensating tempo change, I can get Cue 2 back into the right position (relative to the film) even if I've just recomposed Cue 1 and made a bunch of fresh tempo changes to it. That is, if there isn't a bug. And maybe there isn't one, and I was just doing something wrong. But if there's no bug, how come no one has advised TBR to solve his problem by inserting a compensating tempo change? And the technique on p. 1191 is a way to do this automatically, i.e., without resorting to trial and error.

 

One more thing:

 

Now what's going to happen is Logic is going to adjust the tempo of your first cue by some amount, usually not significant enough to feel different (depending on how far away from the end of your last cue you beat mapped your scene marker).

 

If I create a new tempo node just to the left of Cue 2 (say, one measure back), then Logic won't alter the tempo of Cue 1. It will simply calculate a special tempo for that one measure (and hopefully that measure is a rest, or I can pick some other spot where there is a rest). This is the compensating tempo change I'm talking about.

[ski]

I'd love to give your post the reply it deserves, but I'm short on time right now. I'll just address two points...

 

Here's what I'm talking about... if you change the tempo of an existing project (one that contains regions which don't start at bar 1) and you don't first SMPTE-lock your regions, they will slip against picture.

 

I'll put it another way... if you record something at bar 99 and then you change the tempo of the song after the fact somewhere before bar 99, the region remains at bar 99, but it will have slipped against picture.

 

And that's all I think there is to be concerned with... Example: where does bar 99 (or whatever bar) start at? Oh, OK, 02:44:09:11. But I've changed the tempo, so now where does it start? In the wrong place. So now I have to do what's necessary to get bar 99 to be at 02:44:09:11 again.

 

Second... I never use apple loops so I can't report on how they behave. Maybe they're buggy when it comes to this kind of thing? I dunno... So please take my comments above as "the behavior you can expect when dealing with normal audio and MIDI regions".

 

Gotta run, more later.

[fuzzfilth]

SMPTE-locking events might look promising at first since it prevents them from slipping when upstream tempo events are changed, but believe me, you don't want that because now they're off Logic's bar and meter grid and if you think 'well, I don't care, it's done already', so rest assured, you will be asked to rework that part in a few hours time.

 

That was a four-line-sentence and it will be my final say in this thread.

 

Have fun.

 

Christian

[45rpm]

if you change the tempo of an existing project (one that contains regions which don't start at bar 1) and you don't first SMPTE-lock your regions, they will slip against picture.

 

Exactly. I get that. Does TBR get that? I don't know.

 

So now I have to do what's necessary to get bar 99 to be at 02:44:09:11 again.

 

Exactly. And that's what you meant by bridging the gap compositionally.

 

I never use apple loops so I can't report on how they behave. Maybe they're buggy when it comes to this kind of thing? I dunno

 

I expect that maybe they are. And it's possible that my issue and TBR's issue are completely unrelated.

 

As far as bridging the gap compositionally, I said that Logic can help me do that automatically. I think it might be helpful (for me and others) if I describe clearly what I mean by that. So here's a quick tutorial on how to get Logic to automatically calculate a compensating tempo change for you, so you can fiddle with Cue 1's tempo all you like, and still end up with Cue 2 in sync with the film (and also sitting on the grid properly).

 

You have Cue 1 and Cue 2 in place, and you want to insert a bunch of new tempos in Cue 1. Before you do that, make a note of Cue 2's SMPTE position, because that's going to change, and you want to be able to restore it.

 

To note Cue 2's SMPTE position, put the playhead exactly at Cue 2. Double-click on the SMPTE indicator in the transport. Press cmd-C for copy. (There's no need to highlight the numbers. In fact, it's not possible to highlight the numbers. But cmd-C will copy them to the Mac clipboard.) Now you can paste the numbers in your Project Notes or Track Notes.

 

Now proceed to make a bunch of tempo changes in Cue 1. (Presumably you are using nodes correctly to make sure those changes don't extend into Cue 2. Of course it's ultimately legitimate to do that, but it would complicate this tutorial.) You will notice that Cue 2 has maintained its position on the musical grid, but it now has an incorrect SMPTE position. We will now fix that, as follows.

 

Make sure that Cue 2 is preceded by at least one measure of rest. (It's possible to have music in that bar, but the explanation is simpler if we assume a rest.) Now place the playhead one measure prior to Cue 2. Open the Tempo List (Options/Tempo/Open Tempo List). Press "Create." A new tempo event (i.e., node) has been created at this position. It does not yet express a tempo change, but in a moment it will.

 

Now place the playhead exactly at Cue 2. Again, press "Create." Another tempo event (i.e., node) has been created. In this new tempo event (in the Tempo list), double-click in the column "SMPTE Position," to edit that number. Paste the number you had previously noted, and press return to accept the change (there's no need to highlight the old number; just double-click and then paste).

 

What Logic has just done automatically is edit the prior tempo event (that is, the one that is one measure back) in such a way as to restore Cue 2 to the correct position relative to absolute time (i.e., the film and SMPTE). All my special tempos in Cue 1 have been preserved. What I have is one special (silent) measure with a special tempo.

 

The Tempo track doesn't need to be open to do this, but if it's open it's easier to see and understand what's happening.

 

This is essentially derived from a technique that is described on pages 1191-1192.

 

I also could have fixed Cue 2 in position using SMPTE lock. Why didn't I do that? The technique I described has two advantages: A) Relying on SMPTE lock in this situation means I have to select every single region in Cue 2 and beyond. What if I miss one? I'd rather not have to worry about that. B) If I used SMPTE lock, Cue 2 and beyond will remain in sync with the film, but they will no longer be lined up with Logic's musical grid. (This is exactly the problem Christian mentioned: "you don't want that because now they're off Logic's bar and meter grid.") Trouble is, I want both: I want everything to sync with the film, and I also want everything sitting on the grid properly. Even though I went back to Cue 1 and inserted a bunch of special tempos.

 

To achieve that, I need to insert a compensating special tempo, and this technique gets Logic to automatically calculate that special tempo for me.

 

And if I understand this technique, there should be no need to work strictly from left to right, correct? I think there are other issues with putting a very long score inside a single project, but this particular issue is manageable, right?

[ski]

What I had to do I don't have to do now (i.e., go out in the cold and fix something. Yay). So to continue... I see where the confusion is from my post. Allow me to re-iterate, as I'm not quite sure how what I wrote actually came out on the end of my fingers inthe way it did, but it did... So here we go:

 

......The only way to affect with this kind of tempo change is to first SMPTE-lock all events AND automation from the point AFTER you want to mess with the tempo. Then you can change the tempo in the beginning and the rest of the music will NOT occur earlier or later than it did before. It remain in sync with itself and picture but the bar/beat grid will be off -- and that is expected behavior. However, you can fix this by adding/editing additional tempo events to realign the bar/beat grid with the music. This assumes, however, that there's enough space between cues to make this work so that you can have a nice 1 or 2 bar count-in before the next cue kicks in. And sometimes, even if the space is tight, you can still make it work. You just may not have the benefit of a meaningful click into the cue. And that's fairly easily remedied too, but beyond the scope of what I want to explain right now.

 

To put this all in context, and Apple loop behavior aside (which as I said I have no clue about), let's look at an example of a multi-cue project with 1m1, 1m2, and 1m3 all in the same project. I'm only going to cover the most basic paradigms here...

 

1) If you want to change the tempo for 1m3, theoretically you wouldn't have to worry about locking or changing anything with respect to 1m1 and 1m2. Just put in a buffer tempo event near the end of 1m2 as a safety precaution.

 

2) if you want to change the tempo for 1m2 but intend to keep 1m1 and 1m3 intact, then you have to SMPTE-lock regions (and automation) for 1m3 if you don't want it to slip against picture. Same precautions as above would apply to protecting 1m1.

 

3) if you want to change the tempo for 1m1 but intend to keep 1m2 and 1m3 intact against picture, you have to SMPTE-lock 1m2 and 1m3's data.

 

In #2 and #3, when you change the tempo in 1m1 or 1m2, the bar grid is going to end up being off. That's remedied by adding/editing additional tempo events (where they won't interfere with the actual music) to realign the musical grid with the (locked) positions of the existing music.

 

Hope that clears things up.

[45rpm]

It remain in sync with itself and picture but the bar/beat grid will be off -- and that is expected behavior. However, you can fix this by adding/editing additional tempo events to realign the bar/beat grid with the music.

 

Right. But if you're going to do that, it turns out that there wasn't a need to ever resort to SMPTE lock.

 

This assumes, however, that there's enough space between cues to make this work so that you can have a nice 1 or 2 bar count-in before the next cue kicks in.

 

Good point. Everything we're saying about bringing things back into line with compensating tempo events becomes more complicated if we have no rests to work with.

 

if you want to change the tempo for 1m2 but intend to keep 1m1 and 1m3 intact, then you have to SMPTE-lock regions (and automation) for 1m3 if you don't want it to slip against picture.

 

My point is that there is no need to SMPTE lock 1m3 if I understand how to insert a compensating tempo event just prior to 1m3. Which is what I'm going to end up doing anyway, if I want to preserve my grid. Which means I didn't really need to bother with SMPTE lock to begin with.

 

if you want to change the tempo for 1m1 but intend to keep 1m2 and 1m3 intact against picture, you have to SMPTE-lock 1m2 and 1m3's data

 

Same response: instead of using SMPTE lock, I can get the same effect (and also preserve my grid) if I understand how to place a compensating tempo event somewhere to the right of my 1m1 tempo edits.

 

In #2 and #3, when you change the tempo in 1m1 or 1m2, the bar grid is going to end up being off. That's remedied by adding/editing additional tempo events (where they won't interfere with the actual music) to realign the musical grid with the (locked) positions of the existing music.

 

Exactly. But once I have achieved that alignment, everything is exactly where it would have been if I had never applied SMPTE lock. So the lock didn't really do anything for me, although I suppose it does make it easier for me to be sure I've made the compensating changes correctly. If I've done it right, I'll see everything line up nicely. I can achieve essentially the same result if I start out by creating a scene marker. That marker will be restored to its original position on the grid once I'm done properly creating the compensating tempo event.

 

Speaking of scene markers: even though I've already sacrificed plenty of innocent electrons, for the sake of thoroughness I also want to acknowledge what Illyaas said about beat mapping and scene markers. That's another way of getting the same result: getting Logic to automatically calculate a compensating tempo. An advantage to getting this done via beat mapping and scene markers is that then you don't have to fuss with copying and pasting SMPTE numbers. The scene marker itself is a way of storing the relevant SMPTE number. If one is already working with scene markers, and is familiar with the mechanics of beat mapping, then that method is probably preferable (although it has some quirkiness that I won't bother describing right now).

 

What I am adding to what he said is this: by creating a node just one measure back, one can avoid having Logic make unwanted changes to the Cue 1 tempo.

 

I am also adding this: via proper use of this technique (a compensating tempo created via any of the methods that have been mentioned), it should not be necessary to work strictly from left to right. Unless I'm missing something.

[ski]

It remain in sync with itself and picture but the bar/beat grid will be off -- and that is expected behavior. However, you can fix this by adding/editing additional tempo events to realign the bar/beat grid with the music.

 

Right. But if you're going to do that, it turns out that there wasn't a need to ever resort to SMPTE lock.

 

I don't think you're getting this. All I can suggest, then, is that you try it out for yourself. Two tracks. One audio, the other MIDI. No loops (as there's a chance the behavior is wonky per this thread). Make three cues in one project. Add some automation. Then go through the three different scenarios I presented above without trying to SMPTE-lock regions and automation and see how whack things become.

 

At the end of the day, these kinds of conversations (and we've had quite a few of them here) start to read more like theory than practice. But what I wrote above is practice, not theory. However, if your concern is making sure that music stays on the original bar numbers it was created on rather than staying in sync with picture then we're not simply talking the same language. When these scenarios arise in my world, I could care less what the bar numbers end up being. All I care about is that the music that shouldn't move against picture (because of a tempo change after-the-fact) remains locked to picture. I can always fix the bar numbers later. The practice makes itself especially apparent when not working to a click at all (which is my preference much of the time, but another matter altogether).

 

Bottom line: if you don't think that what I wrote is correct, try out those scenarios for yourself. And if you discover a better workflow, please post back and describe your methods.

[shivermetimbers]

Ski

 

I have never messed with editing sound and picture, so ...

 

If I wanted to do this picture and sound sync thing, could i do the following?

 

Import a video of someone speaking (preferably someone who is Japanese).

 

I can extract the audio and chop it up so that I can practice syncing it back up with the video.

 

I would space the video and have music playing in the background so that I can do the tempo changes.

 

If everything works out, then the voice will be in sync with the speaker. If not, it becomes a candidate for the next Godzilla movie.

[45rpm]

All I can suggest, then, is that you try it out for yourself.

 

I did, as follows. Here's a simple example to illustrate what I'm talking about.

 

http://i933.photobucket.com/albums/ad174/45rpm_logic/shot1.jpg

 

In this project there are 3 cues, with audio, midi and some automation, as you suggested. I set the initial tempo to 60, because it gives us nice round numbers to work with. 8 bars precede Cue 3. That's 32 beats, at 1 beat per second. The playhead is exactly at the start of Cue 3. The transport bar shows that this position is the downbeat of measure 9, and that exactly 32 seconds have elapsed since the film started. This is what the director wants: to hear Cue 3 at 0:32 into the film. (We also see this in the ruler, where I've told Logic to display time as well as measures.)

 

So what happens now? I decide that Cue 1 is boring, and I need to add some really wacky tempo changes. So I insert a bunch of tempo changes, and now my project looks like this:

 

http://i933.photobucket.com/albums/ad174/45rpm_logic/shot2.jpg

 

Now that Cue 1 has a nice variety of tempi (with a range of roughly 20 to 160), I think it sounds a lot more interesting. Trouble is, I didn't bother with SMPTE lock, so Cue 2 and 3 have moved. Things have become whack, just like you said. Look at the transport. The playhead hasn't moved with respect to the grid; it's still right at the start of Cue 3, sitting at the downbeat of measure 9. But the transport shows that Cue 3 is now heard at close to 0:36 into the film, instead of 0:32. And the ruler tells us that Cue 2 appears at 0:20, instead of 0:16. So let's fix that.

 

http://i933.photobucket.com/albums/ad174/45rpm_logic/tempolist1.jpg

 

I placed the playhead at the start of measure 4, and created a tempo event there (using the tempo list). And then I placed the playhead at the start of measure 5 (right at Cue 2), and I'm about to enter 16 seconds as the desired SMPTE position for another tempo event I'm about to create. The shot above was taken right before I pressed Return to accept the new value.

 

What am I doing when I enter the number 16 in this tempo event? I'm telling Logic that I want this tempo event to appear at 0:16 into the film. But Logic knows that this tempo event is located at the start of measure 5, and measure 5 is currently at 0:20, not 0:16. So how does Logic reconcile this? Watch what happens as soon as I press Return:

 

http://i933.photobucket.com/albums/ad174/45rpm_logic/tempolist2.jpg

 

Logic has edited the prior tempo event, and given it a BPM of 990. Logic has calculated that this is what's needed to make measure 5 begin at the right time (0:16). (Logic is basically saying 'I got behind during Cue 1, and now I better play this one measure really fast, because otherwise Cue 2 will be late.')

 

And here's what the arrangement looks like now:

 

http://i933.photobucket.com/albums/ad174/45rpm_logic/shot3.jpg

 

The transport tells us that measure 5 (which is where Cue 2 begins) now appears at 0:16, which is what we want (although the 00.56 is unexpected, but I'll get back to that).

 

http://i933.photobucket.com/albums/ad174/45rpm_logic/shot4.jpg

 

And by moving the playhead back to the start of Cue 3 (that is, the start of bar 9), we can see that Cue 3 is also now back where it belongs: 0:32. So we've used the technique from p. 1191 to compensate for our strange tempo changes in Cue 1.

 

So what about seeing 00.56? We expected to see 00.00. I don't know why that happened, but I think it's probably immaterial (and it's probably somehow related to the tempo event itself showing 16:00.55 even though that's not what I entered). It's roughly one frame. On a prior try, I got a much smaller error (one subframe; there are 80 subframes per frame), and it was in the other direction. I have a feeling I'm only getting an error because the tempo changes are extreme (990 bpm!). I think if I had a series of these errors in a long arrangement, they would tend to cancel each other.

 

I also notice that when doing this the 'normal' way (using SMPTE lock), there are also some strange numbers that appear:

 

http://i933.photobucket.com/albums/ad174/45rpm_logic/smpterror.jpg

 

That shot is at maximum zoom. According to the transport, the playhead is exactly at 0:32. And that's where those regions were when I applied SMPTE lock to them. But when I place the playhead so that the transport shows exactly 0:32, the playhead is not exactly at the start of the region.

 

And look at the weird numbers on the ruler. 0:32 is followed by 0:31:24.79. That's obviously wrong. Welcome to the world of Logic, where the arrow of time moves in reverse.

 

So I don't think anyone should be confident that SMPTE lock produces subframe-level accuracy. It probably doesn't. But we shouldn't care, because no one needs such a thing. Anyway, I have a feeling that the two methods I'm comparing are probably comparable in accuracy.

 

Now, am I saying that I'm sure this tempo-compensation technique will always work right in a large project? No, I'm not. I wouldn't say that, but only because all software has bugs. But if it doesn't work in a large project, we should treat that as a bug, and report it as a bug. But I'm not convinced that such a bug has ever been demonstrated.

 

Also, am I saying that this tempo-compensation technique is always the right approach? No, I'm not saying that. I'm just saying it's a choice. The choices are reflected in these three perspectives:

 

A) Always work from left to right (as Illyaas suggested above). Don't dare edit the tempi for Cue 1 once Cue 2 and 3 are in place.

 

B) It's OK to edit the tempi for Cue 1, but only if you first apply SMPTE lock to the subsequent cues. And this means that your grid will be wrong, but you just have to accept that.

 

C) Tempo compensation seems to work, so it's probably possible have your cake and eat it too: edit tempi in Cue 1, and still end up with a proper grid in the rest of the arrangement.

 

I think it's important to understand that the technique I'm promoting is completely compatible with relying on SMPTE lock. It's sort of like using both a belt and suspenders. One does not interfere with the other. If you don't fully trust this technique, then start by applying SMPTE lock. And then apply this technique. You have nothing to lose. If you do it right, you will have repaired your grid. If you do it wrong, your grid will be messed up. But your grid was already messed up, anyway. Meanwhile, you know that your cues are all in sync with the film, no matter what, because you SMPTE locked them.

 

But I'm also saying that if you do it that way a bunch of times, you may eventually discover that the SMPTE lock step is simply superfluous. Because until I see some evidence of a bug, I'm inclined to believe that this method is reliable (and the bug I mentioned above regarding Apple Loops seems like something quite separate).

 

what I wrote above is practice, not theory

 

I think you're claiming that this tempo compensation technique is just a theory. But I've created and displayed an example of this technique working. Have you seen an example of this technique failing? I realize you have a lot of experience using SMPTE lock successfully, but do you also have a lot of experience using tempo compensation unsuccessfully? It would be helpful to understand the conditions where it fails, because then we'd be in a position to demonstrate to Apple that what they suggest on p. 1191 is not reliable.

 

When these scenarios arise in my world, I could care less what the bar numbers end up being.

 

All I'm really saying is that you can continue to use SMPTE lock, and also use tempo compensation to fix the bar numbers. You don't have to sacrifice one for the other. And it may not be the case for you, but there are probably certain users with certain projects where having a working grid is helpful. And it is also helpful to not be obligated to only work from left to right. If wanted to be that linear, I would have gone into accounting!

 

Import a video of someone speaking (preferably someone who is Japanese).

 

It's a great idea. Maybe you realize it's already been done?

[shivermetimbers]

Naturally it has already been done, all those Kung-fu movies and Ultra-man ...

 

>

[45rpm]

I think that monster is just upset because he used SMPTE lock and dropped some tempo changes into Cue 1 and now he doesn't know how to get the rest of his project back onto the grid again. I don't know about you, but that look on his face is more-or-less what I see in the mirror when Logic is pissing me off.

 

Anyway, that's good monster stuff. I had never seen Ultraman before, thanks for sharing. Another favorite of mine from long ago is Godzilla vs. Megalon.

[ski]

Shivermetimbers

 

The answer to your questions are all "yes".

[45rpm]

Not 42?

[ski]

45 RPM,

 

Before I begin, two questions... what frame rate were you working at? And, did you SMPTE-lock the automation prior to making your tempo changes?

 

OK. Now... you have demonstrated exactly what I was talking about -- the need to SMPTE-lock regions and automation in order to preserve the integrity of later material in a multi-cue project when the tempo of earlier material is changed. You've also successfully shown the technique of how manipulating tempo events can get the grid back in line with the music.

 

However, in making your point you're showing a time and beat display in the bar ruler, and that makes for a very misleading demonstration. Not intentionally misleading, but misleading all the same. Try the same experiment starting from scratch but switch your bar ruler to display Time only. Experiment both SMPTE-locking and not SMPTE-locking your regions and automation. I think it'll be quite an eye opener for you, and will prove to you that SMPTE-locking is not a choice. It's an absolute necessity if you're going to be making these kinds of intra-project tempo changes.

 

Moving on...

 

The whacky tempo of 990 BPM for that one tempo event is also a normal thing to see when you're trying to make up time in a very short space of time. Even if you had more space between the cues and used this technique, sometimes you'd still end up with a very high BPM value for your "make up time" tempo event. But as we discussed before, hopefully it can occur in a spot where you'll never hear it, and, the placement of it can provide you with a 1 or 2 measure count-in to the new tempo for the next cue.

 

The "back to the future" timecode number you saw in the bar ruler is a long-standing bug with Logic. I'm pretty sure I've written this up in the bug report section of this forum pertaining to Logic 7. As an aside, I find it amazing that they advertise Logic in such glowing marketing terms as a film scoring tool when such bugs still exist. That kind of thing just kills me.

 

The other bug you demonstrated below is another legacy bug. I've written this one up in the bug report section here as well.

http://i933.photobucket.com/albums/ad174/45rpm_logic/smpterror.jpg

 

To the points you brought up regarding bits...

 

a) depending on the frame rate, Logic is going to introduce various rounding errors when performing these kinds of operations. You have discovered and revealed some of these in your post above.

 

b) if you're concerned about sync to a very high degree (i.e., to the degree that actually matters in practical terms, considering that there is no hard synchronization between Logic and the playback of QT movies), you will absolutely need to fiddle with the bits value to find the leading edge of the frame you're spotting. I've written about this extensively in this forum so if you'd like more information, do a search of the keywords "leading AND edge", author "ski".

[ski]

Not 42?

 

LOL!

[45rpm]

what frame rate were you working at?

 

I used 25 fps, because it's the default.

 

did you SMPTE-lock the automation prior to making your tempo changes?

 

No (I never touched SMPTE lock except when creating the window called "smpte error"). And if you look at all the screenshots, you see that in every case, the automation sticks with the region. When my wacky Cue 1 tempo changes caused Cue 2 and 3 to slip against picture, the automation also slipped. And then when I triggered Logic to apply tempo compensation (1 measure at 990 bpm, as it turned out), the automation and the regions moved back where they belonged. As if they had been locked all along.

 

you have demonstrated exactly what I was talking about -- the need to SMPTE-lock regions and automation in order to preserve the integrity of later material in a multi-cue project when the tempo of earlier material is changed.

 

Well, I wouldn't say I've demonstrated the need to apply SMPTE locking. I've demonstrated that tempo changes in Cue 1 cause subsequent cues to slip picture (but I think that's an obvious thing that hopefully everyone already knew). And yes, SMPTE locking is a way to prevent that problem. But we don't "need" that solution because I've demonstrated an alternate solution. So we do need a solution, but SMPTE locking is not the only solution. And the point of using tempo compensation (either in addition to or instead of SMPTE locking) is that you end up with a working grid.

 

Try the same experiment starting from scratch but switch your bar ruler to display Time only.

 

I fail to grasp the point of that. I can achieve the exact same result by Photoshopping the screenshots to make the bar ruler invisible. Is that going to alter Logic's underlying behavior? Of course it won't. I tried it (not Photoshopping the ruler, but rather just turning the display off; but it amounts to the same thing). I could easily show you a new set of screenshots, where the bar ruler is hidden. But in every other regard they would be identical to the first set of screenshots. What would be the point of that? The new set of screenshots would still demonstrate that the problem can be solved without resorting to SMPTE lock.

 

From the perspective of the director, what matters is that I restored Cue 2 to 0:16 (that is, I used a compensating tempo event to undo the damage done by my wacky Cue 1 tempo changes). He doesn't care that I also restored bar 5 to 0:16 (although I care, because a working grid is helpful to me). So whether or not we display the bar ruler, along with the SMPTE ruler, is quite secondary. It has roughly the same significance is hiding or showing the transport, or the toolbar, or the inspector.

 

Experiment both SMPTE-locking and not SMPTE-locking your regions and automation.

 

The experiment I just presented relies this much on SMTPE locking regions and/or automation: not at all. That is, I have demonstrated that SMPTE locking (in this particular situation) is superfluous. Are you suggesting I run an experiment where I turn SMPTE locking on? What would be the point of that?

 

I think it'll be quite an eye opener for you, and will prove to you that SMPTE-locking is not a choice. It's an absolute necessity if you're going to be making these kinds of intra-project tempo changes.

 

Except that in my experiment (which is easily repeatable; I suggest you try it youself) I made this choice: to not use SMPTE locking. And this is what I discovered (and demonstrated): that it is absolutely not an absolute necessity. In fact, it's absolutely unnecessary (in this particular situation).

 

My choice at this point is to choose to not believe my lying eyes (and ears), because they tell me that Cue 2 and 3 have ended up exactly where they belong. Even though I broke all the rules: I didn't work strictly from left to right, and I didn't use SMPTE locking. I realize you are taking the position that this is impossible. Therefore I must conclude that my eyes and ears are lying to me. And your eyes are also lying to you, when they look at the screenshots and see that the 990 bpm measure caused Cue 2 and 3 to return to their proper position.

 

I think you're basically saying that what I did can't be done, even though I did it, and have posted proof that I did it. (OK, I admit it. I don't even have Logic; I faked all those screenshots in MacPaint.) Have you tried recreating my experiment? I think it'll be quite an eye opener for you.

 

The whacky tempo of 990 BPM for that one tempo event is also a normal thing to see when you're trying to make up time in a very short space of time

 

I realize that. I deliberately used a short interval (one measure) because I think it makes for a clearer and more vivid demonstration of how the process works.

 

Even if you had more space between the cues and used this technique, sometimes you'd still end up with a very high BPM value for your "make up time" tempo event.

 

True. And it could also be a very low BPM value. Depending on how I messed with Cue 1, it's possible that what's needed is a very slow measure (or 2, or 3, or 12), rather than a very fast measure. But that's secondary, because Logic will calculate the right BPM. All I have to do is paste the right number (0:16, in this case) when I'm editing the tempo event located at Cue 2.

 

But as we discussed before, hopefully it can occur in a spot where you'll never hear it

 

Correct. And if we do need music during those compensating measures, there are other tricks we can use to make that happen, and the listener still never has to know that Logic was huffing and puffing at 990 BPM for a moment.

 

The "back to the future" timecode number you saw in the bar ruler is a long-standing bug with Logic.

 

Interesting, I didn't know. Thanks for explaining.

 

I find it amazing that they advertise Logic in such glowing marketing terms as a film scoring tool when such bugs still exist. That kind of thing just kills me

 

I agree that it's embarrassing and inexcusable. But I have a feeling these are largely display issues, rather than internal (i.e., playback) issues. And therefore have little consequence. There are lots of other bugs causing bigger headaches, right? And that's just how software is. Fact of life.

 

depending on the frame rate, Logic is going to introduce various rounding errors when performing these kinds of operations

 

Yes, I think that's more-or-less inevitable.

[ski]

did you SMPTE-lock the automation prior to making your tempo changes?

 

No (I never touched SMPTE lock except when creating the window called "smpte error").

 

Right. I had a feeling you didn't, but wanted to make sure. The second picture you posted in your previous long post was the giveaway that you did not lock the automation:

 

http://www.score2picture.com/L9pix/nolockauto.png

 

All along I have been saying that it's important to lock regions AND automation when doing these kind of whacky tempo changes. You have not done that, so we're not on the same page. And if we're actually going to discuss this, we need to be on the same page.

 

What I was saying before about theory vs. practice? You're now engrossed in the theory of how this should work while I've been trying to tell you the practice. And frankly it's getting a little frustrating.

 

And if you look at all the screenshots, you see that in every case, the automation sticks with the region.

 

No, it does not. It may appear that way, but in reality is has shifted. I've already told you how to see this -- by switching the display to TIME only.

 

...I wouldn't say I've demonstrated the need to apply SMPTE locking. I've demonstrated that tempo changes in Cue 1 cause subsequent cues to slip picture (but I think that's an obvious thing that hopefully everyone already knew). And yes, SMPTE locking is a way to prevent that problem. But we don't "need" that solution because I've demonstrated an alternate solution.

 

Sorry, but you have not demonstrated this successfully.

 

Try the same experiment starting from scratch but switch your bar ruler to display Time only.

I fail to grasp the point of that.

 

All the more reason why you should TRY it for yourself.

 

So whether or not we display the bar ruler' date=' along with the SMPTE ruler, is quite secondary. It has roughly the same significance is hiding or showing the transport, or the toolbar, or the inspector.[/quote']

 

 

Take a deep breath, and switch the bar display to TIME. Then carry out the same experiment if you want to understand the importance of locking SMPTE and automation in this kind of situation. However, if you don't want to understand it but would rather place more importance on insisting that you're right, then what can I say? Carry on...

 

But I will tell you without fear of having to eat my words that the pictures you've posted are misleading towards the point you are trying to make about the lack of need to SMPTE-lock regions and automation in this situation.

 

In closing (cuz this is my last post in this thread)... There are 10 different ways to do many things in Logic. Here we have a situation where there's only ONE way to do things, and clearly I'm the old dog trying to teach the younger dog how it works. Sure, sometimes you can teach an old dog new tricks. But TRUST me... in this case, the old dog knows better.

 

Arf arf, Happy Thanksgiving, and I'll see you around on some other topic. But on this one I'm done.

[Dorian]

More of question than a reply, but on the same topic;

I work a lot with video. Used to be in LP 8, in the sync window, I could assign the start point of the video at Bar x : timecode x. That way if I made a tempo change, my start point would remain constant. (I like to leave an empty bar at the beginning of the sequence.)

In LP9 when i try to change the Bar number, it always jumps back to bar 1.wtf

Is there another window for this now or what?