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
No worries and glad it works, that’s the thing I was saying, I can’t see how you’re checking the state of the settings, it looks like one set is on pad down, the other on pad up - I guess this just somehow works correctly/in the manner you intend?
I have absolutely no idea about any of what you just said. hahaha. These are literally the first scripts I've ever done, and most of it was copy/paste and trial/error. I'm sure someone could rewrite these a lot more compact and with colors working, but I don't know how.
Pads are white when the padstate is 1. You change the pad state with LatchPad.
Where would that go in the following code?
@OnPadDown
If LastPad = 0
SendMIDICC 3, 51, 127
Endif
@end
@OnPadUp
If LastPad = 0
SendMIDICC 3, 51, 0
Endif
@end
Also, I'm trying to simplify the overall codes using the "for i" with the default pad CC setup @onload. However, I can't figure out how to get the sendmidicc to send on the right CC channel. Is there more to it than I am thinking?
@OnPadDown
for i = 0 to 15
If LastPad = i
SendMIDICC 3, i, 127
Endif
@end
@OnPadUp
for i = 0 to 15
If LastPad = i
SendMIDICC 3, i, 0
Endif
@end
Thanks!
Can you indicate where you want the pads to be white? I generally find it super helpful when writing code to use comments to indicate what I want to happen so that I can go back later and fill in the code that will do that. It also helps others understand exactly what you want to achieve.
Certainly! Basically, I want to toggle red to white. So the pads start white. When I press them to turn on RECORD, they turn red. When I press them again to turn off RECORD, they go back to white.
I am still unclear. Can you repost your code and put comments in the code where you want the various color and pad state changes.
I also don't understand the for loops in your onPadUp and onPadDown routings. That code tests every pad when there is a pad up. You don't need to test them, unless I am overlooking something obvious (lack of caffeine).
Can you write a pseudocode (plain English) description of what you are trying to do. Those for loops with the embedded if are essentially just the same as
onpaddown
sendmidi 3,lastPad,0
end
I can try. Again, I just kind of cobbled this together via trial and error and copying/pasting from other codes. My coding experience is basically nil, and I don't know how much time I'll be able to put into learning to deep. I just thought it'd be a fun and easy way to make a few controllers for this Gauss looper thing before I eventually splurge on MDP2 or something.
Basically, when I press down on a pad the first time, I want it to turn red and send out a MIDI CC to trigger the record function on Gauss. Then when I press the pad again to turn off record (sending the same MIDI CC trigger), I want it to go back to white. This way, one can see which loopers out of the 8 are recording.
If this is all a bit to much, it's not a big deal. It all works in terms of controls as I intended, this is more just for visual feedback to make it easier. Thanks!
When you say "white" do you mean non-latched, color 0 (unlit)? It seems like maybe @espiegel123 is assuming "white" means "latched" (bright white).
Sorry for butting in if that isn't the case.
Ah. yeah. I guess I mean unlit. Thanks!
I hope you won't mind my walking you through a process that I think will help you in all your coding -- it is something I do myself -- and was the best lesson I received in coding in my intro to programming class (that was taught by an awesome grad student).
So, tell me if this pseudocode is correct. If it isn't write an updated version to correct me.
onload
initialize recordState array to 0 // this array will keep track of the record state for each Gauss instance
//recordState is an array from 0 to 8 that tracks whether that gauss instance is recording or not
end_onoad
onpadDown
check RecordState for the pad that was pressed
if gauss wasn't recording,
start it recording
set the color to red
update RecordState to 1
else (gauss was recording)
stop gauss from recording
set the color to white
update RecordState to 0
endif
end_paddown
Well, syntactically you are correct. ColorPad , 0 = white. Latched is a different state and command, not really a Mozaic color. I just thought I'd step in to avoid confusion down the road.
(Sidenote to @brambos: I always thought it would be nice if Latched retained the color, just a brighter flavor of it.)
Man, if you're trying to avoid confusion, you're talkin' to the wrong hombre! Haha.
This seems correct to me. I assume it's safe to assume that when you have "if gauss wasn't recording" doesn't mean mozaic will know Gauss' state, but I will know based on my button presses?
Yes. My approach to a script like this is -- if all the interactions of interest are handled by the script and Gauss starts out in the same state as the script then i will assume that Gauss' state matches what I think the state is based on my interactions.
I can chime in on this again later and provide some code if you haven't worked it out by the time I am able to get back to it
@slicetwo Sorry I didn’t get more involved this afternoon, I saw that others had dropped in with more helpful stuff, and was tied up with calls at work - that latchpad command is definitely more appropriate in this circumstance - I was switching between more states so needed different colours... I’m looking forward to seeing what emerges!
Thanks for all the advice! I'll try and get at it soon, but I don't know how soon! Haha.
@Krupa No worries at all!
My request is coming from a midi-guitar perspective. Each string on the guitar transmits on it's own midi channel. This Mosiac patch called Midi Filter and Transposer, ( https://patchstorage.com/midi-filter-and-transpose ) transposes globally on all channels. I need it to transpose each string individually so I can set up alternate tunings of the guitar. is there anyone here who is able to modify this and still leave the filter function intact? Ideally it would have plus or minus 12 steps for each string.
@erol I just saw that you also commented on the PatchStorage page of the script, it seems that PS doesn’t send emails to inform the script‘s author that something was commented... grmpf
From the midi event‘s side it‘s quite easy to implement transposition per channel, but i have to figure out a way on how the UI should behave, how to setup the indivial versus the global transpose etc and how not to complicate usage for users wanting a script ‚emulating AUMs input filter’
Maybe it‘s easier to just do a new script just for this purpose, but lets first just ask some more questions about your midi guitar use-case in regards to the old script:
Cool idea!
To me, the filter and transpose is for bass.
Hi!! I`m requesting something that I thought existed in mozaic... but not!
I
d like to get a "divisi" script, Im copying the description from the other Thread where I was asking for the script:_“auto divisi “ midi notes. I.e. for 4 channels the incoming chord will be spread between 4 different MIDI channels just like the poly to n-channel scripts, but in this case, with one midi note input it will send the same note to the 4 output channels simultaneously , with 2 notes input will send one note to 2 channels and the other note to the other two output channels and so on... _
And in response after trying the usual supects (polythemusAU,...):
_ what I look for is bit different because if you select 4 notes (4 midi channels, 4 different synths or sounds) all 4 will be playing always regardles of the number of input notes... I you play one note then the 4 synths will play in unison... If 2 notes, then two play one note in unison and the other two the other note in unison. If you play 3 notes then one synth for one voice, other synth for the other voice and two other synths in unison for the third voice, if > you play four, then will be as the "usual" voice allocation.
This is really usefull for playing lot of styles, but a good example will be a string quartet played from the keyboard.
Coulbe an add-on for the current scripts (if don´t have the option, still need to try it at home!) as these kontakt script: https://vi-control.net/community/threads/multi-script-tools-free-divisi-scripts.59985/ _
Maybe could be possible to modify one of the current polyphonic voice allocation scripts?? poly it up,...
Thanks!!!
@Synthi I‘m already prototyping such a script... But the logic behind it is a lot more complicated than first expected.
First of all - the input midi need to be stored and analyzed for a short amout of time since midi events are delivered in sequence and there is no ‚this was the last event to process in the current timeframe‘ marker in Mozaic.
And the script needs to react not only the initial chord or notes, but some notes might be sustained while others can play a melody, so the configuration will change dynamically. And duing my tests with an initial implementation i noticed that a naive aproach will run into problems with notes played in legato.
This happens for instane when sliding on the finger on the AUM keyboard - the note-off of a previous active note is received after the new note-on. This legato play can not only happen for monophonic lines but also for chords you ‚slide‘ on the keyboard. The naive approch would first re-allocate new addition notes due to the early note-on‘s, using less channels per note - and then stop playing the previous notes. Instead it‘s better to reaint the intial configuration and ‚slide‘ all the mono instances - so no change in the configuration. BTW: to detect legato, the midi input events also needs to be stored for a short amount of time.
For a test setup i used 4 Audio Modeling brass instruments placed in the stereo field. Since i used different instruments, each has kind of a prefered note range where it sounds best. So i changed the note deployment strategy to also sort the notes, so that lower notes will use lower channels. When reallocating channels during the note playing while other notes are still sustained (melody in the top or bass note, or legato of parts of chord) this note order can not allways be archieved, since it is not feasable to move sustaned notes to a different channel (this would trigger their attack phase). But i wrote down (didn‘t implement yet) a distribution strategy that tries to keep them sorted in some way.
Or that CCs and pitchbend etc need special treatments. And if this works with the concept developed, its not that far to also wish for MPE input device support where only channel 1 needs extra treatment (since the CCs and PBs on that channel need to be send to all of the other channels). To keep note on‘s / off‘s / CCs etc in the original sequence, they also need to be captured during the analysis time - otherwise they might not land on the channel they are supposed for.
.
Development will take further time, as i haven‘t figured out solutions to all the problems i encountered during testing my inital simple prototype - but have ideas for nearly all them
.
Sorry, i have no timeframe when the divisi script is finished - my normal work doesn‘t leave me much time to script as there are several big milestones approaching rapidly.
.
I don‘t mind if someone else will come up with a simple straight forward divisi script, but i suspect that not all of the aspects i mentioned (melody play with sustained notes, legato play of single or multiple notes, CCs, ATs, pitchbend, multi-channel midi input or even MPE input) above can be done with a simple script.
This is exactly why I didn't take this on. It is the old problem of trying to detect a "chord" when not all notes are guaranteed to arrive or end at the same time. Best of luck. If anyone can manage it, I expect it is you.
@Synthi and @wim : And this time it‘s not over when a chord is detected - the re-configuration needed when releasing just some of the notes and then adding new ones is a quirky optimization problem.
Realising a script for the several initial chord configurations was easy (as i had experience with Smart Chord Bass), but as soon as you then start adding, removing notes, sliding the AUM keys (or used one of the multi channel keyboards) more and more secondary conditions for computing a new redistribution became apparent that need to be observed.
.
Lengthy discussion of redistribution for multi-divisi script hidden with spoiler
My algorithm distributes channels the channels arrording to pitch of notes.
Single notes are output to all 4 channels: ie NNNN
For a two note chord and a lower note L and higher note H you get the configuration LLHH which plays the lower note on the two lower channels 1+2 and the higher note on channels 3+4.
BTW, i formulated most of the optimization steps not only for 4 output channels, but try to find solutions for N channels.
A three note chord with additional middle note M will result in the initial configuration LMMH, two channels for the middle note since that allows better redistribution.
A 4 note chord with note N between middle and highest note, results in the intial configuration LMNH.
But the real funs starts afterwards:
Adding a third note to a two note LLHH config can result in three configurations, depending on the pitch of the new note N in regards to the existing notes.
Adding a foruth note N to the initial 3 channel config LMMH is simple. Free one of the largest group MM, depending on the pitch of . This will result in either LNMH if N is lower than M or LMNH if its higher.
If afterwards notes are released, but at least one note of the chord is still active, channel(s) resulting in empty slots. You don‘t want to start one of the sustained notes in these channels when a note was released, as you would get an undesired note attack played at the ending of another note.
If afterwards a new note is added, and no empty slot are available, you‘ll need to find the best fitting channel from one of the groups with multiple output channels. If empty slots are available, one can use these to balance the configuration again - but you‘ll notice that you can‘t garantee the note sorting any more. It might happen, that only the lowest channel is empty, but you‘ll received a note higher than all the active ones.
As long as one of the notes is active, the current redistribution needs to be adapted to note additions and removals. And the more complicated the distribution problems can get while playing melodies, adding and removing notes etc.
If finally no note is active, one can start the next ‚chord config‘ detection on the next note-on.
If one implements Legato detection the redistribution problem get easier - all legato notes can reuse the allocated channels. So if you slide a two note chord config LLHH, the updated notes will contain a lower and a higher notes - so, just use the old LL channels for the new lowest note and the old HH channels for the new higest note. This also works if sliding three notes of a four note chord. One ‚just‘ needs to detect the allowed complex note-on/off combinations That‘s one of the things i already solved - even for MPE or mutlichannel input intermixed with CCs and PBs etc
If not detecting legato (where note-off comes after the note-on), you would need to release two of the channels for the new notes XY, maybe arriving at LXHY depending on the pitch relation. And then L and H receive their note-off and you are left with -X-Y where only two single channels are playing for a two note config instead of the better LLHH with legat detection.
.
With 6 outputs the intial configs are LLLLLL, LLLHHH, LLMMHH, LLMNHH (depends) etc - many of the problems encountered with the 4 output config will result in easier solutions (if still mostly 3 or 4 chords are played as initial config) as there are more possibilities to replace channels. For the effect it‘s that yo just need to setup more sound playing AUV3 resulting in an even bigger brass band playing divisi style.
In any case, it can be summarised that it will probably not be possible to realise it through a 'simple extension' of an existing script. Except if you only allow the intial configuration and ignore all note-on activity afterwards until all the notes are released - which would heavily restrict the possible note input and playing possibilites.
.
The requested task is quite interesting, as it allows you to take a chord/melody sequence (played by piano roll or even live) and turn it into a fat brass arrangement where low notes tend to be played by tubas/trombones, higher notes tend to be played by trumpet etc, and single or two-note combinations are played by all available instruments resulting in a maximised fat sound. And the redistribution is deterministic, so a new identical playout will result in the same instrument combinations playing.
For real divis brass or string arrangements, a conductor will probably decide using rules i am not aware of, or it may depend on the piepe played.
Using a script will never ever be as good as a manual divisi distribution ! But hey, its working with live input and maybe even with per note MPE expressions distributed to the corresponding output instrument(s)
Thanks a lot @_ki !
I`m sorry I can´t help in the development, I wish I can understand an think in programming those letters and numbers at least as good as I make music!!
I think you toke in account a lot of variables that was out of my initial thought as the legato and reallocation of channels, and all those make sense for a very owerful auto divisi script.
I don´t know the similarities between the kontakt and mozaic scripts but maybe taking a look at the programming of the kontakt script here: https://vi-control.net/community/threads/multi-script-tools-free-divisi-scripts.59985/ could bring some ideas on the implementation.
You guys are genious!!
I have a script request.
Wish I had time to build this myself but I'm currently crazy busy. Not to mention it's been a full year since I last programed anything in Mozaic.
The script is for automating pattern play in Loopbud.
I included a graphic below of what I have in mind.
The purpose of the script is to simply send CC pattern change messages to Loopbud according to adjustments made by the user using the Mozaic knob layout.
Mozaic will step through the layout knobs from left to right, and use the knob setting as script control parameters.
The upper knobs tell the script which pattern to change to. The lower knobs tell the script how many bars to wait before moving on to sending the next pattern change message.
There's a knob for tuning the script output on and off, and another knob for telling the script to either stop at the end of the pattern chain, or loop back and play the chain again, synced with host time.
I believe using multiple "same" cc pattern changes during recording may influence how Loopbud records. I noticed some "weirdness" while recording using StepBud to send multiple "same" pattern change messages.
Recommend only sending only one cc pattern change message at the beginning of the first bar at each pattern change.
Thanks.
@wim - a big shoutout re: Basic Midi Controls. I was really looking for an easy program change module and this is perfect for that and more. Thank you!
Thanks for the kind words. Yeh, that one is one of the few scripts I've written that I actually use.
I’m really hoping there is a way to use Mozaic to generate random patches for Mononoke. Got the app recently and love it just wish there were more patches to explore. Most Bram apps have a random button, and it seems like at least to me, after a few days of having Mononoke it’s a perfect candidate for a random patch button. Not the tunings, the actual synth, preferably two randoms, one for left and one for right, so if you have something you like on one side, you could randomly generate until you have something you like on other side. I know the actual synth knobs aren’t too complicated and dialing in something isn’t to tricky even for a novice sound designer like me, but I would absolutely love if Mononoke had a patch randomization button. It would add a lot of value to the droning possibilities imo. I know there is that “spectrum randomization” script, and another one, but can they be applied to Mononoke or can one be created relatively easily for Mononoke?
The only mosaic script I’ve ever coded was a simple midi velocity echo, so I’m very limited in that regard. I’m hoping someone is interested or can help me make this script. Especially if it’s possible To do two randomizers, in one Mozaic script one for the Left synth in Mononoke and one for the right synth in Mononoke, then you can save the patches you like in the actual app.
On a broader note, It would be beyond cool if it’s possible to write a script that does this on a larger scale, sure some synths have some nice patch Rando features but it be cool if there was a way to use a Mozaic script that could create random presets on any synth that has midi in, and midi parameters exposed. I understand the mapping may change from synth to synth, so maybe some type of framework and the user could add the midi mapping in the code, so it could be used with a several different synths. I’m just spitballing here but it would be amazing if there was a way to have a Mozaic script that could do Patch randomization on various synths, after you make sure all parameters were mapped correctly. Or maybe a way to randomize every single cc so it would catch everything in a synth and randomize all knobs...? Is that possible?
There’s no way to build a script that would intelligently seek out what can be randomized in synths. Some have published CC’s, some have midi learn only, and some have no cc control at all, but do have AU parameter control.
The most direct approach would be to simply use AU parameter automation and map CC’s to those parameters, to be driven by one or more scripts with randomization capability. MIDI Randomizer and Scenes could do this for you. You’d have to set up the AU parameter mappings for each synth though.
I don’t see how a script with a “framework” like you mention helps much. I mean, I could see something where that makes it easy to change the CC numbers and maybe some labels in the code, then provides a randomization button, but ... you’d still be stuck needing to figure out all the cc’s or map them to AU parameters.
No magic bullets here. There’s just not that much in the way of inter-app intelligence available to any scripting language.
@Poppadocrock said:
I know there is that “spectrum randomization” script, and another one, but can they be applied to Mononoke or can one be created relatively easily for Mononoke?
I have been able to change the spectrum randomizer script and randomize ripplemaker’s parameters. I don’t have Mononoke so I can’t be sure if the same logic can be applied.