Is "Glue to Bars & Beats" gone?

Hey,

I was searching for answers to the problem that my audio regions aren’t being moved when I update a tempo marker located before them.

The topics over here mention doing this: Right click Region > Region name > Position > Glue to Bars & Beats

But I’m on Ardour 8.12 (Linux) and this option is not present, be it on audio or MIDI regions.

The options in the Position menu are:

  • Move to original position
  • Lock (toggle)
  • Lock to video
  • Snap position to grid
  • Set sync position
  • Remove sync
  • Nudge later
  • Nudge earlier
  • Nudge later by capture offset
  • Nudge earlier by capture offset
  • Sequence regions

I see most topics covering this issue are from 2023 or before, so was this option removed in a recent Ardour version? Is there an alternative?

Cheers

Ah, I just found that it was removed in 8.0/8.1 released in Oct 2023.

  • Remove option to “glue to bars & beats”.
    For the time being, MIDI regions and data always use musical time (bars, beats) for their position and length. Audio tracks and regions use audio time (samples) for their position and length.
    Location markers and named ranges use the session default time domain (music or audio) and will follow that setting if you change it.

I guess this means that the current behavior is intentional waiting for a better approach to timing?

I guess for now I’ll keep moving songs at the end of my session when I need to edit tempo… I have many audio clips in certain songs so it would be too much of a pain to re-position them after a tempo change.

Since Ardour does not automatically timestretch audio regions to follow the tempo, locking audio to bars&beats is a bit pointless - the audio will not change if you alter the tempo. If you doing single hit audio samples, it has some value, but that’s about all (and you can do those with cues now).

If/when we add “elastic audio” (i.e. automatically stretching audio to fit tempo), we will add back the ability to lock audio to bars & beats.

2 Likes

Hi, thanks for the input!

My use case is actually a tad different I think.

I think youre describing the case of audio regions affected by the new tempo

But I am changing the tempo of a section before the section that contains the audio regions I would like to see moved.

More precisely, my session is structured as a series of songs, each has its own tempo obviously. Say it starts with song A at 120 BPM, then song B at 140 BPM. There are audio regions in song B but none in song A. Now I want to change tempo A to say 110 BPM. As you see the audio regions in B would not be affected in terms of length, since they are still in a section at tempo 140 BPM. They should only be shifted so they are still at the beat and bar position they were before in song B.

Hope this makes sense.

I understand there are edge cases such as audio regions spanning across tempo boundaries. But I was thinking for simple cases like mine audio regions could be moved with beats and bars… But I also understand that the case of changing the tempo of song B would be unclear. So there would be a behaviour in a specific simple case and another in other cases. Still…?

-------- Message d’origine --------

The cue idea is interesting and I might try it out, though I’m afraid of going out of cues to use due to the session containing 20+ songs by now, though not all of them have audio samples in them.

But that’s the crux of it: they will currently never be affected in terms of length, because Ardour will currently never timestretch them to fit the new tempo.

However, I do understand your point, and how the glue option was/would be useful to your workflow.

You could theoretically just put a BBT marker at the start of song B and things should work. However, there are still issues with multiple BBT markers (certainly true in 8.12, and likely still true in the development version).

1 Like

Oh! I didn’t know about BBT markers. Will definitely try that out, thanks. If issues occur with multiple BBT markers I’m fine with using a temporary one when I need to change tempos, hope that will work.

Be forewarned. Lots of problems reported in 8.12 when using more than 1 of them … alas.

The key point is that tempo & meter changes do not propagate past a BBT marker. It stays where it is (in audio time), and it defines the tempo and meter from that point on (until the next relevant marker).

@paul Hi, I tried the BBT marker trick but it does not work as expected.

It seems placing the marker does not preserve tempo changes further down the timeline

I place a BBT marker ef 2 bars before the end of song A, and I expect to have song A at 120 BPM, then a BBT with 2 bars still at 120 BPM, then a change of tempo at 140 BPM

Instead the 140 BPM disappears and everything is set at 120 BPM

Obvs if I place the BBT marker just after the start of song B at 140 BPM, then the tempo of song C and following songs would be affected / disappear instead.

This was promosing but I will move / append my songs to the session for now. I hope things settle in further versions :slight_smile:

Thanks for all your work to you and everyone involved, I have an Ardour setup since 2022 for my tribute band and it has been a great tool.

Hi @paul, I tried the BBT trick but there is an issue which may or may not be expected behavior

Test setup is:

  • Bar 3: tempo 120
  • Bar 4: Song 1 marker
  • Bar 9: tempo 140
  • Bar 10: Song 2 marker
  • Bar 12: sample audio (1 bar long approx)
  • Bar 14: Tempo 80
  • Bar 15: Song 3 marker
  • Bar 17: other sample audio

I try placing a BBT marker at bar 9, right when tempo 140 starts.

Right from that point the issue is that tempo 80 is shifted from bar 14 to bar 14 after the BBT marker, which was bar 21 in the initial meter. I would expect it to be at bar 7 after the BBT marker, ie keep its audio position.

Now I change tempo 120 of song 1 to 80. But the audio samples do not move and sample 1 ends up right when song 2 starts.

Maybe I am using the BBT marker or something incorrectly, or had wrong expectations.

Anyways I’ll keep moving and appending for now, it works even though it just makes the session timeline length very long and creates “holes” in it.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.