Mac AU vs iOS AU

slicetwo

Forgive my ignorance as my only real Apple knowledge is the iPad, but what is the difference between Mac AU and iOS AU? In my short search, it seems that they should be compatible with each other which would imply that they could run across systems. That then makes me wonder why there aren't more AUs on iOS from the Mac versions?

MrBlaschke

Parts of the code might be/are compatible but:
File handling is different
Click/Touch is different
Structures and Hosts are different.
...

So Code-Parts can be exchanged but wrapping them together is different.

animalelder

AUv3 is newer and different. I think FAC makes some of the iOS ones for OSX, but not many hosts support AUv3 on Mac. Probably only Logic?

slicetwo

@MrBlaschke said:

So Code-Parts can be exchanged but wrapping them together is different.

@animalelder said:
AUv3 is newer and different. I think FAC makes some of the iOS ones for OSX, but not many hosts support AUv3 on Mac. Probably only Logic?

Makes sense!

uncledave

Just to reinforce one thing. The processors on Mac and iOS devices are different (Intel vs ARM). And the Apple system software is different, though related. So, at minimum, the dev would have to recompile the code to port from one system to the other. Then, as already mentioned, user interface and file access code would probably need to be adapted. So an AU cannot run "across systems" without some effort from the dev. Apple has made porting as easy as possible, but it's still not trivial.

SilverK

Check this out , it’s a long way off but the ball is rolling by all accounts
https://9to5mac.com/guides/project-catalyst/

RUST( i )K

@animalelder said:
AUv3 is newer and different. I think FAC makes some of the iOS ones for OSX, but not many hosts support AUv3 on Mac. Probably only Logic?

He does.

So does Klevgrand I have them.

McD

As a hardware nerd I'll take a shot at this...

TL,DR:
IOS uses ARM processors and Mac's use Intel Processors.
AUv3 -> ARM Plug-ins
AU's -> Intel Plug-ins

TOO LONG DETAILS FOR THE CURIOUS:

Smart programmers can write for both markets of users.

HAREWARE CONCERNS:

Every hardware device uses a Processor Chip - IOS (ARM) and Mac (Intel)

IOS - Apple designs it' own ARM Chips labeled A{Number} running from A4 to to 13 currently
These chips implement the ARM instruction set.

ARM (Advanced RISC (Reduced Instructio Set Computing) Machine)

These chips are "Systems on a Chip" and are designed to being extremely efficient using very little power while running faster and faster overtime. The enemy in a portable device is HEAT. You can't really add a Fan so there are design limits on how many transistor you can pack into a single chip without melting.

Mac Computers now use the latest Intel Processors that Windows OS'es use. They are strictly CPU designs but some variant bring in addition processing functions like Graphics, Networking Protocols, Bus protocols. To make an Intel based system it requires a circuit board type assembly (called the motherboard) and it holds dozens of interconnected chip types (RAM, DRAM, GRAPHICS, MATH PROCESSORS, I/O Processors). This network of chips make a system than can scale to workloads an IOS device could never entertain hosting.

People that think Apple could drop Logic Pro X onto any IOS device without it becoming a toy
version of that application haven't stopped to learn about these system differences and why a desktop will always be a AirBus compared to a LearJet... sure the Lear Jet can carry a few people as fast but the AirBus can take a crowd. This is an analogy that can easily be picked apart. The point of Scaling Up applications.

So, different Hardware targets make AU's and AUv3's work for unique targets. How many AU's can a modern Mac run (hundreds) and how many can you run on IOS (maybe a few dozen). Deal with it. Buy the right vehicle for your workloads.

CODING SYSTEMS:

Both systems (IOS and Mac) are typically developed using Apple's Xcode programming environment. Xcode provides the ability to turn Swift, Object-C, C, C++ and more into ARM or
Intel Binary packages.

Apple is working to make writing an application for both hardware targets less difficult so an application might be delivered for BOTH hardware devices. Needless to say there will be constraints and limits on what this will mean.

Let's just continue with Plug-in details.

AU PLUG-INS:

Steinberg create a defacto plug-in standard called the VST (Virtual Studio Technology) which
started with Intel systems and DAW's like Cubase and it's competitors. Programmers could write VST"s can sell them for use to any DAW that supported plugging in a VST virtual studio hardware product (FX'es mostly).

Apple took the idea and made an Apple only plug-in standard they called the "Audio Unit"
and after buying Logic Pro they started to slowly displace the Protools use by making a Laptop suitable for most audio uses while also adding support for expensive studio audio hardware devices with AU interface and custom hardware drivers.

So, many plug-in developer just ship VST/AU capable products to open up their markets to a maximum potential.

AUv3 PLUGIN's:

Apple was very successful with the "AU" features on Macs and made a similar set of interface for IOS DAW's and Plug-in authors to use in their products.

NOTE: AudioBus was a defacto standard to connect different products to work together and as Apple makes changes to the AU features over time AudioBus continues to support capabilities that apple neglected or deprecated. AudioBus made the case for IOS as a fully capable system and helped us get our Audio LearJet liftoff in the early 2010's.

Apple's approach model the Steinberg approach:
DAW system with master control
Plug-ins for 3rd party extension of features

AUv3's must respect the limitations of the IOS devices. They have limited RAM due to heat and power constraints that a Desktop/Laptop system does not have.

