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.
Blocswave loops export with time-stretch timing offsets HUGE issue
There is an issue with Blocswave and exported loops when time stretch is involved. For example a 95 bpm drum loop played at 129 bpm will not export correctly: first beat is spot on, but all other beats are all other the place when you zoom in. With iaps packs it’s just not possible to know loops initial bpm, that doesn’t help. This is not a midi timestamps issue, but gives certainly similar issues. I don’t know their algo, but I’ve read even Pro Tools Elastique algo gives similar issues, when Ableton Live’s one is spot on. I don’t know if @AmpifyxNovation can fix that, but that’s a huge issue, and will kill any precise timing and will give floaty groove. With Ableton Live you can use markers to fix offset, but that’s a huge work on a full set. On iOS, when recording BW IAA output in AUM or GarageBand with midi link sync in real-time it’s a bit better but still not as tight as it should.
It’s an important info for Blocswave users IMO, wanted to share it.
Spent 50 € during sales, 100 € value on BW features and packs iaps
Here is initial waveform timestretched at 129 bpm
This is loop exported imported at 129 bpm in Gadget, there is an offset
Same 129 bpm exported loop imported again in Blocswave same offset
Exported loop imported again in BW at initial 95 bpm, correct waveform
Comments
Have you set the same bpm in Gadget? There is silence at the beginning of your audio and Gadget won't touch the imported audio file in contrast to blocs wave which will do proper time stretching/compressing.
Yes of course bpm is the same in both apps. On screenshots this is beat 1.3 so third beat of first bar. First beat is spot on. Offsets are not regular and occurs after first beat. Also offset is not only in Gadget but also BW after importing the initial loop (exported from BW, not Gadget).
Create a blank BW project, change bpm (example 95 to 110), export your loop, import it again in BW and check waves.
Note that this is audible or you certainly can feel it, I’ve realized that because after import in Gadget there was something wrong in rythmic timing, no impact with other tracks. So I’ve searched where was the issue.
Wow if this really is the case as it seems, it will be very interesting to hear what amplify say, as this is obviously centre to their whole app and IAP model.
No, works perfectly here.
How exactly do you get the audio from Gadget to BlocsW?
I've noticed something else however:
The waveform display in BlocsWave itself is inaccurate.
In a 4-bar loop, for example, when zoomed out, I have "slip-moved" transients to start shortly before the beat lines.
The more I zoom in, the more they're moving to the right, until they're clearly behind the beat lines.
Forget Gadget it’s not involved, screenshot is only there to show the offset in both apps.
Do the following:
Create a blank BW project, change bpm (example 95 to 110), export your loop, import it again in BW and check waves.
The offset is also in gadget, so it’s not a bad display in BW.
Let me a moment I will do a short video.
That's exactly what I did, except the initial tempo was 100bpm and then I moved to 138bpm.
I exported using AudioShare, imported in Zurich, exported Gadget's full mix to AudioShare and imported again in BlocsWave, entering 138bpm as the imported loop tempo.
Dropped the loop to a new pad so I could hear the original and the re-imported loop simultaneously.
Except for slight phasing (most likely due to Blocs' time stretching algo) they played in good sync, at least good enough for staying rhythmically correct, with an offset maybe in the low milliseconds range.
Illustration video. I think those ms offsets are an issue with multiple tracks. Not audible for most of us including me but more possibly you can feel it. This is because something was feeling wrong between a BW drum loop and a Vancouver tight arp that I made some investigation.
OK, we're talking about tiny offsets of a few milliseconds that I would guess are introduced by Blocs Wave's time stretching algorithm, that would also explain why the offsets are not uniform for the different attack transients you've shown.
Time stretching is never perfect. Developers can choose to stretch using very short audio buffers to stay very tight in timing, but that will introduce a very "grainy" sound.
Choosing a longer buffer and crossfading between time-stretched or time-compressed audio buffers will sound much smoother but will also smear transients, making a drum loop sound like it's dropped into honey.
Recent algorithms using more modern approaches like TDHS, Wavelets and the stuff done by Prosoniq/Zynaptiq are better at finding a dynamic adjustment and other tricks to get the best of the possible algorithm settings automatically, but even in 2018, we're still "not there" in the sense of perfect results.
Melodyne, Serato, Dirac, Radius, Elastique ... they're all quite good, but none of them is perfect and the quality depends on the audio material you're processing.
As the time stretching in Blocs Wave sounds quite good to my ears, I'd rather accept the fact that the timing is not 100% tight over perfect timing but grainy and clearly audible stretch artifacts, especially when decreasing tempo.
Nonetheless, I guess that there's room for improvement, especially when increasing bpm (which is generally easier to make sound good than decreasing bpm), certainly worth a look for the guys @AmpifyxNovation.
@AmpifyxNovation Haven’t responded here since April.
We’ve been ‘dumped’ and they’ve moved on.
Found myself using other apps as ‘rebound’! 😉
Thanks for your explanation
Yes that’s frustrating, but some BW loops really give some good material to work with, and this is some money too. With drums and percs those offsets are still an issue for me. Note that when we record apps though Audiobus in Blocswave there is often a global offset because of latency (we can use trim easily for correction), but as time-stretch is not involved there will be no random offsets issues (if apps used manage midi time-stamps correctly but that’s another topic).
I've been stumbling over so many limitations in iOS music apps that I've learned to take each app for what it is.
.
I'm sure that you'll have much more fun with iApps if you accept what each app does and what it doesn't.
In fact I've started to create a spreadsheet to find the best app for a specific purpose and then I'll use it only for that
For example, I'm currently struggling with the real mess I get when importing my own samples and loops into Gadget for example. Even after years the KORG development team has not managed to implement proper folder support, and things get worse with every new gadget you purchase!
Not to speak of the initial waste of expensive storage space that you have to agree with when using Gadget.
As a consequence, I'm using Cubasis and AudioLayer for natural instruments and Gadget for the initial compositions with mostly drum presets, synths and breakbeats (without the timing or artifact issues like in BW
If you're serious about music production, you need a Mac or Win machine anyway.
I have found this to be an issue even without time stretching involved. Often I will export from Blocs Wave only to find the first note gets muffled in LP-5. I think the whole app needs an overhaul.
Little blindtest!!
I’ve used GarageBand to export an Apple drum loop at 128 bpm. I’ve imported it in a first Zurich instance, Gadget being set at 128 bpm. Waveform is spot on on this one. Then, I’ve exported the same loop from GB at 95 bpm, imported it in Blocswave, exported it at 128 bpm and imported it in Gadget in another Zurich instance. The waveform shows some timing offsets. A Chiangmai gadget arp plays with drum loop which randomly alternate between the tight and loose ones. Try to hear/feel a difference between both, and give your observations: track 2 or track 3, which one is better/have offsets or not? The fun factor is to not always watching the screen
Sounds like the first Zurich track (track2) has time stretching artifacts on the drum loop.
Do you feel any differences in rythmic feeling between drum and arp?
The attacks are smeared by the algorithm so it's no wonder that you're missing some kind of "tight" feeling!
I made a loop in Groovebox at 240 BPM and played it back in Blocs Wave at 120. It did not loop cleanly. The same loop played back perfectly in Caustic. Definitely an issue with BW I’d say. @AmpifyxNovation
Yeah I have a bunch of songs missing the first beat because of BW.
@rs2000 Well track 2 was Blocswave export and track 3 was Garageband export!!
Not sure if it's algo attacks which are smeared. Here are some screenshots from Ableton, first track is Garageband export, second one is Blocswave export... this is an 7 ms offset, which is HUGE!! IMO
Offset is not uniform as first beat is spot on, and others have some variations. Here clips starts on samples fourth beat. So its not possible to slip the sample to fix this, except if using markers but this is huge work on multiple loops and needs Ableton: