2020 iPad Air Review 🤯| From a music producers perspective! 🎹

ipadbeatmaking

@richardyot said:

@AudioGus said:

@richardyot said:
One solution to the 48k issue is to get something like a Dragonfly Black, which gives you a headphone out and also lets you control the sample rate.

The Apple headphone dongle locks the sample rate to 48k.

How exactly does the 48k problem effect things? Certain apps just sound out of tune because they think only in 44k and iOS isnt smart enough to just interpolate something something etc etc?

Yeah some apps are out of tune, but also you have absolutely no control over sample rates if you use the Apple headphone dongle, it's 48khz or nothing.

With a Dragonfly (or similar) you are free to set whatever sample rate you like. I tend to stick to 44.1khz because you're far less likely to run into issues with instruments or samples being out of tune.

Ahhhh that makes sense. I’ve actually experienced this a couple times.

jassy

@dendy said:

@jassy said:

@Paa89 said:
To anyone considering to buy a usbC iPad, stay away (for now) if you only use apogee one or duet.
Apple hasn’t released drivers to make them work since 2018.

Its that a general problem with other usb audio cards or only a specific Apogee thing?

all iPads (lightning/usb) are compatible with all sound cards which are fully USB class compliant, which is public standard. To me it looks like this Apogee is probably not corretly implementing USB Class compliance. Becassue there are no actually card-speciffic drivers, if card is USB Class compliant. My bets are this is something which needs to be fixed on apogee's side ...

edit: quickly checked Duet's manual and USB Class compliance is mentioned just in realtion with MIDI. So probably there is issue, maybe compliance is not fully implemented, just for MIDI not for audio

Thanks for the answer.
After a similar problem with my Line6 Sonic port audio cards with ios 12 and 13 (now solved) Im not sure if that would be a problem with USB c devices.

0tolerance4silence

@ipadbeatmaking said:

@dendy said:

@Carnbot
If I understand it correctly, for AUv3 multithreading, if just the host updated for MT and not the apps, you'd still be able to take advantage of multithreading over different AUv3 instances?

In case host starts to use new multithreading API (called Audio Workgroups), then it will use it just for build in stuff (like buildin plugins).

Host can't affect which and how many threads uses plugin - that's completely plugin response. It dosn't work the way that "host loads plugin into some thread" .. the way how it works is that host requests iOS to instantiante plugin. iOS instantiates plugins and provides to host some API for sending parameters/audio/midi into plugin and receiving parameters/audio/midi AND interface UI from plugin. Thread management of plugin is completely encapsulated inside plugin code.

So is this a good thing? Does this mean each plugin does its own thing regardless of the host or other plugins.

Not a 1:1 example: but is it Unlike MPE for instance where the host has to support it for it to be used even if the plugin supports it?

In order for mpe to abuse midi, you have a standardised midi protocol in place. We are now at 'establishing the standard' point. How good is this, how long until we get there and how it will be 'abused' are all q of future.
/I expect bumpy next ~2 years

jassy

@dendy said:

@jassy said:
Dont know in IOS side, but in the pcs (mac and win) the Daw (hosts) is the responsible of distribute the plugins (their own or third party plugins) between cores/threads, maybe in IOS is different but the Carnbot question, front this point of view, makes perfect sense to me.

Not sure how it works on desktop (especially on windows) but on iOS it works like i described .. I'm seriously in doubt even on desktop is much different.

Of course - there is one small difference on MacOS compared to iOS - on iOS all plugins are running "off thread" which means theyir thread(s) are independent from host thread and they really can communicate with houst exclusively just using API provided by OS. This costs a little but of CPU but increases it stability and decreases chance that when plugin crashes, it takes down whole host (of course this can still happen but from different reasons)

On MacOS there is posibility (it must be supported by HOST and allowed by plugin) to run plugin "in thread" - which means plugin UI thread is executed as part of host application thread .. This has a little bit better performance but also a bit bigger risk of plugin taking down whole host.

I'm not completely sure how this work and if this related just to UI thread or also to audio (realtime safe) thread of plugin (maybe it does).

