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.
QuantiLoop users - pro-s and cons of hosting apps inside and only using QL - vs QL in AUM or AB3
I've been fiddling with the latest AudioBus - with regard to how it works with QL - and the latest AB3.1.1 or AUM.
There's clearly lots to be said for using QL with AB3 or AUM.
But much though these apps do so much - it seems to me more and more than if possible its just far better to - if possible - keep EVERYTHING hosted and routed just inside Quantiloop and avoiding using AUM or AB3 altogether.
IF POSSIBLE ...
Now obviously this means that there might be this or that feature one might miss - and i'd prefer a larger modal dialog with larger faders if I were to use QL on the fly to adjust levels etc.
One might miss the AB remote feature if one has two iOS devices
One might very much miss the StateSaving feature that some iOS music apps have - which IAA doesnt give you
One might miss and want the recent AUv3 MIDI processor plugins feature - and all the MIDI routing possibilities, arpeggiators etc that go with that..
So if the Quantiloop developers were to aim to provide more features to keep as many users who can - able to do everything they typically need - INSIDE QL alone - what features from AB3 or AUM would you QuantiLoop users want to see implemented in the
QL audio ( or audio-midi ) routing system ?
Opinions please...
what would you miss if you currently use AUM or AB3 with QL - and were to switch to QL only ?
Comments
Quantiloop does what I need it to do, and does it well, the way it is now. Would prefer not to have additional complexity and features and risk adding bugs or making it harder to use
I would like to have the ability to record the dry input signal while still monitoring post-FX as you play. As it is currently, if I have an amp sim as an FX on a pedal, the effected sound is recorded. It’s too late at that point to alter the tone via the amp sim.
I know I can use a master FX instead ... but master FX only affect playback, not what you hear as you play.
Following this for the commments
Main reason that QL has all the built in stuff is because many users are live users and ruling out other software enhances stability.
But keep the suggestions coming.
Re: wim
You can do this now. If you add the amp sim as a track effect and assign that effect to ‘Combined Output’ it should do exactly what you want.
>
Yes. this is why I would prefer to be able to do everything I typically would want to do in a live-improv-situation in QL alone , hosting the odd IAA apps and/or - more and more - just AU plugins
The two big reasons I still might need to resort to AudioBus are
1 ) Simple powerful MIDI routing ( eg sending MIDI data from Navichord or iBassist to one or more synths )
2 ) State saving. Which the IAA API itself doesnt support but AB and AB supporting apps do. And of course-as oft mentioned by many on the iOS forums - this - among other things suggests future where everything but the host is an AUv3.
( I look forward to the day when Navichord and all the LumBeat apps go AUV3. And the LumBeat apps not support AB3 MIDI routing or AB state saving
- a real shame given how cool they are )
AUv3 state saving of course is already in QL. But adding simple MIDI routing like in AB3 would be really useful. There's bound to be times some kind of MIDI "internal-wiring" is needed.