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.
Automatic shut down of programs when ejecting option to minimize processing
An automatic shut down of programs when ejecting option. It seems like a practical idea when ejecting a program from Audiobus, it would also shut down the program and thus decreasing a step and minimizing a drain on the audio and processing. It seems the only way to avoid audio stutter that I am confident with is to shut down a program completely before adding a new one - especially when using two or more high grade synths at the same time like Sunrizer, Animoog and NLog. Im using Loopy HD in the output slot. Thanks.
Comments
I seem to remember reading that, while iOS permits one app (e.g. Audiobus) to launch another app, it doesn't allow apps to be shut down by another app. So, basically it's a case of don't blame Audiobus, blame Apple! :-)
Unless they were to add a "shut down" signal to a future version of the protocol? ( So it's "please shut down", not "force quit". )
Assuming an app can actually shut itself down...
Yes an app can shut itself down
I find this thing of having to use the iPad Home button (and hold the icon, and press it again...) to shut down apps a bit boring...
Apple should have implemented "Minimize/Run In Background" AND "Shut Off" soft buttons for every app to use. Who knows for how long that button will resist so many presses, specially when runnig AB and switching apps on and off all the time.
@snoopy That's interesting, I've never seen one do it. The whole 'shutting down apps using the home button and long press' thing is one of the most pointless and annoying things about iOS IMO.
Hmmm...
Just checked the iOS Human Interface Guidelines. It explicitly states that apps should not quit programmatically. Apple also reserve the right to reject any app that goes against the guidelines.
Although it's not a great solution when making music, you can access the app bar by swiping-up with 4 fingers instead of double-clicking the home button.
Not trying to be mean here, but i just feel it has to be said:
It seems as it gets easier and easier to make music with iOS, the more complaints arise about how "difficult" it is to make music with iOS.
I don't get it. We literally have any sound we can imagine at our fingertips, yet it's a "pain" to take 3 seconds to manually shut down an app in the background to free up resources.
There are a lot of great suggestions for improving iOS workflow on this forum, but as Russ from protools expert blog said, many feature requests seem to stem from people simply not knowing how to use DAW's or just an unwillingness to put a little work in. He likened the impending release of protools 11 to getting a heart transplant rather than a boob job.
All the tools we need are already available. Using them in clever ways with a solid work ethic is what will make your music better, not griping about a few seconds here or there, or demanding features that will eventually bloat the software...
Remember how fast music production tools have come in the last 10 years and be thankful!
:-)
Yes but would you rather have a bypass or a boob job? Wait, err, I mean....
Well, as gravity and age are catching up, I may opt for the boob job.. LOL
At least it would be stereo...
@paulb - yes, the guidelines state that an app should not call exit() so as not to give the impression to the user that the app has crashed. I know of at least 3 apps that do this in the app store now, so it is not strongly enforced (if at all). I was involved with one at a previous job where the engineering team were worried about falling foul of the guideline. What they ended up doing was making it an option that the user could set that would terminate the app which Apple never made a fuss about because the user was aware they were going to terminate the app themselves.
However, the issue here is not about apps terminating, but because iOS is so borked that in order to remain in the background apps have to keep on pushing audio out non-stop, so we have all these apps running audio streams when they don't have to, bogging down the system and requiring user driven termination to keep things running.
Most 'normal' (non audio) apps in the double-tap home list are suspended and probably not in memory and doing the wiggle-X action doesn't achieve anything.
It's a definite problem and only going to get worse. I'd say adding in a terminate request mesage into the audiobus protocol to ask an app running in the background to terminate is likely to pass by apple review, but the underlying problem is still there; the user is required to manually terminate apps that they think might be chewing up resources.
What Apple actually need to so is change the way the backgrounding mechanism works for music apps (audio and virtual midi)
@snoopy that should be posted in Radar (Apples Bug/Feature request system) if you haven't already. If you do, post the number here and I'll gladly dupe it.
Couldn't apps just turn off the background audio when ejected from the bus? I'm assuming they could then be suspended properly.
@Paulb - yes, audiobus could send a message to apps to turn off their engines, but of course this applies only to apps who will honour the message (or the audiobus SDK could call exit() haha).
However, other non-audiobus apps (or apps that would not act on an audiobus suspend message) that use the technique to remain in the background would not be affected and would still require manual termination if they don't have a suspend-on-idle mechanism, so the problem is still only partially solved.
@tarasis - posting in radar is beyond my abilities, but given that Apple is clamping down on this at the review stage I'd say they know it is a problem and maybe will have to do something about it.
Ultimately though, audiobus is stretching the bounds on hardware/os with only a quasi multitasking implementation (in iOS), and no TDM or DSP hardware like a 'real' DAW. iPads/iPhones were never designed to be DAWs in essence. Personally, I find it more efficient to stick with virtual MIDI because once the two audio streams are being shunted (input->filter, filter->output) the quantity of simultaneous apps is severely reduced and you get less bang for the buck.
I think if Audiobus were ooking after its own, it would go a long way to reduce the occurrence of memory/cpu saturation. Not many Audiobus users have heaps of non-Audiobus apps running in the background, we are already aware of the need to husband our iDevice resources, so this would be a useful convenience measure to save us having to exit apps manually every time we swap them in Audiobus. Besides, not all apps save their current settings when terminated and it would be a pain to keep setting them up every time they were ejected and reloaded into Audiobus slots. Getting them to turn off background audio and suspend properly would avoid this.
Agreed, and Sebastian seems to be hinting that this is something they are looking at and it will alleviate the issue in the audiobus arena. However (and I guess a bit like audiobus itself) this should be something built into the O/S to get blanket conformance!
Actually it's the other way around. Keeping apps running in the background is hard. That an app is listed in the iOS multi-tasking menu doesn't mean the app is actively running. It just means it has been launched before.
There's a reason why apps with the Audiobus SDK in them keep on running after they've been disconnected from Audiobus though. We want to make sure the workflow is good for musicians and we simply can't be sure when they want an app to stop running and when they want to keep it around so it either can keep on outputting audio (like a drum machine) or not.
When an app actually stops running in the background that means it will have to be launched once more when reconnected to Audiobus. Which then involves a silly "switching from Audiobus to the app in question and then switching back".
So the main problem is actually not closing apps in the background.
The problem is that there is no way to launch apps without them coming to the foreground.
Welcome to the weird world of technical and UX difficulties that we've hidden from you by building Audiobus the way it is.
Not all audio app developers agree with Sebastian here about the policy to stay running in the background even after being disconnected from AB. The efficient use of resources is deemed more important than the "silly" switching back and forth by some. ThumbJam and DrumJam take a compromise position, where they will stay active in the background after AB disconnect for 5-10 minutes then go inactive after that (unless the Power Save option is disabled, or there is midi activity, in which case it stays active).
I think having an app kill function integrated into the AB is potentially interesting if it was presented as an option at the time of "ejection", or perhaps after a long-press of the eject button. It would obviously need to be introduced carefully into a future version of the SDK.
On a related note, consider that in about half the cases users really don't want the "switch back" to Audiobus when launching an app from it anyway. It would be cool if the AB controller would give the user a few seconds of extra time before the switchback, during which it attempts to detect touch events, and if seeing any cancels the switchback. Just brainstorming.
I'd rather have a clock sync function first personally.
@boone51 - I agree. Having clock is more of a "need" than auto app quit...
@ Sebastian "We want to make sure the workflow is good for musicians".
I love you man. This is why you and Audiobus are successful and will continue to be successful. Audiobus is so integral to my workflow that if I were to eject any app, it probably means I am closing that app for good and need to stick in another app in Audiobus as it'd help my workflow. The creative vibe is critical and any analytical processing thought can be a buzzkill (left brain/right brain theory). So Im throwing in my vote here for this feature if it's not too difficult to implement although I'd rather have clock sync as well.
@dubhaus "Not trying to be mean here, but i just feel it has to be said: It seems as it gets easier and easier to make music with iOS, the more complaints arise about how "difficult" it is to make music with iOS. I don't get it."
Would you have said the same thing when ppl asked to make music on a cell phone? Or to ppl when they asked for something like Audiobus? We could've all just gone to Radio Shack and bought a 1/8 inch to 1/4 inch adaptor and use any old guitar cable to plug in our iphones to our DAW. Progress only occurs when ppl ask whats possible. I see your point about complaining but I dont think the OP brought up the feature in a negative manner. Plus isnt ease of use and convenience supposed to be the main benefits of Apple? Otherwise we'd all be on Androids and PCs.
I'm not aware of anyone wanting to make music on a phone until there was a phone that was capable. Maybe someone doing chip tune stuff lol...
My whole point is function over fluff... If there is a feature that shaves 4 seconds off of my workflow, but takes weeks or months for every audiobus dev to implement and possibly eats more CPU, that's fluff.
Anyway, I'm not going to go on with this, as even though you seem to be somewhat "book smart" with digital audio, judging by your posts I sense you lack real world experience.
Just to put things in perspective, the two things are in very different categories. Doing a sync implementation requires all app developers to modify their code to use the new mechanism, whereas the app quit implementation would be done only by the AB guys and the developers get it for free the next time they build with the latest AB SDK.
Both are doable, I'm guessing sync is higher on their list in priority, but it is also more involved.
@dubhaus - ok, to keep things civil on this board i'll refrain from replying to your posts going forward. I'm not a developer and am the first to admit that I am an idiot when it comes to technology when it comes to recording via computers. I've played in multiple bands and performed live for years, signed to an indie label, essentially played music for half my life and learned recording on analog gear out of neccessity because many local musician friends and singers all complained of so called recording engineers and producers who didn't understand the creative process and were too caught up "in their workflow" and not working with "their creative workflow" to elicit the best performance.
yeah bro, i lack real world experience. you seem to lack "music creating experience"
Yeah, maybe you're right. I haven't exactly been super prolific, that's for sure.
I get your point, and I hope you can understand mine. No hard feelings, eh?
One simple thing I'd love to see is that the if the user clicks the Home button when in the AB app, AB should suspend without background audio if there are no AB apps loaded in its slots. No reason to have it running in the background if no apps are loaded inside it.
@dubhaus - peace. I like dub, house and disco so how can I stay mad?