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.
Help me with action conditionals in LP!
Hey!
I'd love your input on a thing: I’m in the middle of building a new 'conditionals' system for Loopy Pro. This means you’ll be able to set up your actions (from a foot pedal, an on-screen button, a MIDI trigger, whatever) so they only run if certain conditions are met.
So instead of just firing off a series of actions blindly, you can have them behave differently depending on the state of your session.
For example:
• Only run if the clock is playing
• Only if a particular group of clips is empty
• Only when an audio source is muted
• Only if a clip is recording, or stopped, or reversed
• Only if the tempo is set to a particular value
• Only if a send is above zero, or an effect parameter is above a threshold
It's gonna be incredibly powerful.
There are so many possibilities, but I know I won’t be able to think of them all on my own.
I’d love for you to have a think about your own projects and how you might want to use conditionals. What situations would be helpful for you? What conditions would make your workflow smoother, smarter, or more fun?
Do chime in here share your ideas, if you have some!
Cheers!
Michael
Comments
first - thanks for all your hard work in making awesome software (now back to our feature presentation)
CONDITIONALS - allow a text label, conditionally, to take or be set to the values of step(s) in a stepdial. PLEASE, PLEASE, PLEASE..... so I nudge through the steps in a stepdial, and as I go or select each step, the value of the text label changes to the name of the step. So if my stepdial has these 4 steps: Sleepy, Grumpy, Silly, Dopy.... then as I nudge through these, the text label (optionally can be set) displays or has the value Sleepy, Grumpy, Silly, Dopy.
WHY? RATIONALE - Stepdials are real estate hogs. Absolutely necessary and powerful widgets in LP, but they take up way, way, way too much real estate on the screen. This feature - allows me to (a) move stepdials to another page - rather than my main page and then (b) see what step I am selecting as a nudge through or select each step - via a text label..and (c) make the font of the text label big WITHOUT taking up too much real estate. In fact, the screen real estate issue with stepdials is twofold; not only do they take up too much space because they're square even though they look round - in edit mode you can see the square bounding box; but ALSO - if you want to make the font label for a stepdial large you must make the stepdial even larger on the screen. This is a total waste of screen space. Yes for sure stepdials are a crucial widget in LP, but they take up way, way, way too much of my precious screen space on an iPad or iPhone.
This CONDITIONAL feature will revolutionize LP, and make it screen-friendly and easy.
IF - I get to bar or measure 48 - THEN........ (any action I want that already is available)
You may have to create "markers" - to use in the expression you're evaluating; example - IF marker A = 48 THEN.....(any action)
While I appreciate and understand the power that conditionals will bring to the software...... my gut feel is that there are still a large number of feature requests that would actually BETTER SERVER the user community. IMHO.
One that comes to mind is GROUP FOLDERS for audio buses, for color groups, for MIDI channels - like other DAWs have (and have had for years). E.g. - I want to put all my MIDI Drum Channels in a folder called 'DRUMS', or I want to put all my audio bus channels used for my string section in a folder called 'STRINGS', etc..... and then with that - the ability to collapse and expand GROUP FOLDERs. Give users the power to organize the various channels how they see fit. In fact..... along with this..... the ability to drag and move channels around as well would be better than conditionals. These are functionality other DAWs have had for years and years.
Another that comes to mind is GROUP FADERS - which again most DAWs already have. This functionality lets you create a fader that groups which channels the user selects and then control the faders of all of those channels in the group with ONE FADER, and do it or control them in THE SAME RATIO the individual faders are set at. So if I make a group fader to control channels A and B, and the fader for channel A is set to 2x the level that the fader for channel B is set at; as I move the group fader up or down - I get the same ratio
Even improved or cleaned up consistency in the UI would be helpful over conditionals. I think of the list of actions for a widget - well you can't even read the full name of the action because the screen is too narrow L to R. Or the list of MIDI bindings - where there's no functionality to put or add comments. Knowing that PC 8 on Channel 4 triggers the SELECT action on Stepdial Lead Fx .... means absolutely nothing to me several months after I set it up. Or the project management screens - there is sooOOOoo much room for UI improvements that would benefit especially new users - and would be of greater benefit than conditionals IMHO.
Again - thanks for great software!!
1) If ... AND ..., then do/don't execute XYZ. Else do/don't execute ABC.
2) If ... OR ..., then do/don't execute XYZ. Else do/don't execute ABC.
3) When a Loopy Pro internal or plugin parameter reaches a specific value ("18.5 Hz" for example), then do/don't execute XYZ.
4) When a Loopy Pro internal or parameter reaches a specific range of values ("18.5 kHz" to "20.0 kHz" for example), then do/don't execute XYZ.
Examples:
5) When overdub number X of a specific clip is reached, then do/don't execute XYZ.
Example:
6) When cycle X of an overdub of a specific clip is reached, then do/don't execute XYZ.
Examples:
7) As soon as the last remaining clip of a specific colour(s) has been deleted/playing/is recording, then do/don't execute XYZ.
Example:
8) As soon ramping value X of (choose one or several sources here – ideally with exclude source function) has been reached, then do/don't execute XYZ.
9) If ..., then activate/deactivate all actions / follow actions of a specific clip/widget.
10) If ..., then activate/deactivate all actions / follow actions (category "press" only) of a specific clip/widget.
11) If ..., then activate/deactivate specific actions / follow actions of a specific clip/widget.
12) If ... AND/OR ... while stay on page x, then do/don't execute XYZ.
13) If ... AND/OR ... while plugin window x is open, then do/don't execute XYZ.
14) If plugin window X is open, close all other plugin windows.
15) If button X is on, toggle following buttons.
15) If button X is on, switch off following buttons.
16) If clip X is exact 4 bars long, then do/don't execute XYZ.
17) If clip X is 4 bars and longer, then do/don't execute XYZ.
18) If clock is under 160 BPM, then do/don't execute XYZ.
19) If ..., then change the title text of button widget to ... (forever).
Example:
20) If ..., then change the title text of button widget to ... (temporary for x seconds / x beats/bars; and immediately afterwards show the previous text).
21) If a specific clip is empty, following widgets should grey out
22) When I change the colour of a specific clip, the following widgets are given the same colour as the clip.
My first thought is, conditionals will have to multiply and multiply, making Loopy even more intimidating than it already is for many people. I don't think this is the right way to go about this. I think you're headed for a huge mess, though I would love to be proven wrong.
Instead, I think we need all purpose variables, especially doubles or floats, counters / integers, and booleans, but also strings if possible. You already have some of these under the hood in the widget feedback system. So, rather than having something like
IF clock is running AND group 1 is empty THEN ...or we'd have have follow actions to get or set variables on everything we already have follow actions for.Then we just need something like
IF foo is True AND bar is False THEN ...where foo and bar could have been set by any actions we want. Increment, decrement, and (possibly) math functions would be needed as well.I believe you will get tangled up in a huge mess trying to anticipate and make UI pickers for everything people are going to think of as needing conditional behavior. Instead, it seems to me like you could just set and retrieve variables during any existing action, and apply conditional logic to any action based on those variables.
If you can swing String type variables as well, that would nail the other labeling requests that come up all the time. Ideally strings could be constructed with variable place holders as well, such as
Group 1 has played %g1counter% times.I think using variables would also greatly simplify troubleshooting problems with conditionals. We already experience all the time the complexity of helping people troubleshoot where follow actions and settings overrides are causing unexpected behavior. Just think how deep it's going to get with conditionals lurking around everywhere.
Now think about a popup window that shows variable values in realtime as they change. Clicking on a variable could list all the places it's used. Clicking on those places could open up the follow action menu where the variable is set and is used. Debug logging could be possible...
Conditionals in a great many cases will be much simpler than the combinations of follow actions and dials/radio buttons currently necessary to accomplish a number of desirable workflows that are currently daunting or impossible to implement.
I asked ChatGPT:
Here’s a detailed, structured list of possible conditionals you could propose for Loopy Pro:
⸻
Clip State Conditionals
• If Clip is Empty → then…
• If Clip is Recording → then…
• If Clip is Playing → then…
• If Clip is Stopped → then…
• If Clip has X layers (overdub count) → then…
• If Clip length > N bars → then…
Transport/Clock Conditionals
• If Clock is Running → then…
• If Clock is Stopped → then…
• If Downbeat reached → then…
• If Tempo > / < threshold → then…
Group/Scene Conditionals
• If any Clip in Group is Playing → then…
• If all Clips in Group are Stopped → then…
• If Scene has been launched → then…
Input/Output Conditionals
• If Audio Input detected above threshold → then…
• If MIDI Note/CC received → then…
• If Specific Controller Profile is active → then…
• If CPU load exceeds X% (safety) → then…
User Interaction Conditionals
• If Button is held (long press) → then…
• If Double Tap detected → then…
• If Widget Value > threshold → then…
Timeline/Sequencer Conditionals
• If Playhead reaches marker → then…
• If Sequence ends → then…
• If Loop Count = N → then…
Special/Advanced Conditionals
• If Clip A starts → then stop Clip B
• If Overdub finishes → then enable FX
• If No Active Clips → then stop clock
• If Clip X volume < threshold → then mute Group Y
• If MIDI Program Change received = 10 → then Load Project Z
Thanks for the feedback, and kind words. This isn’t an arbitrary indulgence on my part; I need this for an important side project. Just so happens the LP community will benefit from it as well and I wish to make the most of that.
It would be nice if the enabled state of the four input types (hardware, auv3, etc…) could be a condition.
Loop counters (with display, maybe in the center of the loop?). Conditionally switch to a group based on a counter.
A “switch” rather than a large if/else if/else may be cleaner?
How feasible is it for a little AI assistant inside Loopy Pro to help out with this, so you just literally type in what you want into a conditionals prompt, and then Loopy Pro creates the conditional from the massive list of variables in its library? I think this would help solve the sprawling list problem that @wim mentioned.
I gave an idea for a a quick implementation of conditionals a while ago, adding a simple condition action that can be used in widgets to break the flow of instructions early : https://roadmap.loopypro.com/feature-requests/p/conditional-guard-early-exit-for-action-lists
It is widget based though, and will probably be limiting in terms of the conditions that can be expressed, but I find it the best tradeoff in terms of usability, and it is generic enough that you don't need to build conditions for each smaller context.
The difficulty will be in getting a simple enough syntax for conditions, otherwise it will quickly evolve into a complete mess of UI-designed complex selections where simple coding would be really easier. The Shortcuts app is exactly to example of a bad design for this kind of work, as it is a chore to get even a simple script running and is difficult to handle even if you're proficient at coding loops and conditions.
The other thing to consider is if there will be a context of variables assigned to the conditions, or if they will be solely based on static concepts that are used in the actions already. Both ways are viable in my opinion. The first one would require an additional action that would set a variable, just like you store parameters at the moment.
So to sum it up, this is how I'd view the whole system :
1 - Purely concept base conditions
Condition action : (concept) (concept value) (operator) (value)
Each parameter is a closed list.
Examples of concepts : Audio Input, Audio Effect, Clip, Color, Group, Widget
Examples of concept values : input A, plugin B, clip 23, Magenta, Group A, combo
Examples of operators (depends on the concept) : is, is not, is greather than, is lower than, is in (list of selected values)
Examples of values (depends on the concept) : numerical values, enabled/disabled, playing/stopped, active/inactive (widget feedback)...
This is already very powerful, but adding variables can make the conditions much more complex as you can store a given state and recall it any time
2 - Variable bases conditions
Store variable action : store (concept) (concept value) to (variable)
Variable is variable1 to variableN, depending on the number of slots are opened for assigning values.
Action condition : (variable) (operator) (value)
It is less straightforward to set up simple conditions, so probably having the first action as default would be better, otherwise you'd need to allocate a variable everytime you need even a simple condition (like 'inputA is enabled').
A last thing to consider is having a clear text of the condition when you browse through the widget actions, without having to enter a complete menu just to show what is does once it is set up.
Well that's it for my contribution on the subject !
I know it might not be in the scope of the functionality, but maybe having widget state feedback, title, and color attached to conditions would really help bringing out more out of it and push Loopy Pro to another level in terms of customized experience when playing live.
Create a show/hide action (like other UI builders support)
IF....(condition)..... show/hide a widget on the UI
C'mon..... we need to free up more real estate on our main screen /page!!!
Widgets are your variables there. You’ll be able to set widget state from follow actions or gestures/MIDI, see its state visually on screen, and then conditionals can reference those widgets
Nice. That sounds good.
Something about me doesn't like taking up screen real-estate for such things, but of course, they can be on a separate page.
And I’ll add the ability to hide pages soon.
I think I prefer that over adding yet another new construct like variables.
Yay for page hiding!
Nice!
You are right, that is better. You'll get the script kiddies like me whining a bit, but that's fine. 😎
So then ... why a discrete list of conditionals? Might there be a way to add IF / AND / OR logic on all actions as an extension of the timing options (After Last, With Last, Next Trigger, Timing)? Just a thought.
I agree that variables would probably add another layer of complexity and not be very user-friendly. Something that I'd like to see though is a way to store the state of the playing clips, because you can't reliably stop clips / do something / start again with the current options. The conditionals could reflect this state "was playing when stored" instead of "is playing" which is not always what we need.
If there are cases where play state is not currently being remembered, please provide us specifics (preferably on the slack) so that we can address them.
Very excited about this!
There is some good stuff on this list, sometimes chatgpt is actually nice.
Although, it forgot about control profile conditionals !
This would be a very powerful addition (and I can’t wait to see how you do it), but acknowledge it is at the risk of adding complexity for some users. My thinking would be how can conditionals simplify both the building of templates and the simplification of screen display. I would certainly love to see some new actions to complement conditionals, one being conditional widget colours (e.g to reflect the screen mode based on activating a different Control Profile. ). Of course loops already do this automatically for recording/overdub. Conditional text values has already been mentioned, and is similar in that it can assist template designers in keeping the screen as minimal as possible for the user.
Just food for thought….
Hi. I would especially use this related to presets if you select certain preset you could activate or deactivate certain effects.
Of course otherway around and could build preset dependencies and connections and groups.. just thinking loudly.. being currently quite busy, I didn't read if it's already mentioned in here?
Conditionals won’t make anything that exists more complicated. People can ignore them. Most people will probably not use them directly. But it will enable people designing templates to create very useful workflows that aren’t currently possible or are only possible with a lot of complicated chaining of dials and other widgets, follow actions and streambyter or Mozaic.
It will allow us and other template creators to create some powerful ready-to-go loopers.
Please don’t take my comments about complexity as negative. I am super excited about the possibilities here. I am just noting that from a fundamental architecture perspective ADDING is always at the risk of adding complexity which needs to be considered carefully by the designer. I am actually suggesting there is a great opportunity with conditionals to help reduce complexity. From my experience with LP so far, I certainly trust Michael will look after us all 😎