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.
Are there actually non-audio iOS apps that use multicore?
By now everybody on this list knows that iOS audio apps are using single core, but I wonder if there are any non-audio apps available that actually use multicore. Especially the new ipad have a stunning multicore performance in Geekbench, but on Google I can't find any apps or reference to apps that use multicore. Maybe there's somebody on this list that has some knowledge about this.
Comments
Some eggheads on the lumafusion forum sometimes get nerdy about this subject but beats me, I’m just a civilian...
https://forums.luma-touch.com/viewtopic.php?t=7261
In general 3 types of Apps benefit from having access to extra cores:
Image processing can often be done in parallel (e.g. split the image into 4 and do the work in 1/4 of the time)
Rendering of animation (from 3DMax,etc.) is massively parallel as each frame can be rendered independently to others and the results stored in a single file. Or video Streaming Apps that pull content from the network and calculate frames of video in parallel.
GUI programming often helps to have at least two threads when doing something slow, e.g. processing large number of files - this allows the interface to remain responsive whilst the worker does the hard work
Here are a few practical examples:
A word processor runs one thread to spell/grammer check new words and highlight those needing attention with colored underlines while another is accepting new typing input and update the document image.
A web browser that opens a page might launch parallel link downloads to generate the final page
A spreadsheet app might run calculations in one thread while still accepting input typing in new cells or popping up a graph window to display the results as an image that gets painted as results are produced by the other thread of execution.
In the world of audio apps soundiile conversions can be broken into chunks and performed in parallel like the conversion of a 24-bit wave file project to a compressed mp4 16-bit version using more than one core.
Anything that shows a progress bar while doing it's work is probably going to be performed as parallel tasks whenever possible to save wall clock time for the user.
Would you agree that, for a poly synth, distributing voices across cores would be a good use?
Audio apps usually do the GUI stuff on another core than the audio stuff. So they are technically “multicore”.
Probably not for this reason. Every synth voice is calculated by the same code and use the cores to execute 3-4 copies of the same code with different inputs probably steps over a dollar to save a dime.
Computer code is also "data" that needs to be moved on to and off the cores to run its task.
I suspect the contention in complex audio environments like a DAW or AUM running 6 Model D Synths is all the movement of data (audio buffers) that need to get mixed together before be put into the audio output buffer to be played. Miss the creation of the next buffer and the audio hardware just plays some short bit of silence which comes out as a sudden "return to zero" which we hear as a click or crackling.
So, the best use of cores is to load essential code and run it for as long as possible before moving it out for another process to have a shot at execution. So most of the madness is moving code, audio data buffers between code instances (like AU's performing FX tasks and the mixer function of the DAW) and all that code that responds to the home button or any random touch on the iPad.
If someone makes a great modeled (i.e. calculated piano like PianoTeq) it might deploy a clever multi-core strategy just as you might expect to insure more code gets executed but remember this App would only run on the multi-core products and users would scream "Planned obsolescence" and demand it be made to work on the iPad they bought last year.
So, having code that will use cores if available and still perform when they are not available would be required and then you'd face explaining why it works great lone but it's flakey when loaded up with other Apps in a DAW.
I think these developer's try to insure stability and single threaded apps for audio are the most predictable model to test, sell and support. Maybe one will share their thoughts on
parallel programming and making their apps "multi-threaded". It's really hard to design apps like this... race conditions, semaphore locks and the deadly embrace causing missed buffer updates. But there are "batch processes" like file conversions that are just no brainers to crunch regions of data in parallel to speed up the clock time for the overall effort.
Yeah. Any App with GUI will likely end up getting dispatched across available cores for the crunching and the GUI work. IOS might even reserve a specific core for all the GUI code that has expedited paths to the video display memory. The biggest design issue with iPads is managing the heat of the transistors as they deliver more and more work. Would you buy an iPad with a fan? I keep burning myself with my iPhone in my pocket. And we love to carry them in thick cases to keep them clean and ignore the heat.
You can only distribute audio processing tasks over several cores if you're in absolute control over the hardware. A single sample delay is crucial in that context.
Since this isn't the case in any desktop OS (which IOS is, too), your results (audio output) will depend on the OS scheduler, not your design or idea about the sound.
Dedicated (hardware) DSP systems run independant from the main CPU's task handling, but even there you have to consider carefully spreading code over multiple chips. Specs will tell how many samples of delay will happn and if the amount doesn't fit the task, you can't cross chip boundaries.
Many visual arts apps are truly multi-core and lean on the GPU heavily too. And modern games quite obviously make use of a greater proportion of modern iOS device processing capabilities.
Apple has been working closely with the likes of Adobe for a number of years now to help create apps that make the most of the majority of processing units Apple provide in modern iOS devices, even stuff like the machine learning processor.
Single core performance hasn't kept pace with what's commonly known as 'Moores Law' for a good number of years now. The biggest leaps in performance have been in massively parallel processing. But applying this to iOS audio isn't an easy task. Much like on the desktop I'd expect to see DAW's being the first apps that provide some form of parallel processing. But it would seem we're a few years away from that too.
Interesting point. So the new iPad Airs running on A12 are comparable to Macbook Pro from 2 years back when rendering movies... But, somehow this doesn't add up from what I understand, Lumafusion and iMovie on a iPad Air 2 (A8X) rendertimes are comparable to iPhone XS (A12).
As is so often the case with Apple these days, just because they're proving the tools for 3rd parties to utilise multithreading etc, doesn't mean they're making full use of those facilities themselves.
If I had to put money on it, I wouldn't be surprised to hear that Apple are going to create versions of Final Cut Pro and Logic that are optimised for iPad Pro's at some future point. But that's a significant manpower investment.
Back in the Steve Jobs days, he understood the importance of creating hero applications the show off the full capacity of a device's capabilities. I'm not so sure that Apple under the current leadership team sees things the same way. For them, it's all about margins, customer segmentation, and investor value.
@McD @Telefunky thanks this is very useful for understanding. u-he's polysynth plugins have a "multicore" option which (according to the user guide at least) distributes voices across cores, so that's why I thought it could be a reasonable use in iOS-land.
Of course you can distribute multiple (complete) voices to multiple cores, in particular if the voices are displaced in time anyway (intentionally by the patch, often combined with a random factor.
For a 'true' analog emulation that's not possible because the analog processing is almost free of any delay. You need control to keep the cores in strict sync to mimic this mode of operation. Otherwise the voices' individual filters would be displaced in time and that's noticable.
There's a nice implementation that 'steals' cores from the OS by Merging Technolgies.
https://www.merging.com/products/pyramix/masscore-native
In that case you have complete control over all cores that are hidden from the OS, with a tremendous boost in audio performance.
@Telefunky again, thanks! I've been a long time plugin user, but only recently I became interested in knowing more about the internals, so this is great
Loving the fact of bringing Pyramix MassCore into a conversation about multicore on iOS. Mountains and molehills come to mind even though it's a completely inappropriate metaphor. I think iOS is a good few years away from MassCore style solutions.
You entirely missed the point
The mentioning is not related to IOS in any way - it's about getting full CPU control for an application, without any interference from the OS.
The method will provide an embedded realtime system - if the application is designed accordingly.
But in case someone digs into the details on the Merging Technolgies website, it will also be quite revealing how few resources a regular OS actually leaves for applications (while doing it's hundreds of background tasks bs)