Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
Cubasis: Rendered Audio is always a bit too long
![[Deleted User]](https://secure.gravatar.com/avatar/c65f3204a06d27ec73276b6045ed7d23/?default=https%3A%2F%2Fvanillicon.com%2F91feed79a2b1ce0d17ae51ed4913d76d_200.png&rating=g&size=200)
The user and all related content has been deleted.
Comments
I'm guessing it's the latency setting, being added as a silence at the start of the file. Auria Pro used to do this too, until the bug was fixed about a year ago.
I've noticed this varies from 'app to app'. Some synths create longer tails than others.
The wave's may look 'quiet' but when normalising the seeming 'silent' portion turns out it's not so silent after all...
Could it be that Cubasis 'waits' until the synth no longer produces any output and then stops?
If you do not want excessive silence at the end which can occur from long and almost silent FX tails, before exporting via mixdown set the loop markers at the start and end of your track/loop, then in the mixdown screen select the 'Mixdown Between Locators' option and turn off 'Include effect tail'.
I use freeze most of the time as it's faster and doesn't interrupt the flow in the way that the 'mix down' things does.
After freezing I trim the frozen audio.
I don't like fade in-outs (matter if taste) so I extend the tracklength beyond the final point where everything has decayed naturally, sometimes by a dummy silent region to force the DAW to include the extension silence.
But the 'wrong' rendering length might turn into a problem if the target is a fixed beat length of sections/stems to be used in other arrangements.
@tja you remind me of one of our clients, each time we updated their website, they actually took a wooden ruler and measured the lengths of various layout elements on the site and called us in a panic attack, noting that the header was now 0.1mm too short!!!!
No, but obviously you're right and it's important if you want perfect loops exported etc...
If your BPM is not 60, 120 or 240 then you will always have issues...the reason is because of math...
Sampling frequencies are in seconds, so 44.1 Khz means 44,100 samples per second...
BPM is also in seconds...... @ 120 BPM you 2 beats per second so each beat will be 22,050 (44,100 / 2) samples long....
If your BPM is 130 then each beat is 0.4615386 of a second, now the math isn't so simple, each beat is now 20,353.908 samples ....and you cannot have .908 of a sample so rounding is needed, it has to either become 20,353 or 20,354 samples which causes the differences in loop length.
Can I go back to not thinking too much now
once you start dealing with this scale of 'precision' (display) be prepared for a lot of surprises regading rendering files from different apps in different formats
(or vice versa on import)
And you don't even know if a successor app (further on in the process) will calculate on the number displayed or on it's own measuring of sample content.
120 bpm is the default in most apps for a reason
Should be yes.
the infamous ever recurring null-test scenario
Imho just bail out - it's not worth the effort, as not a single person would use a DAW for just adding stems. It's all about busses and processing (fx) chains, which you cannot compare due to their different heritage.
I recently experienced how failures during internal data transfer can spoil a signal: a well respected plugin suddenly introduced a lot of digital mud - and occasional glitches indicated that something must be awefully wrong.
Without the glitches I'd certainly had just trashed the plugin, feeling fooled by my own memory. (there were no error messages)
It doesn't matter if the data is messed by hardware transfer (that specific case) or by a failed program routine on parameters or whatever conditions.
It's software and shit happens
Bottomline: the DAW is more than it's summing section - it has to keep bussed data integrity under a lot of varying conditions.
Interfaces, drivers, plugins, system processes - that's where it's really happening. In the end it's down to the 'trust your ears' paradigm once again...
This looks like what @samu suggested way earlier in the thread. He suggested it is the natural decay of the voice you are using. You misunderstood him, thinking he meant FX tail.
If you look at the first three notes, you can see that the decay gets cut off by the following note. The final note gets the full decay, since there is nothing saying to chop it off. Why would you want to chop it off, except to get a perfect loop?
Try this: do the same test, but with a fifth note. Use regions to only render the first four notes. That should chop the decay of the fourth note, and give you a correct loop length.
Or try with a click sound instead of one with long decay. You may get a shorter loop. If so, I suggest you use the render region option, as well as trim if still necessary.
Yes, decaying notes was what I meant.
Some synths do not always properly decay to 0 causing longish files.
And it won't be a 'perfect loop' unless the excess is mixed into the beginning of the file
(This is one feature I love in LogicPro X, it creates 'perfect loops' by mixing in the decaying notes, in practice it saves the 'second pass' of a loop).
not exactly - the usual argument is that all math is created equal and as such all DAW summing engines have to be identical.
Even if this would be absolutely true, it ignores the fact that processing input data (starting with conversion of the input file) runs through a multitude of stages that are hard to trace and which may influence intermediate data differently under varying load conditions (or by software flaws that only occur under specific circumstances).
The (imho) false general assumption is that software performs flawless.
Digital audio is very tolerant in this context (compared to an accounting app) as it deals with 'analog' data which has analog output as it's target.
Even if 2 waveforms look different, they may sound absolutely identical.
You do NOT 'hear' those sample points, but the result of a reconstruction function which is applied after that stage.
It's same with (white) noise: every snippet (of same length) taken from it sounds identical, but they all have different content
In this scenarios I would also do what @Samu suggested, record the loop for twice as long, and then trim the second half to suit.
@tja you said earlier that you wanted to compare the spectra of the rendered output... if that's what you really meant, then sample - accuracy doesn't matter anyway as the FFT doesn't really care about phase...