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.
Samples rates on iPad Air 3 and similar devices - stuck or not
![[Deleted User]](https://secure.gravatar.com/avatar/c65f3204a06d27ec73276b6045ed7d23/?default=https%3A%2F%2Fvanillicon.com%2F91feed79a2b1ce0d17ae51ed4913d76d_200.png&rating=g&size=200)
The user and all related content has been deleted.
Comments
Nothing makes either of them superior... they are all stuck @48k (which is device specific). Some host will make it noticeable, telling you that you’re unable to switch, other host will look like they are switching successfully (f.e. 44.1k button highlighted, which is false), but in all cases they’re actually running @48k.
This can only be changed with an interface attached that supports variable rates.
Exporting a project at specific rate is a whole different topic... some hosts allow you to specify this (basically up sampling during the render) others will export at project rate, having no available preference (which is 48k on that device).
Up sampling can be as trivial as simply converting audio file to a higher rate. F.e in AudioShare you can convert a 44.1k/16bit audio file to 96k/32bit (which won’t make it sound ‘better’)
In practical terms up sampling during export can be beneficial because certain audio processing can utilise the additional rate/depth increase. (F.e most UAD plugins do conversion in real time, process the audio at higher rate and then convert it back to project rate, or some highend plugins offer oversampling to do the same, resulting better accuracy / sound). Exporting at higher rate therefore may force some plugins to do their processing ‘better’. But since we are talking about iOS (lack of standards, documentation, consistency) I wouldn’t be so sure about how much you actually gain. I’m sure some hosts /plugins handle it right, and I’m sure others don’t... also these things require a very keen ear/listening environment to pick up the differences... so imo total overkill on iOS generally.
You can check your rendered audio in any editor (f.e AudioShare) to confirm its properties.
Added to my todo list to investigate @tja
You don't want to double the samples to upsample. The pretty standard way to do this is to insert the needed number of zeros between each original sample to get the desired upsample factor. You then filter the resulting stream with an appropriate lowpass filter. The lowpass filter takes out the discontinuities introduced by the insertion of the zeros. You also have to scale the resulting samples because the adding of the zeros scales the energy in the signal by that ratio.
If in the generation of the audio you had higher frequency content, then you could see the difference in the files. For example, if you had a non-linear element that aliased the signal when it was generated at 48kHz. That aliasing would still be there if you upsampled after generating the signal. If the original signal were generated at 96kHz, then you would lessen the aliasing and might even eliminate it, so the resulting file would have different frequency content below 24kHz and might have frequency content above 24kHz that wouldn't be there in the upsampled file.
I suspect that it would be possible to see differences in the transients and attack of audio recorded at higher sample rates too. But, It'd take some experimentation to see what the differences looked like versus audio recorded at a lower sample rate and then upsampled. It would probably be interesting to look at recordings of hits to the bell of a ride cymbal to see what they looked like.
You can get a Soundblaster Play which will let you control sample rates:
https://smile.amazon.co.uk/Creative-Sound-Blaster-Resolution-External/dp/B073KTPNDR/ref=sr_1_3
Afaik all focusrite interferes will go up to 96k (again imo total overkill), I would say most dedicated semipro, prosumer interfaces will, but these specs are fairly easy to find out.
Add an AUv3 that can generate a, say, 40 kHz sine wave. Mixdown. Open exported file in a spectrum analyser. If the spectrum contains exactly one peak at 40 kHz, your mixdown has not been upsampled, but truly mixed and exported at 96k. Simple
(if it actually only mixes at 48k, then in the best case, the exported file should be completely silent. In other cases, you'll probably see several peaks from aliasing ("down-mirroring") of the "supposed" 40 kHz sine wave).
OK, but the interface should have nothing to do with export/mixdown
it's a pure software operation...
If by "export" you mean "click a button and write a file", then this is completely independent of any interface. An interface is only needed if you want an analog (or digital) live signal going out of your device.
The "export" feature of a DAW couldn't care less about the audio hardware. Heck it could offer you to export at 1024 MHz and it should be perfectly able to do so.
Maybe I should've read the whole thread 😬
It's going to depend on the host to set the sample rate to a different setting than the audio engine on iOS to render a file with a different sample rate than the current audio session for the iPad is set at. It's possible, but I don't know if any do this. Because of the way the AVFAudio system is set up on iOS, it seems that most DAW's run with what the system does for live processing. Having an external interface hooked up that can change its sample rate via software configuration allows the DAW to request a sample rate change of the AVAudioSession by calling the setPrefferedSampleRate function. This call might return with false even with an external interface if other things in the audio system are in control.
The docs for what is happening kinda start here https://developer.apple.com/documentation/avfaudio/avaudioengine/ with the AVAudioEngine and here https://developer.apple.com/documentation/avfaudio/avaudiosession with the AVAudioSession. The first thing to note is that the session is a shared instance. Everything goes through the same session.
You can see in the AVAudioEngine that it is possible to set the engine into manual rendering mode with a specified audio format, AVAudioFormat, and then render the graph with that. I've never messed with this part of the engine, so I don't know the specifics, but there are probably some complications in the graph for dealing with nodes that are set at different sample rates than the specified format. You would probably need to insert sample rate converters on audio file playback nodes and input nodes for example (if you were using these nodes in your host).
Yes with an audio interface attached you can run your DAW at any sample rate supported by that interface.
I think the confusion arose because you can render to different sample rates even without an interface attached, but in order to actually run your projects at a sample rate other than 48khz you need to have an interface connected on the newer devices.
@tja sorry if I've been confusing. In a nutshell:
When running "live", your DAW either needs to run at a sampling rate that your interface supports (simplest scenario), or it needs to automatically resample whatever internal project sampling rate it uses to one of the supported rates of the interface before it pipes the audio to the output. Any "reasonably well made" DAW should still be able to run a project at any sampling rate whatsoever and then convert at the output. I mean, conversion needs to take place anyway because no DAW in the world runs at 16-bit internally, for example. (at least I hope so). So if conversion has to happen for the bit depth anyway, then why not for the sampling rate. (I'm talking out of my perfectionist tail though!)
Mixing down (rendering, exporting, etc.) a project is an entirely "virtual" mathematical operation that has nothing to do with an interface. Most audio file formats support any sampling rate (44.1 kHz, 48 kHz, 96 kHz, 20000*π kHz, etc.), so any reasonable DAW should be able to export the project at whatever sampling rate has been set for that project, even if NO audio interface or any audio hardware at all is available.
Again I'm talking theoretical here, I'm not extremely experienced with developing DAWs. But I do know that if I developed one from scratch*, the above would be true
*I have but I have no idea when it'll be finished
Yeah to what @richardyot said. Having an external interface hooked up to your iPad can allow for running sessions at different sample rates if the interface supports different sample rates. I believe most do, but there are going to be some that don't. These sessions are not likely to be upsampled but run at the native resolution the session is set to.
I can tell you that with all of my interfaces when using AUM, Audiobus, and if I remember right every other DAW I've tested with, that the audio being passed to my AU's is running at the sample rate the session is set to. (This is true by default for GB since it is locked at 44.1kHz still if I remember right.)
What I was mentioning in my above posts are the exceptions that can occur in both a positive and a negative direction. A host can manually render to a different rate than the running audio session. This could be useful in, for example, a mastering host. I don't know if anything does do this, but it is possible. The host could configure the session to run at one sample rate to generate the output audio file and still use a sample rate converter AU to connect to the output audio ports for monitoring at whatever the rate the overall iPad session is locked to.
The other potential issue is that the system can refuse to set the sample rate to the one that the host is requesting even if the interface is capable of running at the requested sample rate. This would happen in the situation that some other software already had control of the audio session on the device. When this happens with AUM, it'll popup a dialog and warn you that the sample rate change didn't work. As a note. this happens to me in one situation on macOS too. When I launch GarageBand, it changes the sample rate on my interface to 44.1kHz and messes up everything else that is running on my system at 96kHz. Pisses me off every single time.
I just made a 24bit 96khz recording/mixdown on my iPad-1 with the Alesis ioDock-1
(in Multitrack DAW)
Well, there is content up to 48khz, according to half the sample rate.
With the iPad One I just tracked the empty channel noise, later normalized to -6dB.
The noise is fairly uniform up to 20khz, then there‘s a slope down to 25khz (quarter-circle shape) and the rest of the noise level is uniform again.
I repeated the MTD test with an Air-1 and the ID22 (which is a true 96khz device), this time with a (clean) e-guitar via instrument input.
Again there‘s content across the full spectrum, the decay of frequencies is as expected from a guitar (a 60 degree slope down up to 9 khz, the rest is uniform with 3 peaks, the most prominent at 39khz.
I don‘t think it‘s upsampled, as MTD switches the interface to the desired sample rate (set in preferences), which can be heard by the negotiation clicks.
But I have few ideas about the details of such spectrograms...
Sorry, I don't know of any... but there should be plenty!
iVCS3 comes with a separate Oscillator AUv3. I assume the sine wave is pure, but don't know for sure.
miRack has many to choose from.
The Oscillator by Jonatan Liljedahl. Free, but not AUv3.
I seem to recall there being talk of a tone generator or two in this thread: https://forum.audiob.us/discussion/40529/post-your-spectrogram-discoveries-here/