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.
Comments
😂
I can reliably use RE-1 in AUM to (what seems to me) push the iPad out of CPU throttling. It just needs to be have its UI open.
I'll re-visit VSCO as I find good sources for re-sampling into NS2.
That's an excellent idea!
I'd like to know what's the limit of Obsidian instances and sample sizes in one NS2 project. Let's find out. I'm also curious how compressed sample files loaded into Obsidian are handled: Are they decompressed when loading the patch or are they decompressed during playback, reducing memory footprint?
Maybe @dendy knows?
He would be the most likely to know. Such a deep resource for NS2 questions and good friend of the developer and the struggling NS2 novice.
BTW, thanks for the expedient tip!
In general there are no hard-coded limits on anything in NS (number of instances, number of tracks, level of tracks groups, number of sends, number of inserts, etc etc ...). Only one limit which comes to my mind is 24 samples zones per single sample oscillator in Obsidian.
Just your CPU power and memory is the limit. NS loads all samples to memory, so as soon as you run out of memory, you obviously will be not able to load anymore samples. But based on how iOS behaves to apps with too big memory requirements, it will rather crash the app
) Anyway, in theory you can have few hundreds of MB long sample-based patch in obsidian without issues, it will probably just took few seconds more to load it.
Regarding CPU, on new devices, there are probably some limits, but you ca hardly touch them with any meaningful music
With sample based oscillators, if you are not abusing unison too much, and if you are not we are talking probably about hundreds of instances 
) (of course, it strongly depends on polyphony and other factors, but in general with just Obsidian on devices 2018+ you really don't need take any care about CPU)
All samples are loaded to memory and resampled to current used realtime sample rate. (not sure 100% with that resampling but if i good remember it works that way - in general Matt approach was always CPU efficiency at first place so everything is possible to pre-calculate and not do it in realtime, is pre-calculated
)
You'd expect that with a phone though. The OS is always going to be more aggressive about preserving battery life than on a laptop/iPad. There's also more going on on a phone.
One thing you can do to improve performance on any device is shutdown notifications as much as possible, and also your network. Not only do those use CPU time, but also the ways that the OS has to handle them can have quite a detrimental effect on realtime apps, memory usage and a bunch of other things.
I must say that I find his apps really very interesting and well made.
I think we are lucky to have a dev like him on ios.
Personally, I really appreciated the fact that he gave us 5 (!) Free applications, and that the paid ones are definitely excellent.
I also find it really unfair that some users gave a negative opinion of a free app.
It makes no sense and is totally ungrateful. I'm sure they weren't users of this forum, or at least I hope so.
So I wanted to send a greeting to Jens, congratulate him and wish him all the best for his job. Cheers.
@faland: In my opinion, being free shouldn't matter. Particularly when the free version is being offered as a demonstration of a paid app -- if the review is accurate. In Jens case, he made some strong claims about performance and optimization. In my opinion, he should have dialed back the hyperbole and mentioned that his app required much larger buffers than others need.
A developer has some responsibility for how they present an app and educating their customers up front about an app's needs...especially when they make big claims. That's my opinion.
@espiegel123 I respect your opinion obviously, Cheers.
It is an excellent app. He would have done himself a big favor by having some people test it a bit before releasing it (at the very least to get a sense of what user experiences would be) and setting user expectations better.
+1 and then some.
Isn't that what beta testing is for?