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.
Is it just me or is AB3 AUM really this awesome ?
so i made a template in AB3 routed it out to AUM save the session in AB3, and it recalls everything i did in AUM even though i didnt save the session in AUM ?`?
ive tried it a couple of times but iam not sure if it is just a fluke or if its pure luck but if this is intended it is awesome. (before i saved in AB3 and AUM and allways had to redo half the AUM setup)
Comments
State Saving is pure magic
Does this mean that AUM supports AB3 state saving?
Yes.
AUM supports AB2 and AB3 state saving, and has always done that. Note however that IAA apps hosted directly in AUM does not have state saving, only AU and built-in plugins. (This is because IAA in itself has no state saving, which is the whole reason Audiobus had to invent their own state saving mechanism)
I mostly use Aum to host AUx. So in my case at least your state saving works brilliantly
Yeah me too, mostly AUx. this is just so awesome !
Oh that is good information
Now if we can just get Modstep working as an AB3 midi generator, things will really be cookin.
when i do like this...
AB3
Loopy out - AUM
AUM - in Loopy
and then in AUM i add patterning and 2 channels from Push to sidechain then i save the preset in AB3, it does recall the other apps i added in AUM, is that because they allow state saving ? or ? so if an app does not support statesaving AUM (AB3, wichever takes care of the apps loaded in AUM) wont remeber it ?
AWww, it thinks its a PC! Adorable...
this is awesome, like i dont care that much about remebering presets, but remeber the apps and connections, awesome.
so long story short, when using AUM and AB3, setup and save in AB, not AUM and it will work just fine.
restore session
I never go back more than 1 anyway
always been there
in or out AB
But don't DAW hosts save the settings? If so, what keeps AUM from being able to save a session?
Not sure what you mean? AUM saves all its settings. But there's no mechanism to have IAA apps dump their settings to the IAA host to store it there. Also there's no mechanism to signal the IAA app to store its current state itself, and later recall it for a specific project. That's why Audiobus invented their own state saving technology, which has nothing to do with IAA.
Hmmm... Strange. I don't doubt you at all--I'm just trying to understand why when I save a project containing IAA apps, when I load the project again, from my DAW, after working on something else, it loads everything up correctly. Each IAA app in my project loads into the correct track, with the correct patch and routing, and I don't have to re-configure anything. I can simply take up from where I last left off. I assumed that this was the DAW saving the state of the entire project. That's why (in my original question) I was asking why, if DAWs seem to be able to save the entire session state, why can't AUM. Does that make better sense? It is entirely probable that I'm mistaken, but I am just seeking to understand.
iOS DAWs can't save the state of iAA apps either, they can only save the state of AUv3 apps. If you use only AUv3 apps in AUM when possible, that's the best way to get full state saving.
Some IAA apps remember the last state they were in, but that's different and it's not saved with the host session.
"Some IAA apps remember the last state they were in, but that's different and it's not saved with the host session."
I'll bet that's what's going on!!
It looks like I'm going to purchase straight AUv3 apps from now on... Everything else is "old" technology.
Actually, "old" VST technology managed this in the previous century. I still marvel that IAA/AU is so far from reaching even that level. I'd be thrilled if iOS could even get back to that 1990's functionality. Mind boggling, really.
Agreed! Little by little, I guess..... Is there anything that AUv3 is lacking? Does it respond to automation?
In some hosts you can't even automate. In others you can draw in automation but not record it via knob tweaks. Some hosts see the parameters exposed without needing to mess with Midi cc's, some don't. Some hosts can display presets without a preset manager built into the app, some can't. AU's can't send midi out...
I'm sure the list goes on from there, but those are the ones I miss the most coming from a PC/DAW background.
Interestingly, not one of the things I miss is due to performance limitations of the platform! It's just crappy halfhearted design on Apple's part. It's not like they have to invent something. The example is already there.
Or, maybe they're trying to avoid possible patent litigation. In these days that's a threat not to be ignored.
I just did some research. It appears that the spec (aside from gui and touchscreen aspects), is largely identical between iOS and OSX. I am certain that parameter automation exists and is used in the DAWs that are available on the OSX platform, so my question is, how is it being done, and what is keeping it from being done on the iOS platform? MIDI? Why can't MIDI CCs be used and automated with iOS?
Here's a link to some info I found: https://developer.apple.com/videos/play/wwdc2015/508/
I didn't get the video to run, but I was able to read the entire transcript.
@j_liljedahl Can you educate me and help me to understand what is limited in the iOS AUv3 specification? Is it really true that automation is non-existent in AUv3? I haven't researched this very deeply before now. What's really missing from the iOS AUv3 spec when compared to the OSX version? Thanks!
More info: It appears that I was correct--automation with AUv3 apps is being done through MIDI CCs. I found this page VERY enlightening:
https://www.steinberg.net/forums/viewtopic.php?t=97246
AND, it looks like our own @brambos has already got this capability built into his AUv3 apps!
So then, if the capability currently exists, I'm not sure what AUv3 is lacking vs desktop implementations..... Any ideas anyone?
If you read that thread carefully you'll note that the limitations and inconsistencies have less to do with the capabilities of the spec than the current implementation of support between hosts. It's not consistent.
Maybe my memory is fading, but I don't remember that kind of inconsistency between hosts with VST's. Of course back then I didn't have a half-dozen hosts I was working with like I do now.
Happily, one thing that is consistent though ... state saving in the song/project within the host.
"limitations and inconsistencies have less to do with the capabilities of the spec than the current implementation of support between hosts. It's not consistent."
What are some examples of these inconsistencies? This will help me better understand.
"Happily, one thing that is consistent though ... state saving in the song/project within the host. "
Agreed fully!!
Yes, my AUs support all possible kinds of automation, even recording tweaks made in the AU's GUI. Unfortunately no hosts have implemented this yet to my knowledge.
Cubasis lets you draw CC values, which is kind of cool, but still not as cool as using true AU parameters.
I don't want to say anything inaccurate, and don't have time to go through the stuff I've noticed right now, but will try after work. Or - maybe others will chime in.
One reason for the inconsistencies is that for a full year there was no official detailed documentation of the 'standard' (Apple just referred everyone to the WWDC video presentation) and -even worse- there was no reference AU host from Apple. In other words: every host maker just had to make their own interpretation and compliance testing of plugins was therefore also a lot of guesswork...
We still haven't cleaned up this mess (for example: the eternal discussion about who is responsible for managing user presets: the host, the extension or the OS)?
That makes sense. It's definitely frustrating! Even worse if you only use an iPhone--sequencers and DAWs are in short supply.
AUv3 supports parameter automation, yes. As far as I can see, most AUv3 plugins out there (that I own at least) has their parameters exposed this way. Few hosts allows automation of these parameters. AUM allows it by mapping them to MIDI CCs. There's nothing in the AUv3 parameter system related to MIDI CCs, that's just a convenience made possible in AUM - mostly meant for mapping hardware MIDI controllers to AUv3 parameters.
One thing AUv3 on iOS is lacking is MIDI output: you can't make AUv3 sequencers. That would be cool.
Yes, and that's just one reason why AUM is really awesome.
And that's an understatement