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.
Anyone with Musix Pro, Beatmaker 3 and iSEM able to help with a test?
I've been trying to use Musix Pro as an external MIDI controller for Beatmaker 3. I can get it all hooked-up and am getting sound. However, the output from Beatmaker 3 is suffering from a lot of pops & clicks. I've tried using MP to control synths in AUM, with zero issues. Same using MP to control standalone synths. I've also had no similar audio issues using the standalone version of Velocity Keyboard connected to BM3.
Is anyone able to do a quick test to see if they've a similar experience?
Any help would be greatly appreciated 
Comments
@el_bo : a place to start is to use a midi monitor to see the midi being received from the controller. I’ve never had BM3 respond differently to a hardware controller than a virtual one. There might be something in the MIDI stream that is unusual.
Also, make sure you’ve tried power-cycling the iPad and controller.
Thanks for the speedy response.
Just for clarity, Musix Pro is an app and so is a virtual controller, no?
https://apps.apple.com/us/app/musix-pro-midi-controller/id585857087
It's responding very differently to Velocity Keyboard when I use that in the same way. And MP works fine controlling AUM.
By power-cycling, do you mean running down the battery or a certain combo of buttons to hard-reset?
Also, I found this for MIDI monitoring. is there a better option?
https://apps.apple.com/us/app/midi-scope/id1185667452
Cheers
@el_bo : midiscope will work. I would also recommend getting streambyter or mfxMonitor (both are free) which can be used as AUv3.
By power-cycling, I mean a full power down rather than putting it to sleep and waking up.
If Velocity Keyboard causes no problems, you want to use the midi monitor to compare what it sends compared to musix pro.
Also, check your buffer settings. Pops/clicks can mean the buffer is too small.
Thanks!
I did restart the iPad first thing, but there seems to be various ways of powering-down so not sure we're on the same page. And it does sound like the buffer being too small. but even with just iSem loaded and only one key being played, the clicks happen all the way up to the 1024 buffer setting.
If i go with either of your suggestions, where would I put the plugin (I have one instance of iSem loaded)?
@el_bo : if musixpro is a standalone app, send midi to midiscope the way you you would send to BM3. And compare to Velocity Keyboard set the same way.
Got it!
For some reason I could connect Velocity keyboard, but it wouldn't read any events. Did manage a couple of tries with MP, though. But I have no idea what any of it means.
The first run gave these results:
Not sure why it's also registering hits from the green/Source 0 input, which remained unselected.
Here's a 2nd shorter (but not that short) run. Didn't track any of the MP inout, it would seem :
Does these show anything obvious?
@el_bo : do you get those ciicks/pops with musixpro regardless of what you are triggering? And you never get them with Velocity Keyboard sending the same MIDI and the same target in BM3?
I only tried MP with iSem in BM3. But I did try the same setup (iSem in BM3) with VK, with zero issues. Also tested MP triggering instruments in AUM with no issues. So the issue does not seem to be with BM3 accepting 'external' MIDI to trigger iSem, and MP seems to be outputting fine in other DAW.
Will try some other instruments in BM3...
So...Other instruments seem to work fine, within BM3 and triggered by MP. Switch back to iSem and the problems are the same. Did a screen rec. to demonstrate:
https://vimeo.com/manage/videos/848107135
Updated the title to ask whether anyone who owns BM3, Musix Pro and iSEM is able to replicate my clicking situation.
@el_bo : does it happen with all iSEM patches?
I notice that > @el_bo said:
Does it only happen when you play fast?
Does it happen if you play one note then another one with no overlap?
Does it happen with all iSEM preset?
Thanks!
If I play really slowly i.e leaving 2-3 seconds between presses it seems fine. But I don't have to play really quickly to get it to start. If I play once per second, the clicking starts. I did experiment some more with Velocity Keyboard, and if I play many notes simultaneously and very quickly I can get it to click...but i have to really go at it.
So it would seem obvious to suggest a CPU/buffer issue, until I load replace iSEM and the issues stop Also, this happens even up to 1024 buffer. And again, there's no issues when triggering iSEM within AUM via the standalone Musix Pro...even at 32 samples.
Something about this ultra-specific combination is freaking out, and I can't make sense of it. Would be nice to see someone repeat the experiment, but I get that it's a very specific combo of apps.
p.s. Happy to make another screen-recording to test specific ideas, if you think it'd help.
Does it happen with all iSEM presets?
Did you do a comparison yet of the midi musix pro sends vs what velocity on sends?
I happens with every one of the handful of presets I've tried.
And when I tried monitoring VK's MIDI, I could select it as an option to watch, but no data were recorded. I could try again. But if they both work fine standalone, with iSEM standalone, then I'm not understanding why it would show any issues when measured in standalone. Or am I missing something?
I really appreciate all of your help with this, but I can't rule out the possibility that there's something in the set-up or the way I'm trying this that I've got completely wrong.
Try this;
Once you have this set up, can you confirm that when streambyter is disengaged that no midi reaches iSEM?
Thanks! Got some stuff I have to be getting on with, so will try to do this later on this evening. Will update ya when I've done it
Ok, so…with everything set up as described (I think), MIDI gets sent to iSEM from both VK and MP, via Streambyter, and bypassing SB does cut the connection.
One curious thing I couldn’t work out the other day is why connecting via the named inputs/outputs for MP and VK doesn’t work. I can only make a working connection using 'AUM' Destination. Normally I connect stuff that works inside AUM so had never come across this. Is it normal?
>
Can you post screenshots showing what you mean?
Well, I'm not an AUM power-user. The extent of my usual MIDI routing is to connect an instrument to an AU MIDI device directly from the 3-line drop-down menu:
But this week I've been messing with the MIDI routing page. What seemed to be the obvious choice would've been to connect the standalone apps as below:
But I get no sound like that. In order for it to work, I have to connect the 'AUM' Destination out instead:
So when I followed your instructions, I had to connect it like this:
Is there something wrong in how I've done it? If not, I'm guessing there're other uses for the 'Musix Pro' Virtual Port that gets created.
@el_bo : in order to understand the routing, we need to also see the standalone’s output options that you have chosen. There are different ways that standalone’s send midi and have their ports set up.
It's ok...I've managed to work that bit out. In MP, rather than choosing AUM as a 'DESTINATION', using 'VIRTUAL MIDI' and "Send To listening Apps' gets me the desired result when connecting the virtual port. With VK I need to send to 'ALL' rather than AUM.
So, where we're currently at is that Streambyter is working as an effective active/bypass switch for MIDI being sent to iSEM from the standalne MIDI apps. I assume the next stage is to get some testing done in SB, right?
So, if SB works as an effective bypass, open its monitor while it is engaged and play a few notes with MP . Screenshot the SB display. Clear the SB monitor display and play the same notes with velocity kb and screenshot the display.
Try to play the same thing both times. You might also want to screenrecord it.
Then post the screenshots and we can see if there is a difference in the midi that might account for the issue.
I've no problem doing that, but just curious: If it is the case that the MIDI is different, why is there no issue when triggering iSEM via AUM or in Standalone? There seems to be something about sticking BM3 between MP and iSEM that causes the issues, and only in MP.
Anyway, take that as a rhetorical question. Got potatoes on the go. Will do the test after dinner, and post it in a few hours time.
Thanks for the help. I really appreciate it
@el_bo : the purpose of doing this is to see if there is a difference in the midi and then see if that accounts for the different behavior. It might not.
Some standalone apps and their AUv3 process things slightly differently. Since the only communication between the MP and the AUv3 is MIDI, the MIDI is the first place to look to see if it is the cause.
If there is a difference, we can see if setting up a midi filter in SB solves the issue in BM3.
Or, there could be something about the setup in MP and BM3. It is a bit of a head scratcher.
Gotcha!
It is indeed.
Just set up the test. Is it ok to just play 4 notes? That seems to be the only way to stop Streambyter glowing over multiple pages.
You can grow the streambyter window to show more. If playing four notes is enough to trigger the issue then four notes is enough.
For every note played it records 3 events (Note on, note off and pitch-bend), so a fully expanded window only allows 5-6 notes. Will give it a go, and record the results.