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
Probably pointless, but interesting exercise! Tried using other effects to process the CV, but most are tuned for audio, adding harmonics, possibly filtering out DC offsets, etc. so the results are pretty much useless. I wonder if you can pass this virtual CV to Drambo? (I don't have it yet)
@mifki - small bug in the Mac standalone: if play isn't running in the toolbar some buttons and knobs stop responding. Pressing Play, then stopping an internal clock is a workaround.
This pause button pauses the engine completely, and it causes problems with some module controls. There's not much I can do - there's no global clock or transport to control with this button instead of pausing the engine.
OK, it's not a problem as there's an easy workaround. Thanks for the response.
We can already do a lot of this within mirack, but...
Try running an envelope through a LPF (or other filter types). When the resonance is turned up the envelope warbles/buzzes at the cutoff and this decays depending on the amount of resonance and how much the env (or other CV) excites the filter. A compressor can sort of add extra stages to the env when it crosses the threshold. Waveshapers can be fun and granular processors can be fun too if the grain size can be set big enough.
The key for any processing is that low (CV) frequencies are allowed to pass. What makes this kind of stuff interesting is if the controls happen to act (and interact) in ways that are not necessarily straightforward but musical nevertheless.
I’m planning to make a breakout box that would collect all outputs from the back of some cv capable stuff I have and make them easily accessible.
I’m not sure about my rme digiface usb and babyface.
Some say that the headphone outs are dc coupled others say it’s not. If anyone tried and could enlighten me that would be great.
Else, I’ll need to measure it, which I’ve never done before.
Is it just taking the difference of measured cv signals at its lowest and highest values?
@mifki or anyone,
Any response yet to these questions about the Marbles module?
Enable Multi-touch in the settings.
Sorry, looks like these features are not yet present. I'll see if I can add them.
Thank you for the response.
I passed on the advice to try enabling multitouch to the other user but he was not satisfied, so this explains why.
A question.
I've been trying to get MiRack to start/stop using host sync.
I have managed to get it to successfully play
the down beat and start/stop in sync with host clock.
I have also managed to get it to reset back onto the one
but only after I hit start/stop twice rather than once.
Here is a screenshot of my first drum machine.
Could someone please double check it for me.
Thank you in advance.
@Gravitas
I found this to be the easiest way to achieve that...
Or you can use f.e Logic - OR out.
Thank you.
I was trying the Logic module when
I figured out a much simpler answer.
Here's a screenshot.
I reconnected the sequencer using the example you
provided and connected the ,'start output', of the
host sync module to the ,'reset input', of the sequencer.
The ,'run output', from the Clock goes
to the ,'run input', of the Sequencer.
The clock is being sent from the Clock to the sequencer.
I've already changed the mixer as
the first mixer didn't have any AUX.
It start/stops every time now with AUM.
The second screenshot shows the menu settings.
@Gravitas
Yes, there are several approaches to the same end. I like to use it as above, because with the highlighted settings enabled CLOCKED handles everything from the host side - using two wires only - and then can distribute the necessary signals to any seq in the patch. I think it's more about what helps you to visualise signal paths, keep track of your connections.
You're spot on.
I'm going through several different combinations so that
I will know which ones to use in the future for my purposes.
The Ableton Link module is next on my list.
@gravitas , @0tolerance4silence
Rather than use the BPM output from the host, I think it's much better to run the Host Sync module clock output to the Clocked module BPM jack.
After that I patch everything from Clocked and it seems to do everything I need.
My thinking on doing it this way is I want Clocked's pulse to be as close as possible to the host's. If it's running independently just based on a BPM value, I see large potential for sync issues and drift. The pulses coming out of the host sync clock 8 times per beat should keep a much tighter sync, I expect.
>
I had tried that initially but I didn't know about the modes.
It instantly went to double the BPM.
What is P8 mode?
I noted that Clocked is automatically in CV mode.
Agreed.
I tested it this afternoon and it drifted out of sync after about 10 mins.
It seems to be doing so even more so now.
The Bpm LFO is also much tighter now.
When I press ,'start', it accelerates to 120 Bpm and then holds time rock solid.
Can MiRack accept external midi clock?
Also can I get the Ableton Live module to sync like the Host sync?
It seems that host sync is much tighter even with
sending the Bpm out to the Bpm in for Clocked
Thank you for the tip.
@wim
Tbh I use it that way because it's the fastest to set up from 0.
Giving it a second thought I'm still convinced that it's the least taxing approach.
I see bpm out as a single variable, like a cv. Clock on the other hand is a constant flow of pulses.
If host is not slaved to an external clock than I presume bpm is 'perfect', without any jitter, but clock due to its nature - whatever the resolution - is prone to imperfection.
From my experience host sync is always the most reliable whether it's IAA (optional) or AU (built in). Midi clock or Link from time to time can be erratic.
@Gravitas
Standalone miRack will accept midi clock from midi port, miRack AU will accept if routed through the host and host is not filtering out midi clock signal (In theory, never tried myself).
Link has to be enabled in the settings in order to work, but it should work like any other Link enabled app.
It P8 stands for Pulse / 8. So, if you set the Host Sync is set to send 8 pulses per beat in the first step, then you need to set the mode to match. The default is to listen to the CV that says what BPM is. The "P#" settings tell it to listen for pulses then divide to calculate the BPM. In that case, the BPM display is informational only, what is really driving the clock are the external pulses.
Sure, it's a few brief steps faster, but I pretty much guarantee you it's less accurate in terms of host sync. If only internal sync within miRack is important and synchronizing with the host or other plugins isn't important, then yes, a single clock source set in BPM might be the most accurate. I can almost guarantee you you're going to get drift against the host and other apps if you do it that way though.
When you use BPM, the only sync between the host and miRack is at the point you press start. They both start at the same time and they both start at the same BPM. However, if you change the BPM, (I assume) a new sync doesn't occur, only the changed BPM is communicated. So, unless AUM and miRack independently adjust at exactly the same instant they will be off.
Think of two cars starting off at the same time and speed. At first they're fine. If one is a fraction off from the other then they start to drift apart. If someone radios them to increase speed, they do so, but unless they increase at exactly the same rate, yet another shift occurs. That's what BPM CV is like.
But, if one driver is constantly referencing the other car's position, they're always going to be as close together as possible.
Of course, it all depends on what's most important to you, so whatever works best for you.
[edit - on this point...]
I think this might be a misunderstanding about what's happening with the BPM output. It's not sync. It's just a value communicating the BPM of the host.
@wim
Hmm... I've always seen it as 'one car'. Like, AU integration means AU is simply 'borrowing' host tempo, not 'following' it. Just like Rozeta or Drambo shouldn't go out of sync just because host tempo has changed. But since miRack is made to be able to interact with outside world, while mimicking it inside 1:1, you might be right. That's how it would work in a hardware that's not tempo, but only transport synced.
I'll take your guarantee for a ride
Re edit:
That's exactly why I think it's more accurate. Sync ITB always gets looser as cpu increases, and keeping things in sync is taxing. AUs simply hand over that task to the host.
Then you still don't get what I'm saying.
Sync is the app listening to the clock of the host. BPM is just a value telling the app what speed the host is running at. There is no sync (other than start/stop) in that scenario.
Using the Clock output is using host sync. Using the BPM isn't.
[edit ... of course, often when I make an absolute statement like that I get proved wrong by a developer. I'll be happy to be proved wrong, but I don't think that will happen in this case.]
@wim
I do.
I've always presumed that bpm out would provide the equivalent of integration between host and any other AU that's reliant on host tempo.
edit: time for testing
@wim
You're right
I let it run for couple of minutes > drastic tempo change > repeated couple of times then left it run for 15 min, came back and it was slightly off.
Thanks for your patience 😊
👍🏼 Cool. Thanks, you saved me the time setting up tests.
Did you by chance try a similar test with using the other method? There's always a chance that could be off too.
@wim
Will do later, also want to rerun the test so it's not random, same amount of time, 'same' tempo changes, any detectable cpu difference.
Will tag you in once done.
@0tolerance4silence @wim
I've tested it using Wim's method on two iPads side by side.
I speed up the tempo and then slowed it down.
The sync is much tighter.
Thank you both.
Edit: spelling mistake...That should be ,'sped', rather than ,'speed'.
@Gravitas @0tolerance4silence @wim
Really interesting + helpful discussion + problem solving regarding sync.. again, this forum showing what it does best.. thank you because I know I'll be running into this issue soon..