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.
Midi processor vs audio unit extension definition?
What is the difference between these? When loading midi channels in AUM, AUM divides them separately but I’m not clear on the distinction. Thnx folks
Comments
It’s a legacy issue as some AU apps with MIDI output were released before there was a mechanism to categorize them as MIDI apps (e.g. Rozeta). The MIDI processor is the newer category (e.g. Monoke).
Thnx @Paulinko - so there is actually no difference? Any reason why AUM lists them separately?
I think it depends upon how the developer has coded the app and AUM sorts them according to that. It’s similar to how some of the MIDI controlled AU parameters of some apps are organized into subcategories whereas most are just displayed as a single list. Jonatan is very good about updating AUM to reflect changes in iPadOS and iOS and their adoption by other app developers can vary.
Some Audio Units declare themselves to be MIDI only. So, AUM can list those ones separately. Some AU may also indicate that they can do MIDI but AUM doesn't know if they really do until they instantiate themselves, I think -- and hence lists them. Most of those, don't actually do MIDI processing and so don't really perform a useful function when used as MIDI AU.
This is very true, even with AU apps it can be difficult to have consistent implementations of standards by developers so AU host app developers frequently have to do kludges like this to account for AU apps which don’t fully utilize the standards or were developed before they existed and the developer keeps them as they are to minimize disruptions to the user’s workflow.
AU preset saving has even more of these sorts of implementation issues associated with it.
Thanks guys, so lots of the apps in the AU list but not the processor list don't actually really belong on a midi node at all, yes？
MOST don't belong on a MIDI node. The only plugins that makes sense as MIDI nodes are ones that create MIDI output and whose audio output you don't need.
That's what I thought, but there is the odd thing that seems weird, like how Rozeta Scaler is not in the processor list...
Rozeta pre-dates MIDI-only AU, I believe.
I guess so, OK, thnx
Yes, that's exactly true. You need to declare the type of your audio unit plugin in the code. It can be an effect (audio in&out), synth (audio out and optional midi in/out), MIDI generator (midi in and/or out), etc.
You can see the documentation of the types here:
https://developer.apple.com/documentation/audiotoolbox/1584142-audio_unit_types/kaudiounittype_midiprocessor?language=objc
On the host app end, they list the audio units by their type. For example if you make an "aumi" type (MIDI only) app, it would appear under the MIDI Processor section in AUM 👍
@brambos has previously addressed this issue on another thread where he posted about how Rozeta came out earlier before the MIDI AU processor category existed and he decided not to update it to reflect this in order to avoid confusion for his existing users. Chalk it up to an evolving OS where app developers are often ahead of them in terms of functionality.
Even worse than confusing them: it would either cause all existing projects containing the original plugins to fail loading, or people would end up with duplicates of all plugins (i.e. a list of 20 Rozeta plugins in most hosts).
Better to leave it as is. It’s the price of being first
@brambos 👍👍
I’ve often wondered about this as well. Even many of our trusty old “Inter-App Audio” apps have either an A) “generator IAA”, or “instrument IAA” to choose from in AUM. What’s the difference?
ThumbJam is a good example.
https://wiki.audiob.us/doku.php?id=iaa_features&s[]=generator
Ah hah! Thanks! I don’t think I’ve ever seen that page for some reason.
It’s not exactly set in stone though it seems. The differences between “generator” and “instrument” that is, as I just tried an experiment to see for myself; I loaded the ThumbJam “Generator IAA” into an audio slot in AUM, and sure enough, I could send midi to it’s ports just as I can if I had loaded the “Instrument IAA”.
I guess, as mentioned earlier in this thread regarding AUV3 apps, it’s really just up to the developer of each app?
When you load as a generator you have access to the ThumbJam’s Virtual MIDI port. This is a Core MIDI port that is completely separate from IAA (I.e. the developer has to set this up independently from IAA)
If you load TJ as an Instrument you will see the Virtual (Core) MIDI port, but also the IAA Instrument port. This port is the difference between an Instrument and a Generator.
All of this is legacy stuff that points to the messy nature of how iOS music making has developed. IAA MIDI was supposed to make MIDI routing easier as a host could, in theory, immediately route MIDI to the IAA Instrument without having to deal with MIDI matrices. In practice it just tended to confuse everyone
I vaguely recall that IAA MIDI might have slightly better timing, but I can’t say I’ve experienced any real difference.