Probably this is what you mean with "hosts being responsible of distribute plugins between cores" (which is not precisely true anyway, because app never can decide which physical core to use - app can just create some thread, and then it's on operating system to decide which core is processing which thread) -app can create even more threads than number of physical cores .. for audio there are of course strict rules what you are alloed to do on such thread, and what not, but this is topic on it's own .. What is important before iOS14 this was very complicated and risky business, starting iOS14 there is solid straigntforward API for creating multiple audio realtime safe threads .. which is very cool

Well, at least that is not what I have read for many years looking for information in numerous sources about the use of pcs in music applications and the evolution of pcs with multi core / multi thread processors in recent years.
Trying to find on the matter quickly in Google I find for example the first:
https://www.soundonsound.com/sound-advice/multi-core-processors-musicians
"Developers told me that although most instruments and plug-ins run as several threads, they have no control over how these are distributed among the available cores. This is totally managed by the host application"
As this one we can find many sources where it says that the DAW manages the plugins to distribute the best possible with the cores/threads available in the system where it runs.
So obviously the SO is the main responsible of source distribution but the DAW host can also do a good and important job in this matter.

wim

@ipadbeatmaking said:

@dendy said:

@Carnbot
If I understand it correctly, for AUv3 multithreading, if just the host updated for MT and not the apps, you'd still be able to take advantage of multithreading over different AUv3 instances?

In case host starts to use new multithreading API (called Audio Workgroups), then it will use it just for build in stuff (like buildin plugins).

Host can't affect which and how many threads uses plugin - that's completely plugin response. It dosn't work the way that "host loads plugin into some thread" .. the way how it works is that host requests iOS to instantiante plugin. iOS instantiates plugins and provides to host some API for sending parameters/audio/midi into plugin and receiving parameters/audio/midi AND interface UI from plugin. Thread management of plugin is completely encapsulated inside plugin code.

So is this a good thing? Does this mean each plugin does its own thing regardless of the host or other plugins.

Plugins run in their own process, but they are extremely tightly coordinated with the host. They communicate in data blocks. For an FX the host passes some data and gives the plugin a fixed time window to complete any processing and pass the data back. If it doesn't then overruns occur, causing glitches in the sound. For a synth the process is the same but audio isn't passed from the host for the plugin to work on, the synth is just passing its own generated data whenever the host requests it. So, even though plugins are running in independent process spaces, plugins are highly constricted and must meet the communication demands from the host.

That's a vast oversimplification, and @Dendy can surely explain it much better than me.

As for whether it's a good thing ... it comes at a cost. There's overhead in the inter-process communication (IPC) that has to occur.

Not a 1:1 example: but is it Unlike MPE for instance where the host has to support it for it to be used even if the plugin supports it?

Not really. If a plugin has implemented multi-threading, then it doesn't matter whether the host supports it or not. The host and plugins are separate programs and one doesn't know or care what the other is doing internally. They communicate over an IPC channel, and all they do is pass data between themselves. If the plugin works more efficiently, everyone is happy whether the host uses multiple threading or not.

ipadbeatmaking

@Gavinski said:
'it's like body-shaming in the computer world', nice, really enjoying your commentary 😂😂😂👍👍👍

Lol 😂 thanks a lot!

@Gavinski said:
Subbed!

Thanks 😊 🙏

Subbed also!

jazzmess

Man I feel puzzled, just bought a second hand 12.9 2018 iPad pro 1tb (and 6gbram) for around 900. Still wondering if I should keep it and take the plunge on the A14... Damn.

ipadbeatmaking

@jazzmess said:
Man I feel puzzled, just bought a second hand 12.9 2018 iPad pro 1tb (and 6gbram) for around 900. Still wondering if I should keep it and take the plunge on the A14... Damn.

You are beyond good in your current situation. Believe that. IPad Air ain’t beating that. 256gb cap, unknown ram but I’m almost sure it isn’t 6gb and you’ve got a much bigger screen. The grass ain’t greener this time.

mrufino1

The headphone jack removal on an iPad makes no sense to me. At least on the phone they had the excuse of making it waterproof. I am typing this on my 6s by the way, which I have no intention of replacing until I have no choice. Bluetooth does not sound as good as a direct wired connection.

Anyway, I mainly use my iPad these days as an auxiliary to my music making, largely as a control surface, etc, so I guess it will key heading in that direction when the time comes to replace what I have. I have the 2018 ipad and it’s serving me really well. The pencil is awesome for taking notes.

I have cck’s, charging cck’s, lightning to headphone adapter, charging lightning to headphone adapter, etc, for my work in love sound, so I’m set for a while. But I don’t love to use those every time I want to listen to something. And charging your device from AC while plugged into a PA system is often a recipe for lots of noise...

[Deleted User]

The user and all related content has been deleted.

stellare_modular

@jazzmess said:
Man I feel puzzled, just bought a second hand 12.9 2018 iPad pro 1tb (and 6gbram) for around 900. Still wondering if I should keep it and take the plunge on the A14... Damn.

The iPad Air 2020 is using the same CPU which will end up in the iPhone 12, note the missing X. The iPad Pro 2020 and probably also the 2018 is 50% faster.

jazzmess

@stellare_modular said:

@jazzmess said:
Man I feel puzzled, just bought a second hand 12.9 2018 iPad pro 1tb (and 6gbram) for around 900. Still wondering if I should keep it and take the plunge on the A14... Damn.

The iPad Air 2020 is using the same CPU which will end up in the iPhone 12, note the missing X. The iPad Pro 2020 and probably also the 2018 is 50% faster.

Yo, thanks !!
I thought the iPad air 4 would get way better CPU performance, especially single core performance, than the 2018 Pro for music production. Am I wrong here ?

Telstar5

It’s only got two speakers instead of the four on the iPad pro . But that’s just for movies surround sound, right? For music production does it actually matter?

Carnbot

So that vid makes clear the differences, Nice update but iPad Pro’s are still much better, even 2017 models, although it’s close in cpu performance. Apple are always pretty careful not to upset the hierarchy. Hopefully A14X will be in 2021 pro next year.

dokido

If I get it right, for musicians, the single core geekbench is most important and is much better on ipad air4 then the 2019 pro. In that video he does not bother measure single score at all

0tolerance4silence

ATM that's the case, but the shift has now started to utilise multiple cores. It will take time to get there but at least it's being addressed.

Montreal_Music

The iPad Air 4 will be availlable in October. Do we have a precise date or October 1rst will be the date?
And I'm confused; witch iPad is faster on the single core geekbench: iPad Air 4 or iPad Pro 2020?

jazzmess

@Montreal_Music said:
The iPad Air 4 will be availlable in October. Do we have a precise date or October 1rst will be the date?
And I'm confused; witch iPad is faster on the single core geekbench: iPad Air 4 or iPad Pro 2020?

This. Also confused. I have a 12.9 2018 Pro with 6 GB ram that I can return within the first days of October (end of the return window).
The CPU antutu scores are lower for the air 4 from what I have seen, but it doesn't say anything on the single core performance and its weight in the antutu score. Hope we will have more details soon.
Looking at the specs air 4 sports 2x3.1 GHz high performance core Vs 2x2.5 on the iPad pro 2018 + the jump to 5nm, there should be some significant improvement. At the moment I'm more inclined sending back the pro and buying this beauty.

dendy

@stellare_modular said:

@jazzmess said:
Man I feel puzzled, just bought a second hand 12.9 2018 iPad pro 1tb (and 6gbram) for around 900. Still wondering if I should keep it and take the plunge on the A14... Damn.

The iPad Air 2020 is using the same CPU which will end up in the iPhone 12, note the missing X. The iPad Pro 2020 and probably also the 2018 is 50% faster.

but only in multicore performance, not in simgle core - simply because a12X/Z do have more cores.

For music apps at least for next 2 years, until new multicore APIs will be not widely adopted by devs of apps and DAWs, multicore performance is still basically irellevant. In Single core performance looks like A14 really is more powerful than A12/A12X/A12Z ... at least based on geekbench tests... my personal guess is 8 instances of Model D on A14, compared to 6 instamces on A12/A12X/A12z CPUs ;-) looking forward to real world tesrs with music apps...

