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
After you you have updated the script to solve the problem of the knobs not being restored when changing pads.
Well, have we not solved this problem?
This is the same script that has been solved .
This was the script I was working on from the beginning, without problem.
Before we get started. It looks like knob 5, is the only value that changes with lastPad. Is that what you intend?
What is supposed to happen with knob 6?
Related: you initialized an array called swing, but never use it. Is that intentional?
Sorry for late.
This script has not been updated. I have already mentioned this script, for example, with a knob, but now it is complete and works correctly and completely.
If you want I can send it to you ( updated script).
The issue is completely resolved for me. Would you like me to discuss the next issue with you?
Yes. But you'll have to post the current fixed script. The last version of the script that you posted had a number of issues worth your while to look at. That is why I suggest you post your current version.
Or is there a particular problem in it that you want us to troubleshoot?
No, there is no problem in terms of knobs being saved in the pads
I would suggest posting the current version then and reviewing.
Updated script.
@pejman : the first thing for you to look at is your onLoad handler.
I recommend that you go through it line by line and simulate what it does. I see two immediate things for you to look at. There is a for loop that runs 10 times.
Trace that out by hand with your finger line by line to see what gets executed...and include any loop iterations.
As you simulate the loop, ask yourself for each line: does this need to be executed all 10 times the loop runs?
Yes, you are right, I have not yet cleaned some lines and put them in onload. These lines need sorting
I would look at all for loops in your program and see if they are needed.
Do you mean that I should correct them now?
It is up to you. Something for you to think about.
Maybe you can do it on your own and ask questions if you get stuck.
What do you think is the problem, which ( for ) is extra ? I checked them, but removing any of them gives us trouble
I'd like to see if I can get you to find the problems. There are a few. There is one general logic issue and then there is an efficiency issue. If you have looked at it and don't see the issues, let me see if i can ask some questions that will help you to see them.
Start with the for in the onLoad clause.
Trace it through with your finger, every line that gets executed and loop through it. Keep track (you will probably need paper and pencil) and write down the variable changes.
After you have done that as an exercise, put a log line in the "if unassigned" block that prints out the value of knob. Something like
log {testing if block. knob =}, knob
Put a log line on the line after the "endif" that prints out p. Something like
log {after endif. knob = }, knob
What do you notice?
A question to answer: why is the "if unassigned" block inside a loop that gets called for every knob.
after endif. knob = 9
after endif. knob = 8
after endif. knob = 7
after endif. knob = 6
after endif. knob = 5
after endif. knob = 4
after endif. knob = 3
after endif. knob = 2
after endif. knob = 1
after endif. knob = 0
testing if block. knob =0
As it is known, inside if assigned, knobs are not recognized, but they are recognized outside of it
I have to say that there is no logical reason why I did this, because by changing the state or moving the ( for ) outside of if assigned, the script continues to work correctly.
And the latest changes in AUV3 mode are well read and restored after loading.
Hi again, I'm going to raise a new issue . Of course, this issue has been raised before and is half finished. About save color pad in track pads . This script was sent to me by Wim, which I adjusted and made to send CC in the way I wanted. So I have modified this script and disabled some lines.
And I have changed some things.
This patch has 4 tracks ( knobs 0 to3 yellow ) and each track has 12 patterns ( knobs 4 to 15 pink),
In trackpads and patterns, by touching each pad, only that pad becomes colored.
Problem ,
1, touch pad num 0 ( track1 ) Its color turns yellow.
2, And touch pad num 6 ( pattern6 ) Its color turns pink.
3, touch pad num 1 and touch pad num 8
4, return to pad num 0 problem issue
I expect pad num 8 become colorless and pad num 6 become pink.
Thank you if you help me.
@pejman :
what happens in steps 3 & 4?
Where do you expect the color to be assigned?
Put a log line immediately before each call to colorpad that identifies where in the code you are and prints the pad number and what color will be assigned
perform the steps you described and see what the log says. Does it match what you expected?
If you put the log lines in, it should reveal what is going on.
3, touch pad num 1 and touch pad num 8
( Pad num 1 turns yellow , and pad num 8 turns pink , correctly. )
4, return to pad num 0 problem issue
I expect pad num 8 become colorless and pad num 6 become pink. ( which was painted pink in step 1 ).
But this does not happen in practice.
@pejman : you did not answer the question:
where in your code (be specific), do you expect the colors to be assigned when you perform step 4.
Before posting with the answer, do the logging I describe.
In order to find and solve problems like this, you need to be able identify where in your code an interaction is handled and how to check if your code is doing what you expect,
Can you please tell me what exactly I should put in front of the word log ?
There is nothing to put before the word log.
What you need to do is add log commands that display the information that I mentioned (and possibly additional information).
When you add the log lines, make sure to include something that will identify where in the script it is located.
For example,
log {onPadDown. on entry. lastPad is: }, lastPad, { , padRevert is: }
or
log {onPadDown. lastPad between 0 and 3.}.....the rest of the information to log
Use the log lines to peek into the execution to make sure that what is happening is what you expect to happen.
You also need to know what SHOULD happen.
From what you describe, there is somewhere in your code where something you expect to happen isn't -- or something you don't expect to happen is.
I did what you told me about the log, that is, the results I see are correct, but I don't understand where the problem is.
the issue is very confusing for me, I would be grateful if you could give me a clearer guide.
One question: Should we create the line codes in @load layer to make the pad colorless?
Because I think, according to my wish, something like this should happen somewhere and be saved ( copy Array )
Please post the script with the log lines and screenshots showing the log output created when you perform the steps that demonstrate the problem.
```
@Description
Example for @pejman: See @OnPadDown for how to use SendMidiCC in response to touching pads.
This example demonstrates how to clean up the code a little by moving the CC sending out
to a separate event.
@End
@OnLoad
value_a = [1,3,5,7,9,2,4,6,8,0,33]
value_b = [2,4,6,8,10,12,14,16,18,20,22]
value_c = [3,5,7,9,11,13,15,17,19,21,23]
value_d = [23,33,44,55,66,77,88,99,13,35,37]
color_a = [7]
color_b = [7]
color_c = [7]
color_d = [7]
/// new in ver 4 padrevert and colorpad = 0 and 4 insted of = LastPad
padrevert = 0
color_a = 4
ColorPad 0, 2
ColorPad 4, 7
Call @InitializeLayers
layer = 1
Call @LoadLayer
Call @SetPads
delay = 2
ShowLayout 2
@End
@OnPadDown
// When we tap one of the first four pads, recall the layer associated with it
pad = LastPad
//Log cc[pad]
log {onPadDown. on entry. lastPad is: }, lastPad, { , padRevert is: },padrevert,{ color_a }, color_a
if LastPad < 4
ColorPad padrevert,0
ColorPad LastPad,2
padrevert = LastPad
elseif LastPad > 3
if pad < 4
layer = pad+1
Call @LoadLayer
Call @SetPads
elseif pad > 3
Call @SendLayer
endif
log {onPadDown. on end. lastPad is: }, lastPad, { , padRevert is: },padrevert,{ color_a }, color_a
@End
@SendLayer
// Loop through the pads, sending cc # and value combinations stored for the layer.
// We get the CC# from what we set in the cc array. The last touched pad, stored in "pad"
// in @OnPadDown event, tells which CC to use.
//for idx = 0 to 11
SendMIDICC 0, cc[layer-1], active_value[pad-4], delay
// I like to set a small delay between midi messages in case hosts have trouble
// processing too many messages at once.
//endfor
@End
@InitializeLayers
log {on initlayer. on entry. lastPad is: }, lastPad, { , padRevert is: },padrevert,{ color_a }, color_a
// This could be any code you want. We'll just load random values here.
//va= [1,3,5,7,9,2,4,6,8,0,33]
for idx = 0 to 11
//layer01_value[idx] = v //Random 1,127
//layer02_value[idx] = Random 1,127
//layer03_value[idx] = Random 1,127
//layer04_value[idx] = Random 1,127
endfor
// I added some CC #s to use for this example
cc = [20, 21, 22, 23]
log {on initlayer. on end. lastPad is: }, lastPad, { , padRevert is: },padrevert,{ color_a }, color_a
@End
@LoadLayer
// This is where we copy a selected layer to the active value set
// The "layer" value must be set before calling this event
// (There are more elegant ways of doing this, but they require more explanation so
// we'll keep it simple here.)
log {on loadlayer. on entry. lastPad is: }, lastPad, { , padRevert is: },padrevert,{ color_a }, color_a
if layer = 1
CopyArray value_a, active_value
CopyArray padrevert, active_color
CopyArray color_a, active_color
elseif layer = 2
CopyArray value_b, active_value
CopyArray color_b, active_color
elseif layer = 3
CopyArray value_c, active_value
CopyArray color_c, active_color
elseif layer = 4
CopyArray value_d, active_value
CopyArray color_d, active_color
endif
log {on loadlayer. on end. lastPad is: }, lastPad, { , padRevert is: },padrevert,{ color_a }, color_a
@End
@SetPads
log {on setpad. on entry. lastPad is: }, lastPad, { , padRevert is: },padrevert,{ color_a }, color_a
LabelPad 0,{1️⃣}
LabelPad 1,{2️⃣}
LabelPad 2,{3️⃣}
LabelPad 3,{4️⃣}
// use the active_value and active_color arrays to set up the pads
for p = 4 to 15
LabelPad p, {Value: }, active_value[p-4]
ColorPad p, active_color[p-4]
endfor
log {on setpad. on end. lastPad is: }, lastPad, { , padRevert is: },padrevert,{ color_a }, color_a
@End
@espiegel123 ,
As you know, in the load layer and setpad section, pads 4 and later are not reported.
As you know, in the load layer and setpad section, pads 4 and later are not reported.
@pejman : please answer the question that I posed earlier: “ where in your code (be specific), do you expect the colors to be assigned when you perform step 4.”
And one more question: when you touch the pads in step 4, what log lines would we see if the script was behaving correctly?
I think in @setpad in ( ColorPad p, active_color[p-4] ) .
Discoloration of the previously colored pad number in previously track and showing the number of the pad that is colored when selecting a new track