What would you like to see in iPadOS 15 ? WWDC 2021 June 7-11

onerez

@SevenSystems well at least we will know that Xequence 3 will be fully optimized!!! That’s coming soon right? 😁

SevenSystems

@onerez said:
@SevenSystems well at least we will know that Xequence 3 will be fully optimized!!! That’s coming soon right? 😁

I got the message 😁

NeonSilicon

@SevenSystems said:
@krassmann @NeonSilicon I must say I agree with krassman here, it's not the developer's business to develop around strange limitations in the way the OS handles virtual memory. In 99% of cases, it's pretty simple. Memory is used for anything that's currently happening in the app and your project, and the disk is used for saving and loading your projects. It has been like that since computers came into existence. (with a few exceptions in edge cases like audio tracking).

The problem is that iOS is the only operating system in the universe* that can't swap.

. * maybe Android can't either, but still, swap has been invented before the bronze age in order to deal with excessive memory usage gracefully and transparently.

Most operating systems have no virtual memory system. Nearly every embedded system has no VM at all and you get to deal with memory segmentation, fragmentation, and limitations all by yourself with no help from the OS or maybe just a little help in some cases.

Swap is only one way to handle doing VM. iOS uses a different method that has benefits and disadvantages. As you say swap was invented in the bronze age, back when the total available hard drive space was less than the per process limitation iOS has now. It has major disadvantages that come with it as well. Part of what makes it much better for performance on systems with swap to add more RAM is the fact the the applications hitting swap was a massive performance hit.The main point of swap wasn't to allow for use of excessive amounts of memory but was to allow the OS to present a contiguous memory address to the application. The swap part was there to make it possible to do this. As a developer, you still need to be efficient with memory or your own application is going to suffer performance wise because it's constantly hitting page faults. However the memory architecture is setup, it's on the developer to work within its limitations. In a real time setting, a page fault is automatic death. If on an audio thread your memory got paged out or you needed to wait for a new page to be swapped in, there's no way you could make your deadline.

I have no idea how Procreate is architected. I suspect that what really happened is they got caught a little off guard by the M1 raising the expectations of their user base. I noticed yesterday that I got an update for Procreate that said it had "even more layers" on the M1 iPad. They did this without Apple changing the RAM limitations.

NeonSilicon

@krassmann said:

@NeonSilicon said:

@krassmann said:

@NeonSilicon said:

@krassmann said:

• First of all fix the memory management!!! I bought a 16 GB iPad Pro but it can utilize only 5

The new iPad can use all of the memory it has. The limit is per process. In an audio setting, the AU memory usage doesn't count against the host. If someone (anyone) comes out with a host that uses more than 5GB of RAM, I'll purposefully make my AU's crash in that host. Each AU is a process too. The limit on AU's is much more strict. A project with a host using 1GB of RAM and a ton of AU's could easily use up all 16GB of RAM. If some instance of Facebook got launched and sucked up 10GB of RAM, all of the AU's would be killed. (Not quite true since iOS uses memory compression to enable more apps to be running with more RAM usage.)

On an 8GB iPad Pro, two apps trying to use 5GB of RAM would be constantly forcing each other in and out of memory.

Apple may well make some moves in iPadOS that changes the way RAM usage works in iOS 15, but I pretty much doubt it. It isn't really broken and it's not a problem.

I checked my RAM usage on my iMac today. I had 5 "Pro" apps running, MainStage, Reaper, Xcode, Affinity Photo, Affinity Designer. I had Firefox and Safari going. Mail, Apple's horrid music app. Three copies of iTerm. Mail. And a couple of hundred other processes going. None of them were using more than 1.5GB of RAM.

Edited to say, sorry for the rant, it's not aimed at you @krassmann. I'm really just trying to reassure people that this isn't going to be a problem. The reporting on this is getting kinda out-of-hand.

I contradict, it is an issue. Maybe not in our sweet little audio world for the reasons that you mentioned but for instance this limit is actually limiting the number of layers you can use in Procreate - that’s what they said. Just read this thread. The users can not have more layers than with their old iPad Pro, some of them even less. Some people return their new iPads because of that. I can understand their anger. If you are a professional and you can not open your projects - WTF. Apple needs to fix this.

I mean honestly, if your laptop’s OS would have such a memory management, what would you say? Let’s not declare darkness the standard instead changing the light bulb - if you remember this old Microsoft joke.