noob

max 3 months , then we will see multicore apps

wim

No way. Maybe a couple. But that's it. Most existing apps will never be multi-thread, nor would they benefit from it.

And it's multi-thread, not multi-core. The is no multi-core API.

noob

cool beans , in the meantime I will use the new ipad air4 wallpapers https://9to5mac.com/2020/09/18/download-2020-ipad-air-wallpapers/

wim

I planned to spend the time organizing my app library, but alas it doesn't exist on the iPad. It's always something with iOS. I'm going back to desktop.

noob

ah yes that would be great on ipadOs.. wtf hope it will port over

wim

@noob said:
ah yes that would be great on ipadOs.. wtf hope it will port over

I was being sarcastic.

I’ve no use whatsever for that nonsensical piece of fluff.

noob

we need more fluff and emojis

MadGav

With audio multi-threading support there’s also a question of thermal envelope - which devices are going to hit the heat wall and start throttling?

NoiseHorse

So @ipadbeatmaking Im wondering how you’re liking your Air4 in daily use now that some time has gone by. Is it as smooth powerful and overload-crashless as you hoped for? I found a pretty good deal on a 256gb one and I’d to see if you opinion on this has changed any.

auxmux

Also, wondering, anyone have a Launchpad X connected to Air3? Can it be powered without a USB hub?

[Deleted User]

The user and all related content has been deleted.