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.
Comments
Not yet, but will add this I think. May also make the Standalone version full featured.
Another great preset!
I have to keep the song player, my son wouldn't be happy if I took it away. I may make it a slide out from the side one though.
This is one of those design decisions, I personally prefer sliders over dials, and long ones mean a lot easier to dial in what you want. I also want to consider those using the app on an iPhone. On large iPads or the Mac you can always make the window the required size, where as you don't get that choice on an iPhone.
So Dante is handling it right, that is a pleasant surprise! LOL
Oh dear, perhaps I should read all posts before replying! LOL
Hi @Rob_Jackson_Music , Do you have a personal/company position or preference on JUCE being used in Vibe Coded applications?
The oscillators appear to alias pretty severely. For example, take the default patch and switch to a saw wave. Play a high note. Notice how it almost sounds like the synth is going through ring modulation because of all the inharmonic frequency foldback.
You’re probably going to need to address that. Unfortunately it’s one of the areas where synth design gets difficult. Normally band limiting your oscillators will get you most of the way there, but you also support hard sync and wave folding. You’re probably going to need a combination of techniques and I imagine oversampling is going to need to be part of the approach. That’s going to make your synth a fair bit more computationally expensive.
The good news is your filters appear linear (biquad?) so they don’t need to be in your oversampling island. That will make things a bit cheaper.
for now you don’t need to stress this too much, there is no single one daw or other auv3 host on ios using trully native 96khz processing.. not even one.. At least based on my tests, would be happy to be wrong.
for now 😆✌️
Well... I don't have a position as such on Vibe coding other than I'm not going anywhere near it
But, for developing audio apps for iOS, I started off using Swift and Apple's audio APIs, but switched to JUCE / C++ over a year ago. I would never go back, for what it's worth.
While I'm here, don't think I saw it mentioned anywhere, but how much time would you say you've spent on the project so far?
Just to be clear, nothing against folks who do vibe coding. It's just something personally I wouldn't touch with a proverbial barge pole.
It is a good question. I haven't developed on iOS for over 10 years, so I am coming with some basics, but they are very rusty.
I started on the 16th of April according to my project folder, so that is 10 days, I have worked most nights and on the weekend in between being a father. So I am guessing around 60 hours, but some of that time is waiting on Claude to doing its thing, so I usually have 2 projects going on at the same time.
Impressive, thanks.
60 hours is a "light week" for me
, but then again, I don't have another day job, kids, or arguably much of a life to speak of... 
Thanks for the feedback!
I found a bug thanks to @dendy - It was hardcoded to 44.1kHz, and most host will open at a default of 48kHz, so not sure if that is contributing to what you are seeing. I will be sending an update out for this soon, would be great if you could let me know if this has fixed the issue.
It's an SVF (State Variable Filter), not biquad, but yes, it's linear.
if you just hardcoded it to 48 or you are using AVAudioSession.sharedInstance().sampleRate - that’s not ideal too .. just give claude my comment with my few points at page 1 and eventually tell him to go to internet and study deeply retared topocs on how this should be implemented properly to always listen to samole rate defined by host
yes, for now there are no hosts with real no-hw locked ssmole rates.
For now. It’s good to think about future
✌️
look at ZDF variant of SVF .. much better for synth than standard basic linear SVF ..
If you want to apply audio rate LFO (thise are that details which are shifting average synth to the area of great synth) you need to add 2x or 4x oversamling - without audio rate mod and saturation that’s ok, oversamoling not needed for this type.
The Audio Unit reads the host's sample rate in allocateRenderResources()
Standalone uses the AVAudioSession.sharedInstance().sampleRate.
I tested the AU with 192kHz and all good once increased buffer size and gave a little latency inside of AUM.
I will loom into ZDF, so long as it is performant like the SVF.
I have just added Polyphony support, to a per-oscillator everything synth, so starting to push at the iPad limits. Especially at 96kHz. But it is very usable!
What does audio rate LFO do I wonder, will need to research that .... I have modular, so have done the FM thing from an Oscillator to control pitch of another Oscillator ... but this is different.....
Heads-up @digitalferret - Worth noting that while they are related, handling host sample rate changes correctly, and dealing with aliasing are two different things you (or Claude or whoever...) need to worry about
There's a risk here, and I'm speaking in general terms, that vibe coding allegedly gets you past the hassle of having to learn how to code, but there still needs to be a pretty good understanding of DSP and "good" plugin design in general.
Otherwise... it might not be obvious that you need to prompt the stuff that @dendy is suggesting.
And once you've got your head round aliasing, bi-quadratic filters, convolution, decibels, FIR filters, fourier transforms, etc., etc.
Learning C++ will seem like a walk in the park, relatively speaking
Joking aside, I spent more time becoming a semi decent coder than getting to grips with DSP theory, but some of that DSP stuff was much, much harder to get my head round.
To my knowledge AUM too used just device HW samole rate .. if your soundcard supports 192kHz then technically yes in that case it switched but if you try change that sample rate at plain device iPhon/iPad without connected external soundcsed you get this error :
but if you use sharedRenderResource you are probably ok, ready for future when DAWs on iOS starts finally behave as their mature counterparts on desktop
)) ..
will test in my host when you relese new build (my app does true internal processing on 96khz regardless of HW device and then just downsamoles/upssmples result mixdown stream to match device HW
you should give a chance to claude code .. it’s big difference between just plain “vibe coding” - like “claude hey donthis nice cutoff knob for me” and between true “agentic engineering” ehere you use it as tool but still you have complete deep comtrol and understanding about code, patterns, structures and reasoning why it does whst it does .. that latter is almost like coding it by hand for yourself, it just needs fraction of time and you have total control over code and it’s structure, claude just does manual writing of code based on thorough plans you first make together ..
i am developer for 30+ years but thus is completely new paradigm .. i am using “agentic engineering” more and more in my daily job and it’s incredible great tool if used properly by senior experienced dev
of course.. it’s very different, much deeper and complex approach than just plain “vibe coding” of beginners - that doesn’t get you too far :-)
Fair point, I use "Le Claude" and "vibe" interchangeably as I don't know (or care...) about the difference.
The main point was really: maybe you can get away with not knowing how to code, but can you get away with not knowing much about DSP?
Developing a plugin isn't just about knowing how to produce code.
Again, must stress, I'm speaking in very general terms here.
@Squishy @dendy
So this is tonight's effort, from 8pm to Midnight (I am in Australia).
Polyphony works, but I am not 100% happy with the sound yet, it is harsh and washed out, my mate Claude is onto it.... any suggestions for polyphony are welcomed!
The only DSP I have done, was on bare metal on a MCU, pretty basic stuff via the Daisy platform, here it is - https://github.com/remixed123/Experosynth
I do know C very well and C++ as needed, I've developed IoT devices and manufactured in the 10s of thousands.
My current approach to my lack of DSP knowledge is to listen with my ears, and ask Claude questions, and also chat to ChatGPT a little also...along with listening to some great advice from people like yourself and @dendy
The aliasing wasn't something I noticed till you pointed it out, as it is happening a range I am not usually making music, or even testing at. It will be something to approach at some stage, not something I have done any research on yet.
My current issue is Polyphony, I have improved it a lot, but still not good enough yet.....some patches works really nicely, some are horrible, still working on it, but Claude has done a good job of cleaning it up from the initial implementation.
I tested with an Arturia Minifuse 2, which goes to 192kHz ... I was getting that error till I changed to this device...also realised it sounds so much better than the little SoundBlaster X1 thing I was using.
look at this from different angle - you can learn about DSP when working with claude code at absolutely superrior level if you want, faster than you can imagine .. believe me.. i was very skeptic to this entire tech, but when used properly as tool for actual LEARNING - it is like being 4 coders + math expert simultaneously
)) Sometimes i don't do any code i just discuss with that think, i keep him search internet about relevant papers on some topic, then i keep him summarize that stuff and explain it to me with references (so i can verify it's facts not hallucinations).. it helps you learn and understand DEEP stupf 10x faster..
keyword is "ACCELERATE" framework on iOS.. those are low-level methods optimised for DSP stuff .. it makes huge difference in performance aspect ..
@Rob_Jackson_Music - here is a quick little few questions I send Claude, using @dendy 's suggestion . I can then continue from there, discussing how we can implement with the current architecture, what refactoring is required, what impact will this have on performance and so on.
Are you familar with the "ACCELERATE" framework , and could you utilise it to improve my efforts at polyphony? If so, how could you utilse to improve the harshness I am experiencing?
Yes, I'm familiar with Accelerate. It provides vectorized DSP operations (vDSP) that operate on entire buffers at once using SIMD/NEON hardware. Here's how it could help with poly harshness specifically:
What Accelerate can do for poly sound quality:
Post-mix soft knee limiter — vDSP_vclip or custom vectorized tanh/soft-clip applied to the mixed poly buffer. Unlike the per-sample tanh we tried before (which was too aggressive), a vectorized approach lets us do a gentler, multi-stage curve efficiently.
DC offset removal — When multiple voices with wavefolding sum together, DC offset accumulates and shifts the waveform asymmetrically, contributing to harshness. vDSP_deq22 (biquad) can implement a DC-blocking high-pass filter on the mixed output with near-zero CPU cost.
Vectorized smoothing/lowpass on the mix — A gentle 1-pole lowpass on the summed poly output to roll off the harsh upper harmonics that stack when folded voices combine. vDSP_deq22 again, set as a subtle lowpass around 16-18kHz.
Buffer-level RMS normalization — Instead of our current per-voice gain scaling, compute the actual RMS of the mixed buffer with vDSP_rmsqv and normalize dynamically. This responds to the actual signal energy rather than just voice count.
My recommendation — the biggest wins for harshness:
• DC blocking filter (near-zero cost, removes asymmetric distortion from stacked folds)
• Gentle high-shelf rolloff on the poly mix (tames the harsh upper harmonics that multiply with voice count)
• RMS-based gain normalization (responds to actual loudness, not just voice count)
These would be applied in processBufferPoly after all voices are summed but before effects. Want me to implement these?
Just that first suggestion actually terrifies me.
That said, I'm easily scared. 
Sorry I can't get into the weeds why, and at the end of the day, it's your project / your code. Err... kinda.
This is the one! Thanks, it will make a huge difference, poly is now sounding lovely. What else can this thing do.....must sleep!
I'm back
Sorry if previous comment came across as snarky - that wasn't the intention. I was just in the middle of writing some actual code so a bit limited in terms of bandwidth... Anyhoo...
Can I ask a potentially stupid question @digitalferret ?
I think the first time you mentioned the issue, you talked about your synth sounding "harsh and washed out" in poly mode.
Have you been using any kind of metering at all, and / or seeing if what's coming out of your voice mixer stage is generating values over 0dB?
The reason I ask, is because if you haven't, and it is, then that's a much simpler problem to solve:
Just turn everything down in poly mode (at the very least).
Did you try that?
@digitalferret
one big advice - never keep claude just "do something" - keep him to explain to you why is he doing every single step and try also understand and learn the theory behind that, why is he doing it.. sometimes he even makes wrong decision, or takes shortcut, or does workaround insterad of doing things properly - but when you discuss with him about that, he often realises that he made mistake or picked not optimal solution .. never take at first what he delivered to you, always question and ask .. take this project as learning course.. goal is not to build synth, goal is to learn as much as possible on the way.. i think that's only real meaningful motivation to do this little project !
Also work on persistent memory and skills -> build weill structured persistent memory and set of skills which so he can reuse obtained klowledge and learn from own mistakes.. this is big deal - with proper persisten memory strucutre and proper skills set you can go VERY far - if you are willing to really learn and understnad the underlying theory behing his decisions. To really undersrnad WHY the code is written the way like it is.
I didn't think were snarky at all .... this is some feedback I got from a Reddit user
"Some of us got morals and ethics, care about other people instead of shoving mindless monkey shit into an already saturated market. You’re diluting the pool of marketing views from actual developers, taking sales and downloads from people that actually know what they’re doing. I wish all of you would stop publishing all together and take some classes on culture and how it is built and destroyed.
This is how you destroy culture.
You’re a tourist that specializes in pollution"
Regarding the harsh sounding poly, Claude recommended Volume Stacking as the likely first thing to resolve, but it has gone well beyond that, here is a list of what it has done and why.
Added gain smoothing — The gain now transitions smoothly between values instead of jumping per-buffer. Fast attack (voices added → gain drops quickly) and slow release (voices end → gain rises gently). No more pumping.
Phase randomization (SynthVoice.trigger)
• Each oscillator in a new voice starts at a random phase (0.0–1.0)
• Prevents the loud transient spike when multiple voices trigger a chord simultaneously
• Mono mode is unaffected (only applies in poly voice trigger path)
DC Blocking Filter — Removes DC offset that accumulates when multiple folded waveforms sum together. Uses a high-pass at ~20Hz. This prevents asymmetric clipping that sounds harsh.
Adaptive High-Shelf Rolloff — A gentle lowpass at ~16kHz that scales with voice count. 1 voice = no rolloff (pristine). 8 voices = 25% rolloff blended in. This tames the harsh upper harmonics that multiply when folded voices stack.
RMS-Based Gain Normalization — Uses vDSP_rmsqv to measure actual signal energy and normalize to a target RMS level. This replaces the old 1/cbrt(voiceCount) heuristic with real measurement — it responds to what the audio actually sounds like, not just how many voices are playing.
Warmth EQ (vDSP_deq22 biquad)
Two cascaded biquad filter sections:
• High-shelf cut at 8kHz (-3dB) — removes the harsh "digital sparkle" that stacks with voices
• Low-mid peak at 300Hz (+2dB, Q=0.7) — adds body and warmth, like an analog output stage
• Scales with voice count: 1 voice = bypass, more voices = stronger EQ
Soft Saturation (vvtanhf)
• Vectorized tanh across the entire buffer in one NEON pass
• Drive scales with voice count (1 voice = clean, 8 voices = gentle saturation)
• Max 60% wet blend — rounds off transient peaks without squashing dynamics
• Makeup gain compensates for tanh volume loss
Voice-Steal Crossfade
• When a voice must be stolen, its current audio is captured into a ~5ms fadeout buffer
• On the next render, the stolen voice's audio is linearly faded out while the new voice fades in
• Eliminates the click/pop that occurs when a voice is abruptly cut off
Things it also recommended, but not implemented, as they are big hits on resources.
2x Oversampling for Wavefolding (vDSP vDSP_vgenp + decimation)
Wavefolding creates harmonics that can alias badly. Process wavefolded voices at 2x sample rate, then decimate back down with a vectorized anti-aliasing filter. This is the single biggest quality improvement possible for folded sounds — removes the "digital grit" entirely.
Spectral Limiter (vDSP FFT)
FFT the poly mix, identify peaks above a threshold in the frequency domain, attenuate them, then IFFT back. This surgically removes the specific harsh frequencies that stack in poly without affecting the rest of the spectrum. It's how mastering limiters work.
Wow, that's harsh. I don't think that's cool at all.
Um... about those levels, did you actually check them as I asked? There may be a point to why I'm asking...
I'm trying to help.