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
There are no bad questions... someone else probably also learned something in this otherwise idea thread. Someone else also noticed the thread for the first time since you woke it up.
Heh. We've all been there and some days feel we still are.
Hi, Pretty amateur here too. Seeking for ideas to have different CC messages for BlueBoard pads actions, one for single tap, one for double tap, another one for long tap, in the way you can configure Quantiloop. Any clue would be appreciated. Thanks in advance
It’s not too hard You basically just need to capture the
@SystemTime
when each message comes in (cc or note depending on how the BlueBoard is configured). Pick a threshold time (example 250ms) for deciding what kind of tap it is. Then react based on the timing.For instance, a single tap might be cc 20, value 127 (on) followed by cc 20 value 0 (off) less than 250ms later, followed by no other messages for more than 250ms. A long tap would be cc20 on with no cc20 off within 250ms. A double-tap would be like a single tap, but with another single tap within 250ms.
Once you’ve detected the type of tap, then you send out the appropriate message that your software will understand.
A midi monitor such as MIDISpy (free) is very helpful.
I can do some example code for you if my sleep-deprived explanation above doesn’t make enough sense.
thanks. Make sense, it’s similar approach I have used in Max. Any example code is welcome, of course. Thanks a lot
thanks for mentioning midispy @wim
just what I need for my toolbox!
Actually, now that I'm a little more awake, I realize it's more complex than I originally thought. Timers will be needed as well. Let me know if you get stuck and I'll try to find some time to write a script.
Just a heads up from the sales thread that Koder is free today. @_ki, was that one of the apps you tried for Mozaic syntax highlighting? Would be nice if it could work in that regard, on the iPad with no github/online dependencies.
@bleep Thanks for the reminder, i just downloaded Koder.
I think during my research i couldn‘t find any info about user-defined syntax highlighting, only for a given set of languages.
Now after installing the app, i still can‘t find any info about own syntax files, there is no extra manual or menu for changing the highlighting.
Of course, good point. Mozaic obviously isn´t one of the 80 supported languages, so user-defined syntax is needed, a feature which Textastic has.
Is there a script to map 1 knob to control several CC's on different channels?
Let's say I've got 4 instances of WOW Filter (channels 1-4), and I want to control the cutoff frequency of all of them with 1 knob - is there such a script? I've checked patch storage, but may have missed it.
I think MIDI Morph Pad 2 could be used for that.
For example: You can set the knobs you want to control to their starting values and save that to "Scene 1", then set those knobs to their ending values and save that to scene 2. Now you can use the x-axis of the pad (or the X knob on the page with all the knobs to move all the controls between their end and beginning values.
If you just want all controls to go zero to 127, you can do that, but the really useful thing is you can have different ranges, and even negative ranges, for each knob.
Hey again Mozaic rabbit hole!
I understand that Mozaic doesn’t support the use of string variables but I am running into some situations working on storing values within a controller script, and an adaptation to the SimpleLooper script by H_basilier (Trying to make it multi-track), where it’d be quite useful. Do any of you incredibly clever people have some tips for a workaround?
The main use would be to set which variable array a value should be stored in, determined by a previous input value. Not sure how to say this clearly but...
If string variables were supported I guess I would try something like:
Track = [track1, track2, track3, track4]
Preset = LastPad
Track[preset] = some_value_to_store
So that if LastPad was let’s say 2, “some_value_to_store” would be stored in the variable track3, ideally with the added ability to store it within the track3 array somewhere.
Hope that makes sense and what I’m trying to do is clear, been unsure how to ask about this for weeks...
@ManWhoWouldBeStrings
If the number of values to be stored per track is less than 256, you could store them in a single array using a offset to read/write:
I think Ki's solution is standard and easy to use in most situations where you'd want to emulate two-dimensional arrays in language that has only single dimension arrays. (Note, the problem is not Mozaic's lack of string variables . . . )
I was surprised at how much more unwieldy it becomes in Mozaic if you can't deal with limiting length to (1024 / [number of different arrays you need]). I think the code below would work, but arrays in Mozaic still have max index of 1024, so it doesn't necessarily gain you that much, if you have only four tracks. And it's harder and more verbose to work with.
But if you wanted, say, 16 tracks, then Ki's method limits you to just 64 values per track (1024 / 16). And the method below would still let you record 1024 vals per track. You'd just need to modify the @RecordValue and @RetrieveValue functions (and @OnLoad) below to add more tracks. (Then make sure those procedures are at bottom of script, rarely seen, so they don't clutter your mind.) You could get used to working with it, if you had to.
Little late for the party I guess.. I’ve been using chordulator in some of my tracks and it’s quite useful. So thank you for it! 😄🙏
BTW any thought about pushing Chordulator even further?
I get the stuck notes from time to time but this is not the only piece of code where notes get stuck for me. I get stuck notes in Suggester and in StepBud too. And in other place too. I guess it is just something that happens on the platform?
No, I don't think I'll do more with that script. Its borderline too crowded as it is. As for stuck notes, I may take another look in light of things I've learned since then, but not too likely. I remember the hoops I needed to go through with that, and am not anxious to open it up again. That script is unique in that there are so many parameter changes that, if made live, are a recipe for stuck notes. I had to come up with a system of trying to defer changes to parameters until there were no notes playing. I think I got it about as good as I'm able with the meager programming knowledge I have.
Stuck notes aren't a characteristic of the platform itself, but of individual apps, and sometimes hosts. Some are better than others at reacting to timing and sequence of note-on and note-off messages.
Thank you for the quick reply. I think I understand. I use NanoStudio2 as my main host and it is glitchy with AUv3 Midi FX. I have Cubasis3 but I haven’t tested these apps on it.
Someone may have answered above... when you do a save in AUM, the state of the sliders, knobs etc aren’t saved. Is this by design? Or do you have to save each as a different preset somehow?
They are saved. However, scripts need to be written so that they check whether it's a new initiation of a script or a reload from saved state. If they initialize the controls every time then state saving has no effect. Check page 12 of the manual for a good explanation.
Thanks! Will do!
Yup. I was resetting the knobs. Fixed now and doing what I need. Thx again!
It's tricky to implement and decide which variables to protect from being reset by wrapping them in one of these protecting "if" blocks:
@OnLoad
if Unassigned init
// init does not exist
// so we know we’re running the script for the first time! // we can safely create and initialize all relevant variables here.
testvariable = 0
// and all the rest.
endif
@End
So, the developer has to put all the first run initializations here. Anywhere out side this if block a variable could be reset every time you start it. So, every new variable adding with
code changes needs to start with a protected initialization here. I'm sure many developers forget.
If you change a knob in an AUM session and just close the session you need to consider.
Did you request a save?
I know I've typed in variable changes in the code and run it for a while but forgot to "save" the script or save the AUM project.
But when everything is set up properly and saved in the right sequence it's so good that you can share an AUM project with perfect knob tweaks and when someone installs it and hit "GO" they can immediately hear your perfect creations. It's the easiest way to share
Mozaic scripts... especially multiple instances of the same script with unique settings in each instance.
To check if the developer is helping you look for the "Unassigned" codeword... It can appear anywhere in the code so often moving the code to an editor with find/replace tools is helpful. Then you may have to track down the variable set by a knob and see where it's initialized... in or out of the "if Unassigned" code block?
I now many people do NOT want to look at Mozaic code but there are benefits to some
knowledge when building compositions with Mozaic.
Cool, glad it helped.
On the flip side, you also want to be sure to do an Upload of the code before you save a script. When you save a script, all the variables and control positions are saved into it. So, it's not in it's initial state unless you hit Upload first before saving.
Yep... I've done that a lot too. So sad when you create a fix for a bug and then throw it away as a final step and then upload the old script to patch storage and learn that no one's downloading it anymore anyway. All in a day's work.
For anyone that indulges in PatchStorage I'll mention that my scripts get (almost) all their likes they will ever get in the first 10 downloads or so. I have yet to see any music posted that used one of the scripts.
I can see why developers do love it when a user posts a reply nice demo of the app. They just enjoy hearing what it can do in someone else's hands.
Getting a written "Like" from @Brambos or @FredAntonCorvest is a high point for a creative.
Good scripts are worth simply the process and satisfaction of creating them, whether or not anyone uses them or not.
I do get tremendous pleasure every time a script runs and produces musical FX.
But it would also be great to hear someone else twiddle the knobs.
So, in the spirit of giving the gift I seek I shall make something with the chrodulator or one of t=your excellent apps and share my work and your with the world. That shall give me a purpose today/tonight or maybe tomorrow. Don't wait up.
Different problem:
I have a Xequence2 file with one note per measure. It’s sending output to AUM Destination. Link is on, AUM and X2 both at 120BPM. AUM DEST is sending to the following Mozaic script:
@OnNewBar
log {newbar}
@End
@OnMidiNoteOn
log {midinote on}
@End
I reset AUM transport and ran the above. This is the resulting Log:
newbar
midinote on
newbar
midinote on
newbar
midinote on
newbar
midinote on
newbar
midinote on
Most recent log messages are at the top.
I’m totally surprised that the @OnMIDINoteOn is happening BEFORE the @OnNewBar! It seems logical that a bar begin should happen before the first note in the bar, but not so, apparently.
The MIDI sender doesn’t matter either. I set it up with Riffer as the input with the same results.
My full script needs to know what bar a MIDI note is in so I can suppress the note if it’s outside a range of bars. The above makes that pretty difficult. It APPEARS that Mozaic is handling @OnMIDINoteOn before handling @OnNewBar.
Normally I’d be happy to do a code workaround, but I can’t figure out how to Code to tie a note to its proper measure. Bug?
Thx for any comments...
Well, first check whether the count of measures is correct by setting some variable to zero in the
@OnLoad
. It appears that@OnNewBar
doesn't fire until the first measure is complete. Whether this is a bug or not, I can't say, but it's surely too late to change now as changing it would break any scripts that count based on it.You can use
@OnHostStart
to capture the first bar start:It's important to note also that some events have higher priority than others, so it's possible that logging events could come in an order that you don't expect. Somewhere around here is a post where @_ki laid out the priority hierarchy. I'll try to find it...
BTW, if you put three ` marks on a line by themselves before and after your code, it'll render in a code block. The ` key is kind of hard to find on some keyboard layouts.
```
Some Code...
```
Renders like this: