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
I’m trying to light up pads in Mosaic that correspond to the switches on my floor pedal (visually speaking), but unfortunately, the CC values are going down as the pad numbers are going up. So if I press the lower left switch which sends out CC11, that matches up with the lower left pad in Mosaic, which in my case is pad #8. Then the next switch sends out cc10 for pad #9, cc9 for pad 10 and so on… this works but not very efficient:
@OnMidiCC
@END
Here are all the relationships:
CC11 = Pad 8
CC10 = Pad 9
CC9 = Pad 10
CC8 = Pad 11
CC7 = Pad 0
CC6 = Pad1
CC5 = Pad2
Is there a more efficient and prettier way to write this? Or do I need to match the CC numbers to the pads in order to do that? Meaning CC8 would match with Pad 8 etc? Thank you!
@ztones, as written, the code will always turn off all pads except the one matched. Is that what you want?
Yes! I only want the one to light up that I am triggering.
It's not terribly inefficient then. You could make it look a little nicer at the expense of some more abstract code, but imo it's not really worth the tradeoff in simplicity and readability. Other's may disagree with me.
Good point! Just curious, what if the cc matched the pad number? Something like, if cc# is 8, light up pad number 8?
I can also use the pad parameters AUM's plug-in/node settings, where I can individually choose which pads get activated with which cc, but it's only a momentary light up, doesn't stay on, which is what I'd like. Another potential problem with that is that my pedal only sends a value of 64 for each switch. So even if light stays on, how to turn it off?
Wouldn't make enough difference to bother with. We're talking a nano-second or two at best.
Here's a little more abstract way to do it, if you're really bothered by those if statements.
I don't feel it's particularly worth it, but maybe there are some concepts to think about in the example:
I suppose it's a more flexible and lower maintenance solution though. If you change CC numbers or the pads you want to light up you only need to modify the array in the OnLoad event rather than comb through a bunch of if statements buried in the code.
Thank you @wim for coming through again!
So the script works for about half the buttons. I wish I understood the code better so I could troubleshoot it. Believe me, I tried! LOL
So as I mentioned, the CC#'s are not always the same calculation away from the pad #. IF I'm reading the code right, it is taking CC# -1 to identify the pad???? But I know there is more to it, because it IS and it ISN'T behaving that way. Those buttons are lighting up but so are others at the same time in some cases. Perhaps I should have mentioned that I am using layout 2 (with the 16 pads) in Mosaic. The pad numbers I am referring to here are 0-15 (in reality 1-16).
Here is what's happening now:
CC11 = nothing
CC10 = Pad 9 (correct)
CC9 = Pad 8 & 10
CC8 = Pad11 & 7
CC7 = Pad0 & 6
CC6 = Pad1 (correct)
CC5 = Pad2 (correct)
What I'd like to happen:
CC11 = Pad 8
CC10 = Pad 9
CC9 = Pad 10
CC8 = Pad 11
CC7 = Pad 0
CC6 = Pad1
CC5 = Pad2
So on one hand seems like a consistent mathematical correlation between the CC's and the Pad#'s would be much easier (so they are always the same CC & Pad# or consistently -1 or +1 apart for example), but some of the buttons DO work so I'm confused... LOL
-1 in a position means the CC should not fire a pad. The idea is if the CC # is matched to a position in the array that has a pad number, it should light up that pad.
I knew I should have tested that before I posted 😬. I'll figure out what I did wrong later today and get back to you. It's probably just that I have the numbers wrong in the array but maybe my distractions at the time caused me to not think it through all the way.
A mathematical relationship between the CC's and the pads shouldn't be necessary. I'll take a look at it later today.
I see! So the order in that list of the pad numbers as they match the CC#'s in increasing order is the trick! That order looks correct. It was just ironic that all the ones that are working correctly, happened to be -1 from the CC number. I'll play around with it a little bit too but I'm pretty sure something else is going on too because sometimes two light up.
Hey @ztones, sorry! I totally forgot about this until just now.
Um. I set up a test and except for forgetting
ShowLayout 2in the@OnLoadevent, the script works just fine for me with the CC numbers you listed.Are you sure about what your footswitch is putting out? The behavior you're describing makes me think some other midi message such as Bank Select / Program Change (PC) is being sent rather than CC. Can you send the output to a midi monitor such as mfxMonitor or MIDISpy, then press the buttons in order and post a screenshot of the output? One of these two would be better than ShowMIDI as I need to see a log of the messages.
(Only press as many switches as the monitor can display the output from without scrolling. If that's less than all the switches, that's fine, just let me know which switches you pushed.)
Show midi can now be set to never timeout
I’m embarrassed to admit some of my old left over code for latching on/off was still in the script! Can I get a HUGE Homer Simpson DOOOOH!? I thought I had deleted it all, but I had a copy I was working off of and that still had left overs…. Anyways, yes, it does work fine now! Thank you!
Now my only question regarding this, is there a way to keep on the “light” that is currently on? Meaning, I have 3 copies of this script that I switch in between where the function of the expression pedal is different and the remaining pads do different things. So one of the foot switches toggles between the 3 scripts in Mosaic. Each script is saved as a preset and get loaded accordingly. The main 8 switches that are involved in THIS script stay the same (in all 3 scripts) and when I switch between the scripts, I would like to keep the “light” on for the pad that was last active in the script that I switched away from. Currently (by design) when the new script is loaded, all pads get turned off. Is there a way to keep the one on that was already on? Thank you!
Note to @wim : Maybe instead of unlatching all pads, change the code to only unlatch the ones with „non -1“ entry in the ccPadNum array ? That should be 0,1,2, 8,9,10,11 as specified in CC to pad mapping description.
Perhaps one can build an additonal „inverse“ array specifying which pad is used by the remapping from the ccPadNum array ?
I considered doing that but favored simplicity over efficiency in the example given there was already new concepts the OP would have to absorb to understand it.
Which is great, but that doesn't give a timeline view. The order of events is more useful in this case.
That possibility occurred to me in the shower this morning. 😂
We've all made that mistake at one time or another.
I’m honored that you were thinking about my code in the shower! 😂😂
Generally speaking, no. When a new preset loads it has no knowledge of what happened before it.
You might be able to do something using Mozaic's "global" variables. These are special variables that are shared between all running instances. Each script would need to check these variables and act on them to light the pads in its
@OnLoadevent. They would also need to update those variables.I'm not sure that will work though, it's designed for already running scripts to share data. It would have to be tested whether they'd be accessible across a preset change.
Global variables are described in the manual.
The worlds best place to sort out one's thoughts.
That makes sense. Although I’m already surprised that I can send a midi command from a script and it comes back into its own node to execute. What I mean is, all 3 scripts that are being called upon are in the same Mosaic instance and node. I am able to send a message to change presets in the same node that the current script is in and it works! So the outgoing midi is listened for and being treated as incoming midi, even though it’s not a “midi in” for that node/plugin. Surprised me!!! But its nice not needing more instances of Mosaic.
If I understand what you're doing correctly, you're not sending the preset load midi to Mozaic. You're sending it to AUM's midi control and AUM is handling the preset loading.
I'm curious about whether Global variables can be used to pass information on between presets. I'm going to do a test in a little bit here.
Yes, I should have been more clear. I am sending it to AUM’s midi control. But still, it is sending midi out from the node and coming back into the same node. Maybe that’s normal, but it surprised me as it doesn’t fit my traditional “input-output” understanding.
No, it's not coming back into the node unless you've specifically set it to route back to itself. I'm not sure how to explain that better to you.
Can you show us the AUM routing?
@ztones, OK, I did a quick test using a global variable for the pad. It does preserve the pad state between preset loads. But there's a slight downside to be aware of. Normally I'd expect all pads to be unlit when you enter a new AUM session. But the last lit pad is going to be saved in the preset.
If you want all pads unlit when starting an AUM session you will want to manually load the raw script so that it's in its initialized state.
I'm sure there are ways this could be gotten around, but I'm trying to keep the introductory example as simple as possible to help with understanding how it works on a basic level.
So the midi “loop” seems to be coming from the built-in Midi Control. Mosaic 4:2 is where the script in question lives.
What we're trying to get across is there is no MIDI loopback. There's no MIDI involved in AUM's communication with Mozaic. Mozaic is sending MIDI to AUM's MIDI control system. AUM then carries out those automation tasks through a different mechanism that doesn't involve MIDI communication.
It is possible to loop MIDI back into Mozaic by routing it from itself to itself. Generally you would never do that though. If you try it you'll see that AUM represents the feedback loop with dotted lines.
(There are cases where loop-back makes sense, but it has to be handled very carefully to avoid things going out of control, and also involves adding a slight delay since the midi has to go out in one buffer and come back in another.)
True, the midi isn’t going back into mosaic, so it is not a midi loop back. From the perspective of midi going from one node in AUM and coming back into the same node (to change the preset) seemed like a loop, but it does stop there. Doesn’t continue to “loop”. Anyways, I didn’t understand how or why that was happening but after disconnecting the built in midi controller, it stopped working so now I get what was happening.