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.
Send different Midi-CC commands with the same dial wheel.
Is it possible to use the same dial wheel to send different Midi-CC commands?
**For example: **
When button number 1 is activated, Midi-CC command 50 will be sent as a midi message. When button number 2 is activated, the same Dial wheel will send Midi-CC command 60. The value sent will still be variable as before.
Comments
No. You would need to use something like mfxConvert for that. You would set up two conversions, saving them as presets, then have the buttons load the preset needed.
@espiegel123 may come along to prove me wrong with some stepped dial trickery I don't understand, but that's the simplest and most understandable way I know of.
Conditional logic will come some day I'm sure, but for now simple if/then logic is convoluted (imo) to implement when it's even possible.
Thank you @wim!
Maybe I should have a look at StreamByter for this task 👀 I only have to figure out how I can store local variables.
Streambyter would be fine, requiring just two presets of one line of code each, or a more complicated script that receives midi from the buttons and changes the conversion based on the received midi.
Honestly though, mfxConvert is simpler IMO, and involves no coding. For only $2.99 US it's well worth having. (btw, mfxConvert is simply a front-end for a subset of Streambyter code capability)
One method is using control profiles, streambyter or ShowMIDI as a proxy/middleman between your widgets and the midi control system.
For each destination, you set up a control profile that has bindings from streambyter to the destination. And you have a dial to switch between profiles.
Let’s say you have a fader. Have it send cc0 (or whatever) to streambyter.
For each destination, set up a profile that binds cc0 from streambyter to send midi message set up to send whatever midi message you want.
You can even use this method to change what buttons and dials do in loopy pro. The bindings don’t have to be to midi messages.
Jeez. Good one. For some reason I've only ever thought of control profiles in relation to external hardware. I still think mfxConvert is a less complicated and lower maintenance solution, but thanks for expanding my thinking!
What DAW do you use? I’m wondering if the MIDI Control capabilities of AUM might be a solution.
Of course, a programmable MIDI App would solve this in short order:
Mozaic (the expensive choice but the easiest to read programming tool):
There maybe be an error in my recall of Mozaic command syntax but easy to fix since the Mozaic editor shows you
that right number of arguments for these commands.
@McD : fwiw, in the solution I suggested, no programming needs be done in streambyter. It is just being used for midi-thru
@McD - the question is about Loopy Pro.
Interesting… now I need to research what a streambyter profile is… it sounds like graphical programming in a similar sense to
mfxConvert being a graphical way to program behaviors. Not code, but configuration through some menus.
Still, I wish a Streambyter code expert would share the 5-10 lines needed to solve this one. It’s so basic.
Not a Streambyter profile, a Loopy Pro profile. Loopy profiles are used to switch the context so that controller messages, etc, can act in different ways.
Not really. Streambyter coding is very simple and compact for single conversions. Once you get into conditional logic you need a deeper knowledge of a number of Streambyter concepts.
Thank you so much for your engagement @wim, @espiegel123 and @McD.
I will briefly describe:
1. why I want this + and I have a question about
2. a somewhat confusing situation handling in Loopy Pro ...
1) What and why ...
I use ZOOM LiveTrak L6 connected to iPad Pro.
On the LiveTrak, I have 9 buttons that can be selected (Level, Pan, Efx, Aux, EQ, etc.).
When I press the selected function, I can use the rotary knob to adjust the desired value for each of the channels (1-6).
In other words - each rotary knob has a different function depending on which function button I have selected.
For each function button, the rotary knob will also change which midi-CC code is sent.
This (among other things) I want to control from Loopy Pro. In Loopy Pro,
I have solved this by having each function button send a midi-CC code with the corresponding value to StreamByter (AU-plugin).
StreamByter stores the selected value using Loopy Pro Midi Source Actions (Adjust MIDI AU Parameter - e.g. Q0, Q2, Q3, etc.).
In StreamByter, I then filter this out to send the desired midi CC code with the corresponding value to the ZOOM LiveTrak L6.
An example of a filter code could be:
if Q0 == 49
snd B0 49 M2
end IF
if Q0 == 53
snd B0 53 M2
end IF
This actually works as desired - BUT ...
2) a somewhat confusing situation handling in Loopy Pro.
I don't know if this has anything to do with 'State Feedback' in Loopy Pro, but the problem occurs whether I use Radio-Grid (as in the attached video example) - or Stepped-Dial.
In the attached video example, I have removed ALL unnecessary elements and only included Streambyter and three buttons in Radio-Grid.
As you can see in the video, I first select the buttons from left to right - this works - and the correct example code is sent out from StreamByter.
BUT when I change the pressing from right to left, it gets messy.
It seems that only some codes go through. Why?
Does it have something to do with the setting of 'State Feedback'? (I have tested a little differently here, but then it gets even more confusing: some codes are sent correctly, but it is random which button lights up as active).
I have read the WIKI, but I can't find any plausible explanation for this confusing handling in Loopy Pro.
Suggestions for solutions are received with great thanks!
Can you post the whole Streambyter script and also screenshots of your action settings on the radio buttons.
Or, better yet, just export the Loopy Pro project, zip it, and attach it here?
@OlaRos : as wim said, it would be great if you zip and upload the project. Without seeing it, I hesitate to speculate.
Of course!
The attached Loopy Pro project is exactly the same as the one shown in the previous video.
Interesting. Loopy does seem to be setting the value from the previously tapped button in some cases. I'll try with a different plugin to see if it is something with Streambyter or with Loopy working with Streambyter.
I tried setting a delay on the actions, but that doesn't help.
It seems that repeating the button presses a second time (tap 127, tap 64 [fail], tap 127, tap 64 [success]).
Mozaic is responding to the parameter changes as it should. It's likely this is a Streambyter issue.
I believe you are running into a Streambyter bug with regards to how Streambyter updates the host with respect to parameter changes (including those initiated by the host) . I don’t recall all the details but I ran into this some years ago and I switched to using midi for communication with streambyter when Michael explained it.
fwiw, I set up a test in Drambo and the parameter changes are triggering fine there. There's no AU Parameter feedback in my testing though. Dependence on the feedback is probably where the gotcha is in Loopy.
Observability with MID behaviors is so important.
Use the Log feature (the magnifying glass button) of Streambyter
to see all the MIDI events associated with the knob turns and the button presses.
There are a lot of MIDI monitoring apps but streambyter is free and you’re already placing it in the critical path.
@OlaRos @wim
Try putting ramp on the assignment. When I set a 30ms ramp it started working.
I thought about doing that, but rejected the idea because of potential issues from intermediate values. Not with this script, but potentially with others. For instance, it plays havoc with my simple Mozaic test script's logging.
It does work here for this test case though.
Which is why I use midi to communicate with streambyter as that has proven reliable whereas AUv3 parameter changes from Loopy have not been reliable. I’ll see if Michael can look into it again.
I wish I could think of another host with which I could test feedback from Streambyter's AU parameters because it does seem to be related to feedback and Loopy's dependence on it for widgets. I'm seeing that in testing OSC as well.
@wim : I just did a quick test on Drambo that I think reveals the source of the issue.
Add streambyter to a Drambo project. With the SB window open, tap map and choose Q0 to expose QO as a knob. Leave map mode. If you move the Q0 fader in Streambyter, you will see that the knob in Drambo doesn’t get updated. SB updates Q0 if if the Drambo knob moves. But changes in SB don’t get sent back to the host. Loopy Pro relies on AU’s keeping the values updated.
If you do the same experiment with Mozaic, you see that it works in both directions.
I don’t recall why, but Michael explained when I first ran into this that working around it had potential pitfalls.
You are correct. However, it could be argued that relying on feedback from the AUv3 in a case like this isn't a good design choice. If the action is to set a parameter then it should simply do that, as it does in other hosts ... especially when feedback is disabled on the widget.
The counter argument is that workarounds shouldn't be made for ill behaving plugins. That doesn't quite do it for me. I feel like it's fair to not have widget feedback work in that case, but not parameter setting.
@wim: if I recall correctly the ramifications aren’t just for widget feedback not working correctly.
Bottom line. If it works in other DAWs, perhaps it should be considered as a Loopy Pro problem to address. Given that I can set the parameters properly in other DAWs, I'd put it in that category personally, but ymmv of course.
I did, @espiegel123 - and it worked.
The question is, can I trust StreamByter - or is it that Loopy Pro has a challenge? Or both of them?
Streambyter is very stable. It just has the issue of not providing feedback of its AU parameters properly to the host. Loopy Pro is stable. It just doesn't like this particular issue with Streambyter.
You might want to consider using MIDI to communicate with Streambyter instead of messing with the AU parameters, as @espiegel123 suggested. Or, use Mozaic instead.
Thanks so much for all the contributions!
Yes, messing with the AU parameters seems to be problematic in this context.
I have tested some scripts in Mozaic - which look very promising. Now looking for the possibility of storing arrays in Mozaic. If it is possible ...