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
samplers with drag&drop support must be integrated directly into host applications. the host actually has control over the (sandboxed) file management. So a “simpler” concept cannot be done with audio units in my opinion. the “drag&drop’ approach cannot be realized with an audio unit on iOS therefore.
On iOS there is no centralized file management like on the Mac OS or other desktops, everything must be copied thousand times to thousand different places...
...unless someone is developing a centralized file provider extension, that plugs into the iOS files app. Even the file sharing between an app and its own audio unit is merely possible via app groups. The access to these app groups is only possible via file sharing extensions (file providers). so it is not even possible to access the shared app group areas via the normal iOS “Files” app from within the sandbox.
A such (specialized) file provider extension basically does nothing different than copying the files too and does not give direct access to these...
These are the fundamental problems for a sampler Audio Unit. A sampler that is limited to access its sandboxed environments is always limited. the files must be duplicated and copied into the operating sandbox. this makes central management of large sampling libs nearly impossible on iOS.
The solution would be, if Apple actually would provide centralized shared file stores on the devices, not merely on the iCloud.
Surely there are workarounds, but everything traces down to copying files thousand times to make them available for sharing.
This is a quite conceptual limitation on iOS with deep impact for any productivity.
Drag'n'Drop from the Files.app and it's Pop-Over into an AUv3 can be done and is done by quite a few apps already.
But dragging from a 'sandboxed' app into an AUV3 can currently not be done...
iOS/iPadOS will at least partially solve this...
Most users here store their files in AudioShare and last time I checked it supplies a FileProvider extension.
For 'direct integration' its only possible between apps from the same developer that share the storage container.
That is partially why AUM and AudioShare have such tight integration and why many would love to see more apps from the same developer.
To me it's 'good practice' to create a copy of a sample in case I need to do destructive edits to it.
Being an avid Renoise user it's common practice to 'make a copy' (it's done automatically when a sample is loaded into a project/session).
Not really, store the samples in AudioShare and create presets with a 'copy' of the sample, that way you automatically get a backup of the file in case destructive edits need to be done...
iOS13/iPadOS will provide more flexible file management...
Or we learn to work around the limitations and drop the references to the 'desktop way of doing things'
That's what most have done already...
One thing I've noticed though is that there are different types of 'sampler users'.
Those who prefer to use giganormous loop and sound libraries and those who prefer to create their own samples.
Personally I fall into the category of creating my own samples and avoid sample libraries as much as I possibly can...
Relying on third party mechanisms generally was never and nowhere any good idea.
These things must be integrated into iOS directly.
Don’t get me wrong, I am an AudioShare user of the first hour and I did it always exactly as you mentioned, discovering the power of this app..
..but I am a developer too. And a developer, who does not like to rely on ANY third party stuff for some certain reasons. This always will lead to dependencies, update delays and disfunctionality the one day later.
So I surely will not design any app, that is dependent of a 3rd party code and/or storage mechanisms. One will have left nothing, if these 3rd parties are all gone or if their “technology” is abandoned by Apple (as now that entire IAA hack) ...
So my suggestion would rather be an open source project initiative for a public file provider extension to create a centralized place for Audio and MIDI sources, which can be shared by all possible audio production apps across all app providers.
I guess this will be somewhat difficult to realize as iOS is basically a commercial platform and nobody is really interested in such project, but individual sales.
I fully agree and have been an advocate of using iOS system features for sharing files between apps from day one when the share-sheet got implemented (allowing 'Open In...' to send files to any app that support the file-type) and when Files.app came in it's basic form allowing 'on device' access to the 'Documents' folder of each app when enabled I started to push for that as well.
But wider adoption of iOS features seems to be a slow and tedious travel...
AudioShare was one of the first apps ever to implement a File Provider Extension
Everyone here got bummed when Apple forced the developer to remove the integrated web-browser for downloads...
Thankfully we now have a 'free' app (Documents by Readdle) that does downloads and also implements a Fileprovider Extension making it at least a little bit less painful to access the files from any app that support the Document Picker or makes it's Documents browser accessible to Files.app.
With the APFS file system in place in iOS the 'copies' (which stay virtual until modified) do not take any noticeable extra as they are just pointers to the source...
I can understand that too especially if a third party framework/library is causing the issues reported back by users.
Another issues that is of concern is the different versions of iOS and supporting the older version can become a pita.
Perfect example are earlier AUv3's that had to implement 'work arounds' for iOS bugs and when these 'bugs' were fixed and the work around was removed support for older iOS version took a hit.
I always keep my devices as up-to-date but I don't do iOS betas...
Yeah, my main wish here is that Apple would implement something like 'Sound Flower' on iOS where each app would create a virtual audio input & output that other apps could use...
Something like this has to happen at some point in order to 'replace' IAA since AUv3's are just 'feeding a host' and we are left with zero host-to-host capabilities...
This is where the new iPadOS/iOS13 come into play. One central place on device to store all user files.
(One of the main reasons I look forward to the update in a few months time).
But yeah, time will tell what happens...
They SURELY won’t implement soundflower-alike stuff, ever.
Because of some certain reason!
The reason on the mac is definitively, that Apple does not want to have ppl RECORDING for instance iTunes and Apple Music playback in the background !!!
So we can actually expect, that Apple rather will close this gap very soon...
Yeah, I do get why Apple doesn’t implement that but strangely enough it’s already possible to ‘record’ iTunes music using the ‘screen recorder’. Sure it’s aac mono at reduced bitrate at the moment but still ‘good enough’ for sampling
And as long as a device can produce sound it can be recorded one way or another.
If Apple was ‘serious’ about disabling recording then why do they not block the ‘audio streaming’ thru IDAM when using iTunes on iOS?
Time will tell what happens, if the audio driver moves to ‘user space’ like the usb mass storage driver in iPadOS/iOS13 this might change...
Wondering about one thing .. back in days when we used HW samplers .. one had usually main powerhorse sampler (no matter if MPC or for example Yamaha A**** or Akai Z* range) and all sample libraries on disc for THIS particular sampler ...
My way of thinking on iOS is same as with HW gear. I have one main app which i use for sampling, and i hold on samples inside THAT app.. In my case it's NS2 of course, but if there would be other supercool AUv3 sampler - i would simply migrate samples from NS2 document root to that sampler document root - problem solved.
I think most issues people are experiencing on iOS are because they are trying to push whole system somewhere where it was not mentioned to be, to use it differently than it was designed .. in most cases they are thinking too much "desktop-way" or how to call it ...
This is mistake and source of many disappointments and frustration - at least that is what i'm observing here at AB forums for long time. You simply need think different way on iOS. And this belongs to just to iOS as such, but also to each individual app... You have to accept limitations. Do not try change world, chance yourself.
I never try to go against wall, to try use app the way it was not designed to be used or endlessly wait on features which are not there yet - instead i always adjust my workflows. It's much simpler, i have then much less reason to be frustrated that i can't do something... As side effect - always when i adjust my workflows, when i go out of my comfort zone and try do things not "my way" but the "app way" - new inspiration arises from that ..
So. I', actually thankfull for iOS and apps limitations. They are pushing me forward, forcing me to lear new things and new ways how to do things ..
I think An auv3 obsidian/slate would sell like hot cakes. It could even end up the Kobtakt of iOS.
There’s a huge gap in the market for an iOS killer sampler. For now.
Perhaps NI will swoop in and make Kontakt the Kontakt of iOS.
But there’s a huge opportunity for an indie to jump in and become the de-facto standard.
That is how I think too and considering that we'll finally have a central (with iPadOS/iOS13) place where we can store our files and grant apps access to entire folder structures things might finally start to clear up...
(Remains to be seen if AUv3's can be granted similar access to folder structures).
Yeah, I do feel there is also some kind of torn image of what an 'iOS Sampler' should be...
...some see it as a glorified rompler with multi-giga libraries while some just want a tool to record and manipulate and play their own sounds.
Honestly I'ld love to keep things simple and start with something similar to Ableton Simpler.
Sure Ableton Simpler will never satisfy those who need 127 samples per instrument with 127 velocity layers each...
But for slicing up loops, one-shots, basic instruments etc. it would be a gold mine!
(Take a sound, any sound, add slice markers and use keys or pads to trigger them).
Classic case of limitations that spark creative ways of thinking
What about Chamleon? It looked pretty limited from what I saw/bought it. I didn't see a way to do slice markers etc. Basic single sample instruments were ok, but the primary reason I love AudioLayer is that it can pitch and map samples based on filename. So it takes any samples I've created or gotten from elsewhere.