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 totally get the case you're talking about there, but it's not yet a common one with Sitala. The converter has not seen a lot of uptake (it's had like 150 downloads), so I think it's very, very rare to have 1000+ kits (and honestly, I expect even 50-100 is rare).
So it's not me saying, "We won't do this", but rather that it's a good idea that currently has to compete with other things we get asked for a lot more, and are currently higher priority.
The ability to switch kits via MIDI may make it into the next release, but currently we're leaning towards that being such that specific kits get mapped to MIDI PC events, since that's something we've had a lot of requests for (specifically for people doing performances with Sitala).
https://wiki.audiob.us/doku.php?id=file_storage
Useful, thanks Ed
Im definitely speaking from the perspective of a power user, but still, sub folders only make your app better for Kit organization.
I can respect that. But please seriously consider it, it would really improve workflow, something iOS is always in need of.
I think both options are valid, how difficult would it be to get both a midi cc assignable ‘next/previous’ button in addition to the kits being PC assignable method?
Also, on another note:
@scotchi would it be possible to get an updated plugin ID on the desktop version to match the iOS version so we can send iOS projects to desktop? Currently it only works sending desktop projects to iOS since desktop is a lower (1.0?) version number. I’m using MTS (MultiTrackStudio) to do this but there’s a few other cross platform DAWs as well
It's not rocket surgery, but it'd be several hours of work, because we don't currently have buttons for that at all, so first we'd have to decide where to put the buttons, then set up the MIDI mapping, then handle saving those in the preferences, ... Again, nothing off the charts, but all said and done, I wouldn't be surprised if it was a full day of work, and again, there it's in competition with other features we're working on. That said, this fits more thematically with our next release, so if @luzifer and I agree quickly on what should be done, it's possible it might make it in.
Yep. We've got a pretty significant release for iOS coming out in a week or two (biggest update since the initial release), and then will swing back to working on the next desktop release. The big multi-platform DAW is GarageBand, so we already had getting things working more smoothly between the desktop and iOS as one of our goals there. I just added checking MTS to our to-do list.
Does this app work with AudioShare yet?
You can use "Open Individual Sample..." with AudioShare, but the browser can't see inside of AudioShare or any other "file provider". That's not a limitation of Sitala -- that's a limitation of the "file provider" permission system. The only way for it to be fixed would be for AudioShare to store files in the normal file system instead of its app storage.
You can import one sample at the time...
...AudioShare needs to get an update to allow linking to folders etc. etc. etc.
(I've not even bothered to install AudioShare on my new iPad as I no longer see any need for it).
OK, thanks Samu & scotchi!
That's actually a point I'm somewhat curious about: are people still using AudioShare because they care about its feature set, or just because of momentum and that's where they've had all of their samples until now?
I have a feeling that it's 'because they are used to it'?!
Audioshare does provide some basic archiving, file-conversions, quick trimming with fade in/out, reverse and allows one to quickly play the a folder of sounds and does a decent job of file & folder management.
(I do most of my file-conversions with custom shortcut scripts which I can run on a group of selected files straight from the Files.app).
To keep AudioShare somewhat relevant it could just ditch/disable the 'File Provider Extension', expose its existing 'iTunes' folder to Files.app. Users could then move the content inside AudioShare to the AudioShare iTunes Folder and voila, easy access for all apps that use Document Picker and AudioShare users could still keep on using the app to manage their files that would no all reside in one folder with sub-folders.
I have absolutely know clue on what @j_liljedahl is planning for AudioShare in the future and how much extra it would take to disable the file-provider extension and make the iTunes folder visible to Files.app.
I'm not saying that Files.app is 'perfect', far from it. I mean we can't even set the default app for file-types which is a pita when the default app opens a file after one tap on and a long-tap is needed to summon quick-look for preview.
I do most of my sampling & sample editing on the iPad with BM3 or Auditor with occasional roundtrips to TwistedWave.
I can for example see AUM saving Audio Recordings directly to it's own Folder under AUM/Recordings/Session instead of the current way where it defaults to saving to storage provider location shared with AudioShare.
The problem here would be that some users may still be running an older iOS version where these 'modern' iOS features are not present and that in turn creates the problem where new technologies can not be implemented due to refusal to keep the system up-to-date. (It took many years for the Document Picker and ShareSheet to get 'adopted' as a somewhat standard way to import & share files).
Time will tell where things goo...
Cheers!
Largely momentum..particularly people using AUM for stem capture…since AUM uses AudioShare’s directory for audio file recording.
I usually export to other apps directly from within AUM.
But I do wish AUM could also store the recordings in its 'own' folder that is already visible to Files.app for easy backup of project files or at least add an option to do that. (Imagine keeping AUM projects and the generated recordings in one folder?).
Other apps do have access to File Provider Extensions via the standard Document Picker. Just try this:
Yes, I think we have discussed this before but my plans for AudioShare3 is to ditch the File Provider extension since it's no longer needed. It still needs to have internal access to this space though so users can move their files to another folder.
Yes, and that's still usable. But it's not nearly as convenient as the file browser that Sitala (and now also Koala) have, which can't see inside of file provider extensions.
To the extent that AudioShare is still commercially interesting for you, I suspect that's driving quite a few users away from it.
For single file yes, but if try to upload a folder of files...
...single file selection also works in Sitala but when you try to access an entire folder and its content it's another thing.
But never mind me...
...I don't keep my samples in AudioShare (don't even have it installed for now) so for me this is a non-issue.
Cheers!
Ok, yes that's another thing than to say that other apps don't have access to AudioShare's files.
Could you please explain this in more detail? There is only one file browser in iOS as far as I know (UIDocumentPicker). So if the soundcloud app can see inside file provider extensions, why can't Sitala?
I just tried latest version of Koala. Import Audio, navigate to the AudioShare file provider, load a sample. It worked fine here.
OK, but can we all agree that it would be very useful if Sitala could get access to Audioshare's folders rather than just individual files?
As of iOS 14, apps can now be granted access to list and browse files without using the file picker. But they can't do that for file providers. Here's a screenshot of what that looks like in Sitala.
I'd be happy to give you a promo code for Sitala, if that'd be helpful in getting your head around things. (Though again, Koala now has an almost identical browser, with the same limitation that it can't see into AudioShare.)
Of course! And I am all to improving AudioShare and of course want to fix any problems/bugs on my side if there is any. I'm just trying to understand exactly what the issues are here.
Here's the same thing in Koala with AudioShare (and Dropbox) grayed out:
Mounted USB-Drives and SMB Shares work as well which is really, really nice!
(This is something that works on both iOS/iPadOS15 & iOS/iPadOS16).
Would it (or is it) be possible for AUM to give users the choice to save recordings elsewhere than Audioshare? Equally for AUM File Player to allow people full access to On My iPad and iCloud instead of Audioshare, if they so wish? @j_liljedahl
That's really cool, and has totally flewn over my radar
Do you mind pointing me to the docs regarding this? Or are you using a document picker first to pick a folder and saving a bookmark for that?
Yes, sure!
Yes, this is on my TODO list as well. It would happen at the same time as some changes regarding the way recording in AUM works now.
This is already possible! Just tap the folder-with-arrow button in the FilePlayer window, and you can open any file available via the standard iOS Files system.
That's pretty much it. You need a
UIDocumentPickerin folder mode to get the security scoped bookmark. Once you have the bookmark you can access all of the folder's children.Ah, point 1 is good to know, the sooner the better! Point 2 is a new one to me, cheers!
Amazingly at least back in the days when we implemented that feature there was no mention in Apple's docs whatsoever. If it wasn't for @Samu we'd never have discovered the possibility.
At least one other developer I know of found this pretty useful...
https://adam.garrett-harris.com/2021-08-21-providing-access-to-directories-in-ios-with-bookmarks/
(Ie. in his case the AUv3 and Stand-Alone app will share the same 'working directory' so no more duplicate files).