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.
iOS 8: Audio Plugins (experimental!)
Heya,
So, I've been working recently on an idea and wanted to put it out there and gather some feedback on it:
I've written up a blog post about it, which has more details, but the gist of it is that it uses new features coming in iOS 8 to provide audio plugins. Offline ones, so this doesn't compete with Audiobus at all, but is complementary to it. Audiobus for live/realtime audio pipeline, plugins for offline/destructive editing.
(It's just an experiment right now, so don't get too worked up about it yet... 
)
The nice thing about it, is that it doesn't require a new SDK to support it. If a developer has implemented the standard iOS sharing feature (available since iOS 6), all they need to do is add support for one new callback Apple have added in iOS 8, and then they'll have supported audio plugins.
Thoughts?
Canis
Wooji Juice
Comments
Sign me up!
I like it! If they can do this with photography apps, as shown in the WWDC demonstration, then why not with music production apps? I hadn't thought of this until now. It has potential!
Yes! Good call from good dev
Hi Canis, I like this (and your apps) a lot. Please take it further.
Yer, go for it!
This sounds like a really great idea, enjoyed the blog post too.
I like it
Would be great to see it in all apps share page.
This is great! Looking forward to this!
Cool.
Go for it. ⭐️
Quick and slow fade in and fade out would be nice...
Phase shifter, convert stereo to mono, reduce sample and bitrate ...
I hate it when I have to jump to Hokusai to do it.
It's endless tapping around doing these simple tasks.
I think I get it.
Do it!
+1
Interesting. Yes - pursue this - looks like it might turn into something interesting. Wondered if something like this might be possible. Glad to see someone looking at it. Go for it! :-)
+1!
That's awesome and I hope stuff like this takes off. Making music with iOS devices gets better every year.
@Canis: That looks very interesting. I would also say go for it.... before someone else beat you on it ; )
I also would like to hear what some of my favorite iOS developers here (f.e. the Audiobus team, Sonosaurus, Virsyn, Kymatica and some others) think of it since all the tech programming is a foreign language for me.
I'm interested in ideas people have for using this new bit of cool beyond single purpose audio processing. Been wondering about it since iOS 8 was announced but can't really imagine much advantage over 'open in'. Hopefully some enterprising devs can!
While I love single task focused apps like Holderness Media's apps, I'm not really interested in having 10 apps on my device to cover fades, reversing, normalizing... Though, if I understand the tech correctly, a single app can expose multiple intents/extensions.
I also do not want to wade through the iOS sharing menu having 500 audio processing extensions either. "Open In" and IAA lists already kinda suck. @canis can these sorts of extensions be included within apps in other ways? Like a dedicated 'audio processing' menu within the app's native UI?
One thing this might work well for, if devs implement it, is integrating with an app that supports copy/paste of more than one file at a time. I miss the Sonoma clipboard! Or perhaps the audioshare SDK supports that already?
I can also imagine the SoundCloud app and the Dropbox app stepping up here - no need for every developer to include soundcloud and dropbox (and twitter and facebook and...) support - just pass a file off to the app. Hopefully that means more time for devs to do the fun stuff.
I'm looking forward to the future of this because I feel like there is tons of promise here—I'm just having trouble envisioning it.
So I'm not quite sure I get this, but it has me wondering if Extensions/plugins might make it possible to access the audio from sources like video. That's the biggest Achilles heel in my iOS music making.
Hi all, hope you had a good weekend. Thanks for your comments!
Well, it should be faster, better integrated, seamlessly feed the results back into the original app, you don't have to go round cleaning up temporary files everywhere... it's not earthshattering, but it's a bunch of taps saved every single time, which adds up. There's the potential, also, for passing additional data between app + plugin in a way that "Open In..." doesn't really handle.
That's correct. Also, the user (not the developer) gets to choose which plugins appear in the sharing panel. When you tap the "More..." button you get a list, with switches to flip items on/off and handles to rearrange the order.
So you shouldn't have to wade through 500 plugins unless you chose to enable 500 yourself, and you can put the most useful ones at the front
Plus, it is context-sensitive, so for example if you go to share a photo from your camera roll, you won't have to wade through any audio plugins.
No, Apple only make this available via the sharing panel. It seems to be part of their general security philosophy — it makes it a lot more difficult for a rogue app (whether actually malicious or just badly written) to cause problems with other apps on your device, because the app itself is not able to launch plugins from other apps. It can only show the sharing panel, and the user has to choose to launch the plugin. In this way, iOS 8, and the users themselves, act as gatekeepers between the apps.
Also, while the host app can't provide its own list of extensions, there's no reason why a plugin has to be single-purpose — the plugin does get to provide UI. So (to give a trivial example) there's no reason why Fade In and Fade Out have to be separate plugins, there could be a single Fade plugin, and the plugin pops up a choice of fades.
There's a separate extension type, "Document Provider" for that purpose. You can read an overview here: http://www.imore.com/ios-8-document-provider-extensions-explained
I would be very, very surprised if Dropbox didn't support this, it pretty much exists for Dropbox
I don't know about SoundCloud though — as a company, they seem to be becoming more Twitter-like, in the sense of being oriented around people following celebrities. The technology support is there, though, if they want to take Apple up on it.
Likewise, AudioCopy/AudioShare could rework themselves as Document Providers if they wanted. Again, I know nothing about their plans in this area. But my hope as a developer is that over the course of the next year, more of the proprietary APIs will migrate to using Apple's standard technologies, and we'll be able to whittle down the list of APIs we have to support. If an app can just support Audiobus, MIDI, Action Plugins and Document Providers, and know that everything is covered, and new stuff would mostly just slot in to one of those without even needing an app update, well, that would make everyone's lives better.
But, I still haven't really heard from any other developers about this, so, we'll see.
Might be nice to be able to pipe MIDI to and from a MIDI I/O plugin app and have all routing and syncing handled sensibly and in a consistent fashion by just that one app.
Yes, I was very happy when reading about iOS8 plugins and especially Document Providers. It's perfect for AudioShare, and will let any app interact with the file library of AudioShare directly in the app without having to switch to AudioShare.
Thanks for the thoughtful and thorough reply @canis. A bit of a bummer about the Apple imposed UI but I understand the reasons behind it. Really glad to hear that users can pick what's in there. "Open in" is a mess.
@J_liljedahl, definitely looking forward to that version of the future!
Im dont like the idea to give my files to Condoleezza Rice on dropbox
I want my own cloud! Give me Share with my sftp or webdav!
#dropdropbox
@canis Is it possible to use an audio file inside another app's folder without copy it to your app? This is interesting for save a device space...
@Sinapsya said:
Yes.
@syrupcore: more advanced applications?
Composers desktop project, that should give you plenty of ideas of things that can be done offline. Spectrum and convolution and morphing foo ...for example.
Speaking of documents, no one is talking about the elephant in the room, so what's new in iCloud?
@Sinapsya said:
In the case of the Audio Plugins demonstrated in the video:
iOS 8 gives the plugin temporary permission to read the selected file from the host app. Once the plugin shuts down (ie user saves/cancels), permission is revoked. So while its running, if the plugin wants to, it can make a permanent copy in its own sandbox* but it doesn't have to. When it wants to make a change (eg when you tap "reverse" in the crappy demo plugin), it creates a temporary file in its own sandbox. When you save changes, the host app again gets temporary permission to read the changed file. It copies that into the audio library, and when it's done, the plugin is notified and can delete the temporary file. So you're not cluttering up the device with extra copies every time you use a plugin
(* "the sandbox" is the fenced-off, security-padlocked part of the device that an app is allowed to access. Each app has its own sandbox so they can only talk to each other through special Apple-approved routes. It includes the app's documents folder that you can see in iTunes, read-only access to the app itself — so it can load its own images, sounds etc, but not modify them — and space for temporary files and so on. It's also slightly more complex in that an app, and the plugins it provides, actually have their own separate sandboxes as well as — if the developer sets it up — a shared one. But I'm glossing over that as an implementation detail that users don't need to care about. It's just another hoop for developers.)
In case the case of Document Pickers:
It is possible to keep the file in the original Document Picker app's sandbox, yes — but with the warning that supporting that is a lot more complex. The same new Apple technology allows for both copy or keep-in-place modes, and I suspect that for simplicity reasons, developers are much more likely to implement the case where it copies, vs the complex case where the file stays where it is.
So, an app can ask iOS 8 for a Document Picker — this is like a load/save panel. The app tells iOS what it wants to use it for, and there are 4 choices, corresponding more or less to: load, save, import, export.
Import and Export are very simple. The user can pick a service (iCloud, Dropbox, potentially other apps on their system like SoundCloud, AudioShare, AudioCopy etc if those apps implement the feature) and then either pick a file to import, or place to export to.
iOS then extends the app temporary permission to access that file. It doesn't last long, just long enough to transfer the file. The app needs to copy it to its own sandbox for use. This is very simple to do, and I hope apps will get at least support for this much.
On the other hand, with Load/Save, the file lives in the Document Provider app's sandbox (eg Dropbox' sandbox), and iOS extends semi-permanent permission to the other app, to read or write to the file.
It's much more complex, for two reasons: one is because of the additional hoops you need to jump through for security reasons — in effect, iOS gives the app a "permission slip" to access the file, which the app needs to keep in a safe place and present whenever it needs to read/write to it.
The other is because the file is still stored in the other app, it's shared between those two apps. In fact, I don't think there's anything stopping multiple apps all accessing the same file from the same source. Since those apps could all be running at the same time, they could all try writing changes to the file at the same time — which would cause an unholy mess, and at best, the "last one in would win" (trashing changes from the other apps) and at worst, the file would get corrupted.
So, iOS requires apps using the Load/Save version to use additional technologies (which are too long and boring to explain here) called File Coordinators and File Presenters, that sit between the app and the file and sort of handle negotiations between apps when they all want to change the same file, keep the apps updated as to changes that have occurred, and so on. It's necessary, but a bunch of extra work.
TL;DR Yes, but don't hold your breath, it's much more likely that apps will support import/export style access, which copies the files into the app.
Thx for your time and effort.
Yeah, what lala said. Really appreciate that break down.
is this still on?