You’re right. That was my assumption because I can’t imagine that 2.5 minute limit was set low. And if it was just an arbitrary limit with a load of unused ram still available, then to increase it wouldn’t be work, it would just be changing a compile constant.
I’m still hopeful. But you’re right, I shouldn’t assume.
Just trying to see if anyone has found an efficient flow on the Mac, to remove exactly 360 samples. I’m using Ableton as my DAW and Wavelab 8 LE for basic wave editing (I also have a trial of Audition that I’m messing around with and might pick up). When I open up the file, there is audio that goes to the very end, but my understanding is that the last 360 samples is in excess of what I truly want looped (so if I just loaded this in Ableton’s session view, and looped it, it would pitched up just a bit, if played at the BPM recorded). In Wavelab, I can select samples on the time ruler, but it seems like I have to take the cursor to the end, do some math (i.e. -360 from the value at the end of the file) and then enter this as the new cursor location from which I select to the end, to trim. Seems cumbersome. My impression of the batch processing file linked above is that it is only for the PC, and some additional script has to be devised for Mac. Sorry, I’m not a programmer!
I posted this info on trimming audio files on a Mac way back when. It still applies today.
The way you are currently trimming files might be just as good as the way I did it.
@BrennanSingularSound Is there any real reason why the crossfade needs to be calculated in advance and saved to a file?
Doesn’t seem like this is much work if any for the CPU to calc on the fly than what the Aeros already does for mixing multiple tracks. From a pure data perspective, modifying data is a bad idea (and leads to downstream issues); the main reason to modify data is for a huge performance increase … which I doubt this is.
Fixing this issue directly makes the import and export workflow (and code changes) trivial.
Hey there, sorry for the delay but I wanted to ask the devs to be sure I answer you correctly.
The cross fades are handled live, they are not written into the file, what is set is the amount of samples we record even after a recording is stopped, we use these extra samples to have enough audio information to have a smooth cross fade at every loop seam and part change.
Does this answer your question?
Let me know thanks!
I understand. Let’s call that extra part the tail.
The core issue is we want to preserve the loop length. We are effectively are doing the cross fade after the end of the loop (with a tail) so that we don’t stop it short and mess up the timing.
Recording after the loop end is one way to handle this. I’m not aware of any looper that does this. Ideally this implementation would store the tail in a separate file to avoid messing up the export but that ship has sailed (at least for now).
There are other approaches to preserving the loop length … automatically … and these avoid the above issues.
One approach is to create 30 interpolated samples spread throughout the loop to stretch it to create a tail. This can be done on the fly. There are other approaches to stretching that are possible. I think just repeating a sample every total-frames/30 might also work (but averaging the samples on either side is logically better).
Note that we have to solve this if we ever want import to work (no way to get 30 more samples from an imported file). At that point, why not use that approach for all loops (It’s simpler/less code to maintain), and it magically fixes the export issue.
I suspect you may (already/want to) have something like this implemented to handle external clock drift…
Sorry for the slow reply but I have already forwarded your thoughts to the dev team, thank you!