There is absolutely no reason Procreate needs to have all of the layers in memory. My laptop has 4GB of RAM in it. With normal swap settings, that means I have about 8GB total of RAM to use. (I'll note here that iOS is actually more efficient with RAM than my old laptop.) I was able to run Photoshop on my old laptop with huge numbers of layers. Actual Pros didn't complain about the limits of the RAM usage back then. There are plenty of ways to use RAM efficiently in a photo editing/graphics app. The "disk" storage on these things is faster than the RAM on laptops that professional graphic artists used to do huge projects on just a few years ago. Just like samplers can stream from disk now, graphics apps don't need to have every layer in RAM. They can efficiently composite into the image being displayed and only have what is actively being manipulated in RAM.

So, you want to say the developers of Procreate didn’t craft their software properly? If 4 gigs is enough to do anything why would a professional who uses mainly one software need a machine with 16 or more if you can just install an ultrafast SSD and you are good? I’m a developer myself and I’d would basically say its better to have your project’s data in the RAM to write efficient code. I agree that you better have large data on disk like audio files and stream them but then your disk I/O performance becomes a limiting factor for how many files you can play back at once. It’s always a trade off between performance, usability and simplicity of the code. Honestly I don’t feel that I know enough to judge Procreate’s decision to have all layers in RAM but its also possible that you are right and they didn’t do their homework.

I didn’t know there’s no LLVM for iOS. I’m not an iOS dev… It’s open source, shouldn’t it be easy to compile it yourself? Do you really want to develop on the iPad?

What I'm saying is that applications have been able to do very pro levels of graphics well before we had anything close to 5GB of RAM available with or without SWAP. LumaFusion is able to handle multiple streams of high-res video flying through the system and doing all sorts of graphics processing on them in the RAM limitations.

As far as I know, you still can't have any form of compiler -- including JIT -- on iOS itself. If you could, then that would solve the issue of running open source software on iOS. It would be huge for me personally because it would enable a couple of major uses I want for developing a couple of applications I want to do.

StudioES

Would lifting the RAM limit allow multiple instances of resource-heavy software like Kontakt/Reaktor/Omnisphere?

...without requiring the developers to recode or understand how memory-management works on iPadOS?

AudioGus

renaming file extensions

LOL

NeuM

@SevenSystems said:
@krassmann @NeonSilicon I must say I agree with krassman here, it's not the developer's business to develop around strange limitations in the way the OS handles virtual memory. In 99% of cases, it's pretty simple. Memory is used for anything that's currently happening in the app and your project, and the disk is used for saving and loading your projects. It has been like that since computers came into existence. (with a few exceptions in edge cases like audio tracking).

The problem is that iOS is the only operating system in the universe* that can't swap.

. * maybe Android can't either, but still, swap has been invented before the bronze age in order to deal with excessive memory usage gracefully and transparently.

Apps shouldn’t be using “excessive memory.” If they are, the developer hasn’t done a clean job of programming.

AudioGus

Found this chart showing what hardware is still supported by the latest OS. I imagine that supporting almost seven year old hardware and the latest and greatest makes for some interesting challenges.

https://en.m.wikipedia.org/wiki/IPad

NeonSilicon

@ocelot said:
Would lifting the RAM limit allow multiple instances of resource-heavy software like Kontakt/Reaktor/Omnisphere?

...without requiring the developers to recode or understand how memory-management works on iPadOS?

No, lifting the RAM limit wouldn't help because AUv3's have much tighter restrictions on iOS than normal apps do. Although, I doubt if even these are using more than 5GB of RAM. I'd guess that Kontakt and Omnisphere could already be ported to iOS --- maybe. Reaktor is a bit different. It might not even pass the limitations on having a compiler or JIT on iOS.

tahiche

• Sample rate nightmare. I don’t who’s fault it is, but it’s a mess. Inexistent apps taking over the sample rate, different sample rates in an app amd in a auv3 plugin within...
• Use external storage as actual external storage.
• End the sandboxed app file storage paradigm. We need to be able to access the same sample/file or whatever from different apps without having to copy it over and over. It’s just stupid.

Iskander

Backup/Restore the device with external drives and Sync Folders without using iTunes, iMazing etc.
Incremental Backups please…

NeuM

@Iskander said:
Backup/Restore the device with external drives and Sync Folders without using iTunes, iMazing etc.
Incremental Backups please…

100%. I’d love to be able to connect any iPad to an external drive and back up the entire system. Since I no longer have a desktop computer this has come sharply into focus for me.

krassmann

@NeuM said:

@SevenSystems said:
@krassmann @NeonSilicon I must say I agree with krassman here, it's not the developer's business to develop around strange limitations in the way the OS handles virtual memory. In 99% of cases, it's pretty simple. Memory is used for anything that's currently happening in the app and your project, and the disk is used for saving and loading your projects. It has been like that since computers came into existence. (with a few exceptions in edge cases like audio tracking).

The problem is that iOS is the only operating system in the universe* that can't swap.

. * maybe Android can't either, but still, swap has been invented before the bronze age in order to deal with excessive memory usage gracefully and transparently.

Apps shouldn’t be using “excessive memory.” If they are, the developer hasn’t done a clean job of programming.

My recommendation was not using excessive memory. I agree that it should be a design goal to keep that low. But the other extreme is also bad. If you start streaming everything from disk then your application could be sluggish as nothing beats RAM when it comes to speed (except CPU registers). You might also end up in a maintenance hell with your codebase as it will be complicated. You might encounter race conditions because the disk I/O influences the timing of operations. It should always be a well considered decision when you add complexity. The KISS principle - keep it simple stupid

Samu

@NeuM said:

Apps shouldn’t be using “excessive memory.” If they are, the developer hasn’t done a clean job of programming.

Depends on the definition of "excessive"

Imagine you'd have a tempo synced delay running at 1BPM with 8-16 bars of delay time?
That would require quite a chuck of ram...

supadom

Mostly improved emojis but some more stability would be nice too.

AlmostAnonymous

Hopefully some nice advancements in AR.
A nice AR AUv3 where I can take a pic of my room and it will insert an audience for the lack of gigs during covid.

NeonSilicon

@Samu said:

@NeuM said:

Apps shouldn’t be using “excessive memory.” If they are, the developer hasn’t done a clean job of programming.

Depends on the definition of "excessive"

Imagine you'd have a tempo synced delay running at 1BPM with 8-16 bars of delay time?
That would require quite a chuck of ram...

Hmm, a delay that supports one breve of delay at 20BPM has a memory footprint of ~80MB* at 48kHz. That delay happens to be working on 64bit floats and is 4 times oversampled. So, assuming the 16-bar delay in question doesn't need the oversampling and can run at 32bit floats, you could divide that by 8, but then you want to multiply by 20 to get to 1BPM and then do 8 times to get to 16 bars. So, 10MB * 20 * 8 =~ 1600MB and you've used 2 to 3 times the memory allocated to all instances of your plugin. You could do it as an Audiobus app and have plenty of room to spare on the new M1 iPad though.

• That 80MB figure is according to Xcode for a running copy of the AU on a 1st gen iPad Pro. So, it's a rough figure and it is actually 84.5MB. Everything else is a rough estimate too, just to get a scale.

wim

It'll never happen, but wouldn't it be nice to have a way to fully back up and restore to the exact state of the backup, without being forced to the latest OS?

[Deleted User]

I'd like Apple to switch to a longer release cycle. Every year they rush to get out new versions of iOS/macOS and it really affects software quality. Maybe it makes sense for iOS since they try to tie a new iOS version to a new iPhone model, but for macOS the release cycle should be longer. F#ck marketing people, more power to engineers

MacOS used to be very stable, then they switched to annual updates and you know what followed... Now every year they release a half-baked major version riddled with bugs/security issues and light on new useful features. The annual release cadence is not working for macOS, how long will it take Federighi to realise that?

Enkerli

Hoping for a “line in the sand” update with iPadOS15. Eliminate as much tech debt as possible (so, finish pulling the plug on IAA). Drop support for older devices (including my 9.7" iPad Pro). Promote iPadOS as its own “parent OS” instead of the poor sibling to iOS.

Make the M1 iPad Pro with Magic Keyboard into what it should be. So, full support for external monitors through Thunderbolt, complete suite of full-featured first-party pro apps (including the full Alchemy in the full Logic Pro… and Xcode!), enhanced multitasking, clearer paths for developers going from desktop AU to AUv3, maybe even a special section of the App Store for apps requiring such a machine…

Not expecting sideloading anytime soon, despite all the court cases. Some solution for very demanding niche products would be more than welcomed. Having “our” music apps mixed in with mass appeal products didn’t make that much sense in 2008. It’s just plain weird, now.

And WWDC would be the right context to make a big push for developers of pro apps. Apple has its “Pro Users Group” which helped the company get out of a deadend in terms of pro hardware. Now that Apple Silicon is here, a renewed push for pro software will require a broad range of third-party devs (not just the usual suspects). Since it’s an online event, those pro devs who wouldn’t have gone to San Jose will get access to what they need.
It might sound like a stretch to get UE5 on iPadOS. If we did get it, that could open up all sorts of possibilities for touch-first development (including MetaSounds).

We won’t get touchscreen Macs and we won’t get macOS for iPad. We can still get complex apps running on “laptop class” M1 iPad Pros.