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.
(ANSWERED ("no (t yet) ") ) remove tempo jog wheel snap-to "markers", while keeping the loops?
Hi hi,
If espiegel or any other resident experts know 
,
if I load something like a breakbeat eg ashley's roachclip or funky drummer or something akin, in to a donut, from the original source and not some sample pack version, is always going to be a floating point value tempo not a whole number because of course the era, then it seems that creates these snap-to "marker" lines on the tempo jog wheel, it's not a biggie, its just a niggle, but they're kind of annoying when i'm doing something like practicing playalong material or practicing for a set even and regularly changing the tempo on the jog wheel and that jog wheel snapping (to these floating point values) while scrubbing. is there, does anyone know, a way to remove these snap-to "markers"? i can see why they do have a use but myself i'd like to turn them off
thanks
Comments
There isn't a way to turn that off.
You might want to add a feature request on the roadmap: https://roadmap.loopypro.com
I searched a bit and didn't find another request for that but you might want to give it a try first.
ok thanks wim!
If you use a widget such as a slider instead of the jog wheel to adjust the tempo you don't get the snap. That has the added advantages of being able to make it as long as you like and to set minimum and maximum values for scaling.
@Bruques , the only snap-to line I am encountering is at the loop’s tempo. Is that what you are talking about?
Out of curiosity, why is it a problem when practicing for the tempo to match the loop’s real tempo?
it's just a niggle, maybe its a touch of ocd or 'tism, but i'm not using that real tempo, and i can be going up or down in particular divisions of tempo and the snap is just a tiny unwelcome moment of no-thank-you i did not want to set the tempo to 89.16, i wanted 90, or 97.73, i wanted 97 or 96 or 98, godammit stop snapping to... etc.
also, i'm never going to play a set or record any piece of music in a floating point value tempo ever, and when mixing and matching different material, and being ready for mixing processes later in other daws of material recorded, and when collaborating with fellow musicians and when sharing clock between us, floating point tempo snapping is just generally in my way, and never going to get used
but i can see why it has its place, just not with me
I am not understanding how if you are all synched to a clock it matters if the clock is floating point. Everything will sync to whatever the clock is.
In case you don’t know, you can type in an integer tempo if you want.
It matters in general, as I say, for a variety of reasons, 1 being ocd, 1 being compatibility with other people, with a range of material, with mixing projects, with a wider context of working in whole numbers.
as its a minor annoyance taking just microseconds of time away, then adding in typing in integers to the equation isn't going to help, its extra slowness, this being a user experience thing.
i thank you for attempting to help but no, that doesnt help
In the case of 89.16, the next non-snapped value is problematic , too?
yes.
i mean its pretty much the crux of posting the original question. (Edit)
(edit: a bit like, in fact exactly like, when you snap to an adobe grid line, and then to pull away from its orbit to the next nearest point you can settle at for say creating a new grid line or making a selection, or drawing, is further than you wanted, so you have to zoom to an extreme or delete that grid line to be able to get to the new point, this is exactly like that as an experience, the next nearest bpm is a number of bpm away, whereas my preferred ux would be no such snap and i can settle on any whole number bpm at all)
it's fine.
the snapping gets in my way, which is though, an extremely minor thing, nevertheless, i would definitely find useful turning the snapping off. yet given that i cannot, i will do the widget approach, and no trains smashed today!
thanks
If you round off the tempo before finalizing the clip import, that'll get rid of one small annoyance for you. The jog wheel snap won't much and for sure adjusting the tempo to whole numbers is easier with the jog wheel than with a widget. Even though I'm not sure you'll be happy with the widget approach if avoiding decimals is important to you.
oh yeah there is that.
ok, admittedly, this is laborious but, i could reuse it, so, i may (or may not) make a stepped widget with all-the-bpms, maybe/probably mapped to something physical as well. given it's such a boring admin thing to create so many steps, i might just do it a bit at a time and keep adding values over the days ahead. ocd? 'tistic slightly? probably, but once it exists i'll be happy
thanks both of you
I use +/- 1, and +/- 10 buttons on my templates. That works real well for me.
actually @wim another approach maybe, you'll tell me, a slider sending a midi cc to mozaic and mozaic math rounding? and then mozaic sending a different midi cc back out, that is then mapped/bound to a second slider which is adjusting tempo on value change, but isn't actually touched, and only ever receives integers from mozaic?
or would it even need to math round, if its sending midi cc wouldnt that already be rounded, isn't the midi spec integers 0-127? i have some vague memory of floating point values being outright rejected by some past midi set up i had
If you round the tempo, the loop won’t be a whole number of beats long. you will want to trim the end slightly so that the loop is an integer number of beats.
Actually, it'll just time-stretch to the rounded tempo
^this. And the stretch is so small that the quality is excellent.
thanks, that's certainly useful, 1 out of 2 as it were, happier to snap to a whole number, albeit i would also like no-snap, but hey, moon just not on a stick.
there's a use case where having numerous loops of close but not that close tempos, i find results in not being able to land on in between integer tempo values via the jog wheel, and my ocd says but i want to use those too,, and then the experience of passing through the snap is a (minor) annoyance (to me)
as i said throughout, i do get the usefulness, i don't expect anyone else to necessarily also want to turn it off, this might just me only. actually this thread is way longer than it probably deserves now,
thanks for the help, all y'all.
cheers
In the import dialog, what I see if you round is a loop that isn't an integer length. It will round if you enter the integer tempo after importing.
I'm rounding on the step before that when you first import the track, not in the detail settings. Yes it shows a fractional difference in number of beats, but it gets stretched to fit anyway on playback in the clip (I think). Anyway it works satisfactorily for my purposes.
Anyway, this is somewhat off-track.
Hummm … or maybe I have that confused. Oh well, don’t care.
The pictures in my post are out of order. The last picture is the first opportunity one has to change the tempo. Entering a tempo of 82 instead of 82.15 leaves you with a loop 1.02 bars long. So, it drifts out of sync with loops that are 1 bar long if left to loop.
The middle photo shows that the length is the same as shown in the import dialog if you round the tempo without trimming.
If the loop is constantly retriggered it won’t be noticeable but if left to loop it can.
Maybe I am overlooking a way that doesn’t involve trimming. When you do this, are you ending up with a loop an exact number of bars without trimming?
Sorry, I'm pretty busy right now and not really motivated to get to the bottom if it anyway. If I'm concerned about fractional BPMs and if its the first clip so that it sets the project tempo to a fraction, then I just quickly fix the project tempo. I think this is the workflow that I mistakenly remembered as something I did at the import file stage.
The jog wheel thing doesn't bother me and the OP is ok, so I'll move on.