So, the AUv3 plug-in concept allows us to plug-in more Apps than the system and DAW can manage without audio "drop outs". We can ask the system to do more than it can physically process. I called this the Power Strip problem. Power Strips draw power from the wall socket which in the US is limited to 15 Amps of current (a flow of electrons). A Hair Dryer pulls 1500Watts (Power = Current x Voltage) so 1500 = Current x 110V and max current is about 14 Amps. If I plug 2 hair dryers into the Power Strip it throws a circuit breaker either in the hair dryer of at the Circuit Breaker in my house.

So, it would be nice if AUv3 vendors could provide "Current Estimates" but that's where the analogy breaks. It tries to explain complex interactions of software sub-systems using a single measurable metric. In reality a DAW's design is different from it's competitors and each DAW might have different workload potential for hosting AUv3 apps. The fans of NS2 know that the optimized code of NS2 allow it to do more work in parallel than the other Top DAW's but if you want Audio it's still a planned future that might change a lot of workload issues for the DAW comparisons. We shall see.

So, AUv3's are the current standard and before it Apple had another Plug-in attempt called the IAA (Inter-App Audio) that many apps used. Apple wants developers to stop coding IAA's and AudioBus still survives as another option for pulling older apps into our Music Production Workflows.

PLUG-IN CROSS PLATFROM PORTABILITY:

Some developers product are mainly mathematical models written in a language like C that can be compiled to function on IOS or Mac OS X. The GUI's tend to be different and need additional work or a library of routines to minimize the effort to make one for each hardware target.

If you spot errors or misleading info I'd appreciate the option to re-edit before this is frozen in the Forum.

Anyone wanting to see in this the Wiki... go for it. Cut and Paste. Who reads it anyway? ABF is enough of a time sink.

TL,DR:
IOS uses ARM processors and Mac's use Intel Processors.
AUv3 -> ARM Plug-ins
AU's -> Intel Plug-ins

Smart programmers can write for both markets of users.

aplourde

@McD AUv3 is the current specification for all Audio Units, regardless of platform. It was introduced in 2015 (v2 was 2002; v1 2001). The underlying audio code should be, essentially, the same.

So why are there fewer Mac to iOS ports?

I would guess economics and the hassle of refactoring UIs to work on touchscreens (and because of economics the dubious ability to recoup costs) as a bigger factor than HW differences.

McD

@aplourde said:
@McD AUv3 is the current specification for all Audio Units, regardless of platform. It was introduced in 2015 (v2 was 2002; v1 2001). The underlying audio code should be, essentially, the same.

So why are there fewer Mac to iOS ports?

Again if there's a developer that can provide useful input I welcome their time to educate users more about these issues.

I think it could be misleading to minimize the effort needed. AUv3 is also a description with documentation of an API (Application Programmers Interface).

Do you think the 340MB limit is NOT a huge distinction on IOS vs OS X? The developer has to insure their product doesn't break this rule to actually stay active. That's probably not a concern on OS X.

The devil as always with these things lies in the details and the implementation of an API by a company like Apple is typically a black box system that developers must "work around" to make something work.
Remember when FabFilter included side-chaining in the Pro-C tool and no DAW's on IOS worked with it? The GUI looked like it should work but the DAW didn't get updated with any changes. AUM as usual beat the others to market. A smart solo developer will typically out perform a big development shop just based on having fewer meetings and concalls.

Did you see the Developer comments on how they had to use trial and error to figure out MIDI FX interfaces and behavior.

Common API docs are just an example of Apple trying to minimize developer frustration when aiming to support both platforms.

Our IOS AUv3's almost always get implemented with an IOS capable GUI that needs some attention on OS X. I've heard the Audio Damage guy explain that he created some private code his his GUI's so that he could ship AU and AUv3 products easily. Then he has the on going headache of reacting to GUI changes that Apple requires. People tend to complain about the Audio Damage GUI's in general and point to other apps that have better UI's.
This particular programmer admits he's not a bleeding edge UI designer but this was a business decision. If anyone cares I can locate the Interview on the "IOS Music Producers" podcast.

There are massive differences between IOS and OS X regarding multi-threading, memory management and on and on... So, don't trivialize the effort to support both from the same app.

In generally FX'es that feature DSP audio processing see to be pretty portable. Complex GUI's probably not as trivial.

I'm begging @Brambos to make an OS X Mozaic product but I'm sure he knows if that would be trivial or not worth the effort. Making Mozaic massively profitable in his portfolio will help me so I tend to work on getting people to buy it.

For $8 you can download 127 MIDI FX for free in one zip file. No Programming required.
127 MIDI FX Presets. The download an import process is so easy too... $8. Cheap at 4 times the cost.

Now we need a bunch of Mozaic Script demos so you know why you'd want them for free.
That's a call for the Video Tutors to get engaged... @Daveypoo, @TheAudioDabbler and Prof "Cool Beans". Help move some Mozaic out of the iTunes Warehouse to get me an OS X port. The SpaceCraft guy did it with a plug-in and the Audeonics did it with an OS 10 Standalone of "MIDIFire" which is also an amazing MIDI tool which most ignore. Lot's of script available to solve a lot of MIDI problems and make create tools.

TheAudioDabbler

@McD I actually don't have Mozaic It looks cool but just have not gotten around to buying it.

Maybe I will soon

McD

@TheAudioDabbler said:
@McD I actually don't have Mozaic It looks cool but just have not gotten around to buying it.

I'll help you get it if you promise to make videos demo'ing the Top 10 Scripts. PM me an email address. It's a really amazing tool. Just start with the Top Downloaded or the most "Liked Apps". @rs2000 made a zip file of ALL 127 currently uploaded scripts on PatchStorage. You'll get lost hooking up interesting MIDI FX solutions. It can do almost everything any MIDI FX App we ever payed for.