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
That's super neat and much simpler than I expected. Can you please upload a sample project to patch storage whenever you get the chance?
Confirmed: the problem is Atom responds to any CC value including zero for a pattern change. StepBud is sending every CC every step, so it's confusing the heck out of Atom. @cfour - CC's from StepBud isn't gonna work for now.
@blueveek - I guess responding to any CC value, including zero, is by design. I had assumed that a value of 127 (or over 64) would trigger a pattern change and zero (or under 64) would not. The way it works makes sense when I think about it since it's not an on/off switch, but a trigger.
Still, it seems like something that might trip people up, so maybe should be included in the documentation ( @tk32 ).
Good idea.
Yeh, now that I think about it, it's an excellent way to arrange songs. You can easily lay out and change which patterns pattern order, see them graphically laid out before you, easily mute patterns. Very cool.
Restricting the CC# switch range will be possible in the next update using the input offset modifier
However, also restricting to CC values of 127 (or over 64) also seems like a good idea.
Definitely, this is all pretty advanced stuff.
I think we might need an atom recipes book at some point!
Thank you!
Yeah, externalized song mode!
a very good set up! saved as a template
@wim Excellent! To be honest I was happy with notes triggering the patterns. I started looking at the CC option since the user xor commented on it yesterday (I saw his/her post today). I thought it was worth giving it a shot and perhaps learn about what was going on in the process. But yeah, I will continue to do it with notes. Your post on doing this by using stepbud is pretty cool, and perhaps simpler than doing it with Atom. In any case it is good to have both options
I found some issues while playing with stepbud to trigger patterns from atom piano roll2. I find that the behavior is slightly erratic, with some notes being played while others are not. In this case I have 2 patterns with 4 bars, while the remaining 2 consists of 2 bars. I have stepbud set to play one note for the duration of 2 bars. Since the first pattern has 4 bars I make stepbud play 2 notes to complete that pattern. The other patterns are triggered by only one note (thus 2 bars are being played).
Besides finding that some notes do not play (e.g. a chord is played in a pattern that has no chords) it also seems to start the first pattern (the one with 4 bars) at the beginning of the pattern or at the middle. This latter problem may be solved by having patterns that are the same length, but the missing notes (or the added notes) and the modified lengths is a bit problematic
Keep the 2nd note in StepBud, but disable it so that nothing plays on that step. It's likely that that 2nd note is re-triggering the pattern. You only want the first trigger for any pattern. The disabled notes after that are just to fill in space. You do not want those to play.
(Please note: I'm only saying this to provide information, not to criticize; there are many reasons that inform technical decisions from AU authors, some related to the target audience, others informed by the developer's personal use-case, and many related to financial incentives.)
A hard requirement
For Atom to be properly orchestrated by other AUs, those AUs must be emitting MIDI events in a sample-accurate manner. Because Atom does emit MIDI with sample-accurate timing, incoming MIDI from other AUs that is coarsely timed will appear to switch patterns at slightly incorrect times relative to the grid. For this same reason, using Atom itself to switch patterns (using notes for example) will work properly and accurately.
What does sample-accurate mean in this case?
It means that timing should not be affected by your buffer size (512, 1024 etc.). The unfortunate reality is that many AUs don't go through the trouble of offsetting the time of each individual note relative to the start of each audio frame. With a small enough buffer size, this can be imperceptible to the human ear, but larger buffer sizes will make this obvious.
Here's how inaccurate it can get with StepBud. Notice what happens when I change the buffer size at 0:14.
StepBud limitations
Unfortunately, StepBud does not seem to be sample accurate. This means that it does not properly time/offset its MIDI output within a frame, and because of this, timing will be affected by your buffer size. I'm pinging @cem_olcay here because I'm happy to have this information confronted, corrected or confirmed (it's been confirmed).
You can verify this easily by looking at the time column in my MIDI Monitor. Here, the output from StepBud is sent to the MIDI Monitor. If every number in the Time column is 0, it means that all MIDI events are emitted clumped together in a single frame, with no timing offsets. This behavior is incorrect, but sufficient for non-timing dependent tasks.
A personal note
I'm sad to see this. It's mathematically very simple to calculate timing offsets and properly emit MIDI events with intra-frame accuracy. I wish that all AUs on iOS would be sample accurate. However, I know the reality is not as neat as it could be in theory, and like I said earlier, not every AU has to do this, even when every AU could do this. Ultimately, target audience, the developer's personal use-case, and sometimes the financial incentives will take priority.
Hey @blueveek, thanks for your detailed post and pointing it out the next steps for a better implementation!
I'm trying to make StepBud sample-accurate by adding an offset value for each midi output message I'm sending.
So instead of this
Now I'm doing this
but still getting the "swingy" effect when I'm increasing the buffer size in AUM, like in the video you've uploaded. So, I don't quite understand how should I calculate the sample-accurate timestamps for the midi out messages.
I can read the host's buffer size, sample rate, bpm and of course I've got the timestamp->mSampleTime, so I assume I've got the everything I need for the calculation but I'm lacking the formula!
This is how's it looks like in the MIDI monitor, each event has a time offset:
From the screenshot, it looks like what you're doing is making sure each event in a frame is sent out one after the other (offsets 0, 1, 2, 3). But you're still clumping them together at the start. That's not what sample accuracy means in this context – it means that the beat might fall at any time during a frame, either at the start, during it, or right at the end. Jitter will complicate things even more, and sometimes the next frame could start before the current one finished (so you're overlapping samples), or actually later (so you're missing or skipping samples). A frame's start does not coincide with the beat start, far from it.
DM me and let's hop on a zoom call and I'll explain everything some more if you want.
I love seeing this. Two professionals solving a problem. ❤️
Have to agree, maybe this will result in all the *bud apps getting more solid timing in the end
The 'drifting' and 'cc overload' drove me nuts so I only have one bud app (Chord Bud 2) installed at the moment.
I'll wait for a sale on Helium and stick with Atom 2 for the time being even if multiple tracks per instance and CC are tempting.
Still hoping the hosts (Cubasis, BM3 etc.) will catch up when it comes to midi editing...
it's a... buddy code movie
Sorry to insist with this issue
, but I am still getting problems with notes triggering patterns in atom piano roll; even when the notes are coming from another instance of atom piano roll. Some notes are not played, and once again I get, at the end of the sequence, a pattern that starts from the middle instead of the beginning. I recorded a video of this with random notes, in case it helps.
What I ended up doing is making them all 1/1, so each step represents a bar. Then disable any additional steps added just to get a longer pattern. Remember, you only want the first step that triggers a bar.
BTW, there's an error in the screenshot example. The notes shouldn't be C-1, D-1, E-1, F-1, they should be C-1, Db-1, D-1, Eb-1.
Except for one of the notes that aren't playing, all those look to me like they may have zero velocity based on the color. What happens if you increase the velocity on them.
[edit. nvm, maybe they're just colored that way because they're selected. Next idea: try a different target app just to be sure it's nothing to do with the app that's playing rather than Atom?]
No matter what I do, I can't reproduce the other pattern triggering problems you describe. Both using Atom to trigger and StepBud to trigger are rock solid. Maybe screenshots or a video of the master that's triggering the pattern changes.
I'd suggest triggering using notes from Atom, just to reduce the chance of something about using StepBud is the cause.
Yeah, I selected those notes actually to show that the velocity was up.
I have tried it with Poison, FM2 and retro piano, and I get the same behavior.
I am amazed you cannot reproduce this, I get it no matter what I do!
I could try restarting my iPAD, though I feel it is unlikely that would fix something so random as this (as it only happens with some notes)
On the last video I am using atom to trigger the patterns (the second instance of Atom can be seen at the right of the screen). I did not even have stepbud present in AUM for that video. It is only retro piano and two instances of Atom.
Thanks for your feedback... as always!
@cfour Can you DM me the project? I'll have a closer look at what's happening.
I just noticed! You have Probability set to 85%.
That sorts the missing notes, I think.
I don’t see anything that explains the early pattern start though.
Great eye. That would explain it, definitely.
I wonder if I should add a warning or notification for new users when first using the probability slider? Though perhaps sometimes it can be nudged accidentally, so maybe these sliders should be a part of a sub-menu?
Ok @cfour, based on the video, it looks to me like you tapped on that 3rd pattern and it started playing when you tapped on it (as it should).
When patterns change by a midi note, they don’t pick up the focus if they’re not focused. Your pattern 3 changes color right when it starts playing, which it would only do if you tapped it.
If you want to display a pattern while another pattern is playing, you need to tap the focus button, not the pattern itself.
I’m not saying for sure that’s what happened. It’s hard to tell from the video, but that’s how it looks to me.
Here's another perfect resource to understand this, written by @j_liljedahl: http://devnotes.kymatica.com/ios_midi_timestamps
"It’s important to make use of the timestamping when receiving and sending MIDI, otherwise you’ll get ugly timing jitter that ruins the music."
@wim Yikes! The probability was at 85% you are right
! I must have moved that accidentally 
, I have not messed with that so far. Such a simple thing! And yeah, everything worked better by pressing focus and not the pattern itself to see what was playing, as pressing on the pattern triggers it 
I guess my only question that I have not resolved is why, when starting back to triggering pattern 1, does it start midway thru that pattern (i.e. bar 3 in my video instead of bar 1)? The first time the note triggers the pattern it starts from the beginning (as it should), but on returning to that pattern it starts from the middle
@blueveek Thanks for your concern! Not sure if you still want the AUM project to check this last question?
Yep.. the menus seems clustered .. long press is a good thing.. or.. choose/hide (customized menu) tools option .. thanks...
Not complaining but agree with above
When I am on the phone, I go to scroll the top menu to patterns and lots of times change a top menu setting
Not sure of the best solution as you have done a fine job
In fact when I am on the iPhone using atom I am in landscape mode, wish AUM could be in landscape mode on phone as I am constantly turning the phone
First world problems I guess
Yeh, I think we are talking about two different things. In the current release version, pattern trigger notes are auto assigned based on the position in the list. In my example I had four patterns. Those would trigger with the notes C-1, Db-1, D-1, and Eb-1 (the bottom four notes of the keyboard). My screenshot showed C-1, D-1, E-1, F-1. Those notes would trigger pattern 1, 3, 5, and 6. It was just a mistake on my part and I didn't want it to confuse you.
The next release will have some more flexibility as to which notes trigger patterns.
Sure, it would be more efficient, and also useful for other things. I wasn't downplaying the suggestion for StepBud, just noting a way around not having it.
On a side note: If you're using Atom to trigger clips, one way to get more on the screen without having to add a really long pattern to control a song is to turn down the Atom tempo to .25x. That way each quarter note is a bar.
With the “latest latest” update, Atom also got the ability to switch patterns with CC values instead of unique CC messages, so that can also make it mode suitable for sources that prefer to emit single CCs. You can also offset and spread the input from within Atom for more controlled pattern switching.