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
It is not a big deal for me.
I prefer to poke around in AUM to do Midi routing, but if I have to do some things in another app, I don’t mind. At least not enough to hound a developer about it. And especially not you, developer extraordinaire. 😊
I will mostly use TS in IAA mode anyway. And I just wanted to point out that the Midi Out does work in standalone mode, just set it up in the TS interface.
If you get particular feature requests that you are not sure about, you could always ask here to get an idea of how useful it will be if you add it. Although you may get a lot of conflicting feedback here, too, so look out! 😁
I symphasize with that![:) :)](https://forum.loopypro.com/resources/emoji/smile.png)
But think that was a strange request whoever did request it, virtual midi ports are independent from IAA audio and not related so I can't think of another app which does this, why do the ports need to be hidden at all, especially if the midi out is "on" ?
For me it felt like a bug and I spent about an hour fiddling with the settings and trying on a different ipad before loading it in a host, So other users might do the same. For example I always use these types of apps without the audio, as a midi controller only, so didn't think I needed to use it in a host to get the full midi features when I wasn't wanting to use the audio.
But even when I loaded it in AUM it didn't reveal the ports the first time for me, it took a few attempts..so I think the IAA element is still buggy, at least for me. I thought the ports feature had been removed, then they appeared![:) :)](https://forum.loopypro.com/resources/emoji/smile.png)
As IAA may break with every iOS update keeping the midi settings independent from the audio makes sense to me, but don't redo it on my account, maybe some info in the settings could help.![:) :)](https://forum.loopypro.com/resources/emoji/smile.png)
Hi guys - thanks. I think in this particular case, there was (IMHO) a convincing argument that you don't need to see all those virtual ports unless you're running in an IAA host. I was persuaded that you don't need to see them, and the fact that they're there when you don't need to seem them is more confusing. I'm sticking with that for now. When you're not running in an IAA host, then you make all your MIDI connections from the touchscaper side.
As for the ports not showing up straight away, that could well be an IAA glitch. Basically, touchscaper checks for AU property changes (kAudioUnitProperty_IsInterAppConnected if you're interested) when entering and / or returning from the background etc. It uses this to determine if it's running in an IAA host, then that determines whether the MIDI ports are hidden / shown.
The actual process of checking that property has worked the way it does for a very long time - the only addition being the MIDI ports thing.
As with a lot of IAA apps, it's best to launch the app first, then connect the IAA host.
Ok, will remember the next time I play with it.
But yeah it’s most probably an IAA glitch. Seems more common on my 12.9. This port hiding is different from all other midi controller apps like Gestrument pro etc.
From a user point of view, this has been one of the many advantages of replacement by AUv3, it standardises connection and removes any confusion about ports (and less bugs).
But despite that, love the app and will play around with it. I find these apps are much better when using it on a secondary iPad without having to switch apps at all.![:) :)](https://forum.loopypro.com/resources/emoji/smile.png)
I'm not familiar but Gestrument, but I think it's just one "instrument" essentially is it not? I think touchscaper needs multiple MIDI ports because it is several distinct instruments in one app. That's why I think it's different from most other "single instrument" type apps. The only alternative I could see is have a single port (like most other apps) and use different MIDI channels, but I don't think that would go down too well.
From a user point of view, I think that's partly true, if by standardised you mean "AUM"
From a developer point of view... I think it's a different story. There's practically nothing "standardised" about AUv3 development - we're still in "the Wild West" phase I'm afraid. IMHO, of course ![:smile: :smile:](https://forum.loopypro.com/resources/emoji/smile.png)
To the best of my knowledge, as developers we have one AUv3 demo / example from Apple - the dreaded "filter demo" project. It's huge and as clunky as can be. Also, the "template" code that Xcode generates when you add an AU extension is essentially bits of the code that worked from the dreaded "filter demo". In all honesty it looks like code knocked up by an intern (albeit a very clever one) during an afternoon as preparation for a WWDC talk. It probably was. IMHO, of course![:smile: :smile:](https://forum.loopypro.com/resources/emoji/smile.png)
Less bugs in terms of IAA vs. AUv3? Rant alert!![:smile: :smile:](https://forum.loopypro.com/resources/emoji/smile.png)
Supporting AUv3 is (IMHO) much more complicated than supporting IAA in terms of development effort. It could even mean a total re-design of your app - that's certainly my gut feel with touchscaper. The more complicated your code, the more risk of introducing bugs, right? But we know / suspect IAA is glitchy as heck and most of the actual issues are "under the hood" - i.e. Apple's code, not mine. And... because IAA is "deprecated" that means that any breaking changes with new iOS releases probably won't get fixed - I think we're seeing evidence of that in iOS 13. You may have seen another (much more famous) developer "ranting" about IAA being seriously broken in the latest iOS?
Almost daily I see / hear "IAA is deprecated - use AUv3 instead". So a reasonable response would be... "OK - how do I replace IAA with AUv3?". I think if your app is a model of an analog synth or drum machine, it might be reasonably straightforward. In other cases, I'm not sure AUv3 is actually a good fit (let alone IAA "replacement"), unless the future of music making on iOS is to make everything look like it's running in a shrunken-down DAW and all music apps in the future have to be designed as "plug-ins". FWIW, I find that future a bit dull - that's the way I used to make music on a computer in the 90's.
I'm hoping (quite desperately) that we might get a bit more clarity from Apple on AUv3 development in general with the release of iOS 14. Sadly, I suspect what we'll actually get is yet more emojis.
Just my €0.02![:wink: :wink:](https://forum.loopypro.com/resources/emoji/wink.png)
TLDR; supporting AUv3 isn't as easy as I think most folks think it is, and it is most certainly not a direct replacement for IAA, even if in some contexts, it might look like that![:wink: :wink:](https://forum.loopypro.com/resources/emoji/wink.png)
I feel your pain. Apple are often difficult, and users always blame the devs for everything. But some of the blame has to lie with Apple.
If only the whole AUv3 framework was better documented I think the whole iOS platform would be miles ahead of where it is now.
Thanks for your understanding @richardyot. I think there are a couple of things that might also help put my rant in context...
1) I've spent the last 2 days "aka the weekend" trying to get something working with AUv3 and I have next to nothing to show for it, so I'm still a bit "frazzled" from that.
2) My situation is probably different to a lot of other developers because of the tech stack my apps are built on (this is an Apple tech stack, not 3rd party) and right now, I can't get AUv3 working with that tech stack. I'm literally trying again as I type this and making zero progress...
I could go into the details of 2, but this probably isn't the place. I've asked some hopefully pertinent questions on the Apple Developer Forum, but as per, that's highly unlikely to get me anywhere.
You can watch the tumbleweed rolling by here...
https://developer.apple.com/forums/thread/649415
Not offering up excuses, but just in case anyone's thinking "jeez - he's sounding a bit sensitive about the whole AUv3 thing"![:smile: :smile:](https://forum.loopypro.com/resources/emoji/smile.png)
@moodscaper Yeah I feel your pain, and share it...Apple should do better in supporting both devs and users. I think they support where the money is first and we are a small niche, but at least it's better than Android etc.![:) :)](https://forum.loopypro.com/resources/emoji/smile.png)
I've been involved beta testing AUs from the beginning including all the modular hosts and it's been slow progress. I wish it was perfect from the beginning, I just want to get on and create.... but as a pro user who wants to use it in my work on a daily basis I knew I needed to contribute time if there was going to be a more stable ecosystem. IAA is still a useful workaround but it lacks many features and I only use a handful of IAA apps now. I would not be still using ipads as much as I do (and still spending a lot of money on apps) if Apple hadn't introduced audio units, I got tired of the IAA workflow, not being able to save etc, sync jitters, and switching apps which destroys flow.
"it is most certainly not a direct replacement for IAA, even if in some contexts, it might look like that"
I know what you mean, but AUs aren't supposed to replace standalone apps, which are always useful, especially with midi controller apps like yours, for example from device to device or ipad to PC...but when you want to use it as plugin AU is better than IAA. It's much more work from a developer perspective I know that. Not only because you have to think about many more different use cases and window sizes (if you want your apps to be used these ways). But I know the lack of documentation and support is frustrating. I want hosts to support a max view AU size so that this full screen workflow is still there if you want it.
There is a cross platform standard which is evolving slowly, but I agree it's still in the wild west period, but a bit less wild than a few years ago, AUs are more usable now and developers are getting more experienced making them and sharing knowledge. Stability has been improving at least, I think as Ram increases it helps too. I mean we didn't have files access until recently so iOS still has a long way to go![:) :)](https://forum.loopypro.com/resources/emoji/smile.png)
Fingers crossed Apple pull their finger out more, if they want to sell more pro Ipads at continually higher prices they will need to do it![:) :)](https://forum.loopypro.com/resources/emoji/smile.png)
Have you considered registering for a one-on-one consultation with Apple engineers at this week's WWDC?
@moodscaper
You are very appreciated, and I thank you for your open communication on this forum.
I feel your pain regarding IAA vs. AU. Everybody seems to expect AU, like it is just a simple choice of how you publish your app, like choosing .wav or .m4a as your mixdown file type.
It seems like some apps cannot make the switch to AU without recoding most of the app.
It may be the case with your apps.
Maybe Audiobus support could be added, instead? IAA is deprecated, but Audiobus will live on beyond IAA, according to the dev.
Audiobus support in all of your apps would extend their longevity, without the necessity of updating them all for AU support.
When the AU mess gets sufficiently sorted by Apple, then maybe add AU support.
I am assuming adding Audiobus support to your apps would be much simpler than adding AU support, but if this is not the case, then I apologize for being presumptive.
technical ramble alert... This probably will make little sense, but I'm getting more engagement (dare I say sympathy) here than on the Apple Developer Forum...
I probably shouldn't and can't speak for the AB guys, but I'm pretty sure AB is actually built on top of IAA. Although IIRC, that wasn't the case to begin with. So if they're planning on keeping AB alive, then they're gonna have to maybe go back to how they were doing it before IAA came along assuming that's actually possible. I have no idea whether that would be a route I'd take, but I do have an over-arching aversion to any 3rd party integrations. I did Link for touchscaper, and that's the only one I've done.
Anyway, I suspect (and it's no more than a suspicion) that I will essentially have the same issue with "AB4?" as I'm having with AU migration. Sadly, I'm rapidly coming to conclusion that if your app is built on top of AVFoundation (Apple's Swift-oriented media framework) then trying to "expose" the AudioUnits you're using from AVFoundation as AUv3 AudioUnits simply isn't possible - or more accurately, after 3 days of trying, I haven't managed to do it.
It's all the more frustrating, because they are actually audio units (AUAudioUnits to be precise) under the hood, albeit wrapped in AVFoundation stuff - mostly the stuff (as far as I can tell) that replaces AUGraph (also deprecated) functionality, which, amongst other things, allows you to wire them up to each other and so on.
My problem is that while I can "get at" the underlying audio unit, and even instantiate it in something like AUM, I can't really get it to do anything useful due to (as far as I can tell) a dependency on having a reference to the AV "audio engine". It just throws exceptions, basically saying it isn't attached to an "audio engine". If I try and do that myself, as I do when the app is standalone or running in an IAA host, I also get errors.
I basically just need a simple yes / no answer from someone at Apple whether you can use AVFoundation stuff as part of an AUv3 implementation. That's essentially what I've asked on their dev forum. If the answer is no, then that renders the audio stuff in AVFoundation pretty much pointless for all but the most trivial of apps. Which is a little weird given that AVFoundation was touted as quite a big deal. Then again, it's how Apple roll I guess.
I suspect a few of the "proper" developers are thinking well... you shouldn't have used AVFoundation. To which I would say, (a) I wish you'd told me that over a year ago when I was designing touchscaper, and anyway there's no way I could have built touchscaper as it currently is, without AVFoundation.
Anyway, this isn't a developer forum I know, and that was a whole load of developer type speak up there ^. I'll let you know if I make a breakthrough or hear back (ha ha) from Apple. In the meantime I may disappear for a while - I had loads of plans for new features and even 2 or 3 new apps. Until I have more clarity on AVFoundation and AUv3, all that is now on hold.
@moodscaper you should maybe reach out to @Michael and @brambos as they are both knowledgeable and helpful. They might be able to offer some pointers.
@richardyot - I would guess that neither of those illustrious developers would stoop so low as to use something like AVFoundation
They'll be doing everything "properly" at a much lower "Core Audio" level using C and Objective-C. My route into iOS app development was really Swift and AVFoundation, mainly because I was curious to see how much you could accomplish with AVFoundation and Swift. Quite a lot it turns out - touchscaper is totally developed in Swift and all the audio side of things (i.e. excluding MIDI support) is AVFoundation. And... because I knew that AVFoundation was all based on AudioUnits, I stupidly assumed that when the big AUv3 revolution came, there'd somehow be a way I could expose my AudioUnits via AUv3, instead of IAA. Believe it or not, getting IAA working with a Swift-based solution was a nightmare. It's not documented anywhere.
All this said, I'm not so proud as to not ask for help, but I think maybe talking to the AudioKit guys might be a better bet as they're more into Swift. I think they were using some AVFoundation stuff, but I haven't looked at AK recently. I also don't think the AK Framework has any AUv3 stuff in it - could be wrong. I know they've done AUv3 apps, but I don't think it's in the framework - if it was, Synth One would be AUv3 surely?
Anyway... broken record alert. I've added some details to my question on the Apple Dev forum and the tumbleweed continues to blow... I really need a yes / no answer from the horse's mouth ideally, then take it from there...
@moodscaper
I just want to again show appreciation for what you have created and all of of the subsequent development and hard work you have done since initial release.
You have made one of the greatest iOS music apps, ever. Considering how complex this app has become, how simple the UI is when playing the instruments, and how it all runs extremely well without crashes, glitches, or weirdly broken functionality, I would say your use of Swift and AVFoundation wasn’t a bad decision. The app in its current form works perfectly for me.
AU would be wise, obviously, but if it makes more sense for you to create a brand new version of Touchscaper using a different starting point, then you should really consider taking that route. Even if I have to purchase a new Touchscaper AU, I would gladly make that purchase.
I think a lot of other people around here would understand and support that as well.
Anyway, just try not to stress about it.
You have already created a masterpiece.
😊
@moodscaper I agree with @CracklePot Touchscaper can do without AUv3 in its current implementation. In fact it doesn't even really need IAA: a standalone that generates MIDI and syncs via Link is perfectly acceptable.
An AUv3 version of Touchscaper is almost certainly going to be a major endeavour, and should probably be released as a brand new app to justify the development time involved.
+1. While AUv3 is appropriate for synths, fx, stuff that’s modular and/or benefits from multiple instances, I can’t really see the benefit for something like Touchscaper. If it was AUv3, I’d still only run a single instance so as long as IAA is supported it’s fine by me.
@CracklePot ..well said ! I heartily agree.
Thanks guys - really much appreciated. I thought it might be interesting to share some ideas, and hopefully in a more positive frame of mind![:smile: :smile:](https://forum.loopypro.com/resources/emoji/smile.png)
So something I had on the "roadmap" anyway was splitting the audio and MIDI components of touchscaper for a number of reasons. I've had quite a few requests for a MIDI "controller" version of touchscaper without the "baggage" of the internal sounds. And... I think I've got my head round MIDI well enough actually make that possibly a set of AUv3 MIDI components. The way I've done MIDI in touchscaper is a lot more AUv3 like and has nothing to do with AVFoundation.
I also wanted to do a totally new audio synth engine, separate and much more configureable, also as AUv3s, but that's looking doubtful now, depending on what the response is from Apple on AVFoundation. So I guess it's looking increasingly likely that I'll leave instrument apps to the hardcore(audio) developers. It's a bit of a shame, as I thought I had some nice ideas around MPE, but I think it's too late for me to take time out and get to the level I'd need to be at to pull this off as my C coding skills are really rusty and Core Audio isn't just something you pick up on a weekend I think.
If touchscaper (MIDI) becomes a thing, I'll make sure there's a bundle deal so that anyone who already has touchscaper that might find the MIDI only version useful for some reason can get it without paying full price. Depending on what happens with the AUv3 / AVFoundation debacle, I guess touchscaper (MIDI) might become touchscaper 2.0. Too soon to say and there's way too much thinking aloud as I type going on here.
I just watched the WWDC keynote. No mention of AUv3![:smile: :smile:](https://forum.loopypro.com/resources/emoji/smile.png)
Yeah Touchscaper is not one which is desperate for an AUv3 version as controller apps are great as standalones so I'll always use them that way. An Au version would just be an additional bonus![:) :)](https://forum.loopypro.com/resources/emoji/smile.png)
I would agree too, for my uses, which are at best hobbiest.
Hate to see you giving up on your dream though. I really dig what you've done so far and look forward to what you are coming up with next @moodscaper !
On a positive note, the current Touchscaper is one of those rock solid IAA apps (which is not always a given ...), so there is nothing immediate which needs fixing.
Sounds like a swift-based midi-only Touchscaper component(s) AU is a viable path, that certainly sounds useful from a user perspective. No AUv3 in the keynote was no surprise:) You may hope for some hidden knowledge/documentation in one of the upcoming audio presentations.
Absolutely solid, and even pre-ARM chip I had it running four VST’s in Live via IDAM!
I just use the save in the scenes window (from the little folder in the top right, select scenes, then edit, then save) and it always saves everything: arrangements, patterns , and instruments.
I made an account just to say this cause I've seen so many comments about saving. You can also use the save buttons
in the other windows, but the master scene save does save all, at least for me.
Thanks Rob for such an awesome app!
thanks @cerement! Funnily enough, I thought about looking at scene saving today - one save button to save them all! Or something like that...
I can't decide where to put it as we're rapidly running out of space. At least on a 9.7 or iPad mini we are.
That would be the icing on the cake for me, a quick and easy way to save and open whole setups. It’d be great to bring up one where the MIDI channels were saved too, so I can open a template that’s already mapped to another saved template I have in AUM.
Just bought, pretty nice..Hope to see it in AUv3...please..
Edit...The AUM (Back) button helps.. wonder why other IAA apps don’t/won’t do it?
Could somebody please tell how how to change the octave - if I bring up the scene editor, then click advanced, then select any chord the octave shows as C4.
If I change it to C3, then hit save/scene only/overwrite scene. Then bring up the scene editor again its reverted back to C4.
How do I change the octave and get it to save the change?
TIA
Sorry, this is a little confusing. When you select an octave, you're telling touchscaper which notes to play, in that octave. C4 just happens to be the default octave selection. Hope that helps.
Any chance Touchscraper will be Auv3 anytime soon?