Hi, I had a workflow in Ardour 6 that is not working in Ardour 7.2. My goal, given two pieces of audio with different tempos, is to trim the second piece of audio to a number of bars, then stretch it to match the first piece of audio so I can overlap them and do additional operations. My previous workflow was this:
Set a New Tempo marker and define the second piece’s tempo
Move the second audio into this tempo, then align with the grid/metronome
Use Cut Mode to trim down to a section I want to use, snapping to bars as I cut
Drag this section to the time where the first audio/tempo is playing, and align the start to the start of some bar
Use the Stretch Mode to resize the snippet so that the end is now aligned with the desired ending bar
The problem I’m seeing with Ardour 7.2 is that step 4 will result in my moved snippet having a different length, as it fills the same number of bars (without stretching, but filling additional audio or removing audio) instead of preserving the amount of time I trimmed to. This means I lose my end cut, and it makes finding it within the new tempo more difficult.
I’ve gone through the Preferences but have not identified anything that allows me to honor time length over bar count. I also would not like to Freeze my track, as I may want to add plugins later, and Unfreezing will revert things without giving me a safe way to Undo them after unfreezing.
Any ideas that would allow me to accomplish my end goal with minimal hassle and cleanup, even if completely different from my previous workflow, would be appreciated. Thanks!
The first image shows my typical staging process, where I will add a New Tempo and then figure out the actual tempo and desired range I’d like to work with for my next track. In this example, I’d like to use 27|1 to 43|1 of Track Two, which I’ve trimmed down to already.
Then, I start dragging the start of this Track Two snippet to where I’d like it to start playing alongside Track One. Here, I’m starting it at 6|1, then intend to stretch it to match Track One’s tempo and continue messing with it from there. As I drag the clip, but before I release it, I can see that my Track Two clip should end sometime between 20|3 and 20|4 before I perform the stretch.
As soon as I release the mouse button, the clip resizes to the time from 6|1 to 22|1, but the stretching has not occurred. Instead, audio that I had cut from the end has reappeared, and I’ve lost the point at which the Track Two clip is supposed to end.
If the resizing did not occur when I released the mouse button, then I could Stretch Mode the clip end from 20|3 to 22|1, which would only stretch the audio I originally intended to stretch.
I hope this clarifies my use case. Sorry about the merged image, I am not able to post multiple images in a single reply yet.
There seems to be some workflow (one or more, probably) that ends up marking audio regions position & length in beats. That’s not supposed to happen by accident, but I’ve seen evidence that it does.
Can you give me access to the .ardour file for the example above and I’ll take a look.
OK, confirmed. At some point the instance of the “beams” region in the track got resized using beat time. Which makes perfect sense actually, since you trimmed using the grid set to 1/16 notes, which Ardour interpreted as “oh, the user wants this region sized in beats”.
Then you moved it, and found that N beats in one part of the timeline is a different duration in samples than in some other part.
The question is: who is making the mistake here, and what is the mistake(s) ?
you trimmed using the grid set to 1/16 notes, which Ardour interpreted as “oh, the user wants this region sized in beats”.
If Ardour is tracking whether the region is sized in beats or in samples, is there a way to change the method for an individual region? If so, I can integrate that into my workflow.
The question is: who is making the mistake here, and what is the mistake(s) ?
I apologize if this is meant as a rhetorical question, but I can offer my thoughts:
Since my workflow used with Ardour 6 is not working with Ardour 7, this might just be an instance of a breaking change or a specification change. In those cases, perhaps the mistake is with me, as long as I had ample documentation to warn me. I know a bunch of timing logic changed to beat/tempo-based processing in Ardour 7, but I may have missed a note that would have alerted me that I need to change my approach - or it may not have been documented.
It’s hard to find fault in Ardour’s current assumption that trimming based on the grid should result in beat-based region sizes. If that happens to be the preferred functionality for a majority of the users that work at least somewhat with a beat-based approach, then it seems fine as-is. I’m guessing there’s a lot of backend logic that depends on that, too. Of course, I’m doing things that involve switching between beat-based and sample-based measurements, so there’s probably not a foolproof solution that can be made from that kind of assumption. (However, rendered audio files like mp3 seem inherently sample-based to me, since they cannot respond to a tempo change without additional processing. Perhaps that knowledge could be integrated into the logic to prevent a sizing change?) There might just be a desire for more preferences or options to cover edge case users.
