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.
Romplers and sample rates 44.1k or 48k [solved]
![[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
Not problematic at all. Carry on with your music making. 😁
As long as the plugin sample rate converts as necessary, no problem. Most do the right thing these days.
App developers have to deal with conversions between audio formats. Apple provides api (application programming interfaces, i.e. code routines in IOS) for these conversions that insure high quality results.
Sometimes we see problems around these issues in our DAWs with new IOS updates but
conversions between formats are going on in all our apps and in IOS with few problems.
To convert from 44.1 to 48 the math involves interpolation:
It does sound a little like the Ghostbusters warning but writing apps is not for the faint hearted.
You do ask very interesting questions... trying to find good and understandable answers is engrossing and time consuming. Of course, sometimes I get the wrong answer but that's the benefit of a good forum to doublecheck my misunderstanding of complex subjects.
I just did a deep dive on Euclid's Algorhythm and how it re-surfaces in Euclidean Sequencers.
I ended up thinking I might be more interested in numbers that don't have common factors to create polyrhythms. There might be a Mozaic script worth writing... you can use 2 scripts with conflicting PPQN's and get there pretty fast: 3:5, 3:4, 3:7, etc.
I digress... and that's often a good thing, for me.
Like a CPU, I'm always running... finding good questions is the key to a productive day and a productive life. Curiosity is the power supply.
If the conversion went wrong, pitch is almost exactly 50 cent off.
With instrument libraries it means when you play a C on the keyboard, the response will be either B or C#.
A melody is more difficult to tell if you don‘t know the original tuning and speed, which is also slightly altered.
(but in fact these cases are rare today and IOS does a solid job in auto convertsion)
No. It involves lots of stages of high order FIR filtering (typically). Are you going to be bothered by the results? Probably not.
It's not exactly efficient and it would be much better to do the SRC when the files are imported to a project than to do it each time the project is run.
Simple SRC, like 2x, 4x, 8x, etc, (integer multiples) is pretty efficient and aren't going to involve multiple filtering stages for the most part. 44.1kHz and 48kHz aren't integer multiples so it gets much more complicated. You can get an idea of what's involved in this discussion on Stack Exchange, https://dsp.stackexchange.com/questions/67407/realtime-sample-rate-conversion
BTW, some of the sampled instruments in GarageBand on iOS are 22.05 kHz sample rate. GB runs the entire track for these, including the effects processing, at 22.05k and then upsample to 44.1 at the mix to the other tracks. Really annoying if you ask me.
A sampler that can do the conversion on import would be a good choice, the bit depth and format of the samples isn't going to be all that important. Best case for stuff on iOS (and macOS) would be 32-bit float format for the sample library, but a 24-bit int to 32-bit float conversion is pretty easy and quick in realtime (there are even vector library functions to handle this very efficiently). 16-bit sucks and should have disappeared long ago, but even there, if the 16-bit library sounds like what you want, converting to the format the software uses on import is most likely going to be good and give you what you want with efficient realtime usage.
Keep in mind that a piano app, unless it uses one sample per note, will have to resample the source samples anyway when played, so there's really no benefit in trying to use the same sampling rate in the host than the one at which the app's samples have been recorded originally...
For a drum app, if you make sure that you always play all drum samples at their original pitch, then there might be a slight benefit from the lack of the need to resample anywhere in the signal chain... theoretically.
Actually, the frequency ratio will be 48/44.1, so the cents is 1200 * ln(48/44.1)/ln(2) (need logarithm to base 2). This gives 146.7 cents, more then a semitone. Maybe your have a different definition of cents.
Obviously... my definition seems to shift with lack of sleep.
Can’t get used to the semitone = 100 cent, so subconsciously a 50 had to slip in as 50% substitute.
I once had a software e-piano (EVP-88 from EMagic) that did have this sample rate bug and (if memory doesn’t betray me completely) it was in fact very close to 1 semitone off.
At least I could play to backing tracks, if I shifted 1 key, which would be impossible with another 40 cents off.