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
By all means put them in one script
@ManWhoWouldBeStrings
That will be easy realy.
If you have nice functionality usefull for other applications then maybe it would be nice to make separate modules.
About the code:
I would test for
If midicommand = 0x90, instead of if midibyte1 = 144.
But there is a big change you will receive another noteOn with velocity 0, wich is a noteOff.
So this is weaponing you against noteOffs retriggering your script:
If midiCommand = 0x90 and midiByte3 > 0
If midiByte 2 = sendTrigger
Elseif midiByte2 = myOtherTrigger
Endif
Endif
For me it’s all about what plays out as the most easily understandable, and therefore manageable solution. I’m more comfortable with code that I feel I understand and that I don’t get lost in the complexity of. Everyone has their own tolerance for that. Mine is about 10% of what the real pros around here can handle.
On the other hand, I would rather have one plugin that can do five things I want rather than five plugins cluttering up a setup, as long as I still feel like the plugin code is manageable for me.
It really doesn’t matter. Even if they’re all loaded into a single channel, they’re not “chained” unless you set the routing up that way. I’d usually rather have all of them in a single channel so that I don’t have to do as much scrolling.
On the other hand, it’s sometimes nice to have the instance that’s controlling something next to what it’s controlling. That can help with remembering what controls what, and can also reduce scrolling when you’re focused on one app.
So basically ... it really depends on what is most clear for you in both cases. It shouldn’t have any effect on performance or anything else.
I didn't test the code, just tried to figure out what you presented and then refactored it. Maybe i have just missed that feature. Adding an if
loopy[_idx] … endifinside the recall should fix that.Your
repeat … untilloop seems ok. If the number of iterations is fixed, i prefer to useforloops, as these are not only 2 lines shorter (no init or inc statement) by also indicates that the looped statements never influence the end-condition and therefore will always terminate. A 'while' type loop should be used if use-case includes that the looped-statements are never executed , a 'repeat' type loop should be used if the use-case includes that the looped statements are at least executed one. Both 'while' and 'repeat' loops are prone to the endless loop error (just forget to increment) .Yeah that's a good idea, needs less code and is less error prone.
.
As the others already commented - It depends. I normally try to 'offer a well-rounded package', a script that covers all use-cases i can think of, but does not suffer from feature bloat and is still easy to use.
.
I combine them in one AUM midi channel since this results in less scrolling. There is no disadvantage in doing so if the mozaic scripts use SetShortName and therefore have different icon names. My CopyCat script even allows to adapt the icon name with a knob since it is a regular use-case to have several of them.
You can safely test for NoteOff messages. Mozaic will catch any NoteOn messages with a velocity of 0 and pass them on to you as a NoteOff message for your convenience. No need to design for this yourself.
I have made a note of this behavior in the "Receiving MIDI in Mozaic" chapter in the manual, so you can assume that Mozaic will always offer this behavior.
Yup, my bad. Did not realize this was inside a onNoteOn handler. The testing for midiByte1 = 144 threw me off.
In that case to make the code more clear, you are essentially testing: if midiChannel = 0
hello,
in the mozaic manual i cannot find info how to setup and use a timer...
can you please direct me to some example code?
thank you
Check out the example in Chapter 5 about using LFOs. It shows how to use a timer to get LFO values at set intervals.
ok, thanks. got it
so there is only one timer possible per instance?
@Alfred said:
Yeah you’re totally right about that. Still learning all the commands...
In the end I’m now using OnPads (bound to trigger notes in AUM) to trigger the reset and recall so don’t need to test for any note input on any channel anymore anyways for that case. But thanks for the clarification. Also the clarification of how/when to use the different loop commands was very helpful @_ki. I was confused about that. But I think I’ve got this one nailed down now!
And thanks @wim and @_ki too for the input on multiple instances of Mozaic or just one, and where to put them. I think in the end I’ll try for one instance to just do a bunch of basic conversions (note/cc transposing, note to program change/cc and vice versa, etc.) and a second instance with the various manipulations of those messages for controlling Loopy. All in one channel in AUM to simplify scrolling.
found a way to crash Mozaic this morning @brambos. Seems a long array initialization will crash the instance like this
@OnLoad
MACHINES = [1, 2, 3, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28,32, 33, 34, 35, 36, 37, 38, 39,48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,64, 65, 66, 67, 68, 69, 70, 71, 72]
@End
@_Ki slipped me a clue about really long arrays:
MACHINES [0] = [1, 2, 3, 16, 17, 18, 19, 20, 21, 22]
MACHINES [10] = [23,24,25,26, 27,28,32,33,34,35]
MACHINES [20] = [36,37,38,39,48,49,50,51,52,53]
MACHINES [30] = [54,55,56,57,58,59,60,61,62,63]
MACHINES [40] = [64,65,66,67,68,69,70,71,72]
Maybe that will be a workaround? I tried to insert some HEX in the middle and that is a no-no.
@McD Hex constants should work where ever constants are allowed. In Mozaic these start with the prefix 0x :
TEST[0x20] = [0,1, 0x42, 4]
Looking into it! Thanks!
@brambos In addition to the "large array on load" crash, I've also experienced difficulty in storing and recalling five digit pitch bend values in a large array. I could experiment to figure out exactly what causes it; I just worked past it by storing a separate value for the ten thousands and thousands places. If I could load an array with 127 numbers, 5 digits each, on load, that would be convenient for making the code for my microtonal script a little bit nicer to read.
@Skyblazer I believe the max values in the arrays go from -64 * 127 to 64 * 127.
So deducting 64 * 127 from your values would make them fit in one instead of two values.
Also no pitchbend will be 0, so much easier to read :-)
@brambos thanks! I have another one for you although this one might be user error. I would expect the following to emit a random number from 0 to 1 but it seems to ignore the parameters when they are enclosed in parenthesis.
@OnLoad
log random(0, 1)
@End
That should be
Log (Random 0, 1)The entire function call should be enclosed in parentheses, not just the parameters.
Ugh.. thanks. I keep forgetting that part of the syntax when i leave mozaic for a few months and come back.. thanks!
Thanks for the info, and that's a good idea. The topmost range of the pitch bend value won't be used, after all. The default bend value is 8192, "(64 * 127) + 64", so I'll subtract that from the total to make the default bend value 0.
Hi @McD
I have been looking at your developments.
I think Bill Evans was right about the joy of finding things out by yourself.
I am a little concerned about the notes though, so here are some tips.
You can split the onmidiInput into onmidinoteOn and onMidiNoteOff.
You can store up to 16 notes for any input note in the noteState array.
You can use the noteState array to release the right notes on noteOff.
You can use onTimer and a counter to walk through the 16 notes in the noteState array.
I think the long delay some notes get at the moment is not a sure method.
This depends heavily on the midi buffer of the host.
Using the onTimer method does not overload the buffer with future notes...
First get the releasing of the notes working. Then you might try to also play the notes from the onTimer script. This way the added delays will be minimal.
You will have to track multiple notes, so it will get a bit more complicated. But you will figure it out, once you build the release routine.
Thanks for your input. I'll use this as a list to work from as I go from v1.x to a 2.x version. I'm learning new things by (unintentionally) starting and putting out small fires in my script. My ability to process text on IOS has been the main takeaway.
Thank God (or @_Ki) for Textastic and it's search/replace functionality. I'll bet there are a lot more text processing aids I have stumble on yet. I really miss my "vi editing" habits for using regex map statements. Is there a good "Vi Editor" app for IOS? Hmm... (Seems like there might be one that's FREE with IAP's).
Yes carefully chosen variable names make your script self explaining. Regular expressions are above my paygrade though. Ki is the master in that field. My experience with coding comes from HyperCard and Director.
This guy has a nice perspective on coding:
@McD Textastic supports regex in search and replace - but i didn't try it out yet
@Alfred Using the note state array to store the scheduled notes is a nice idea, but i assume that one could just use a normal array with a stride of entries offset by 16 for several input notes instead. That would result in 64 parallel active input notes with 16 arped / strumed / iterated chord notes each - which should be enough. Using the note state array offers 128 x 16 notes.
What I'm craving is an editor that supports the Vi "escape" sequences for moving the cursor
{return}
rapidly around the code without having to touch the screen or grab the mouse. Jumping to instances of a given variable I can type: :/ChordVolume{return} and continue using
I downloaded iVim but the font size is too small. I'll keep re-programming my brain to use Textastic unless someone proposes a useful "Vi" alternative for iPad editing. Can I add a font to iVim that's larger?
Just published my In-Order ARP script on patchstorage.
Brilliant execution of some great ideas. I love your application of the SHIFT button.
You are the King of Mozaic Tiles, IMHO and the Emperor of StreamByting.
You asked if there would be any interest in you creating Mozaic Coding Videos and
I vote "YES". The potential audience will only get larger with more of these amazing tools.
Hopefully, more musicians will decide to try to invent their own automatic MIDI generators and utilities.
Thanks for the flowers, a less big bouquet would have done it too
There are several excellent Moazic script programmers, from which i also learn and adapt.
.
I already tried that with one of the next script ideas - but i totall disliked the result. I didn't image that i produce so many errors during scripting and tap stuff in the wrong order during testing. Over and over even though i have a clear idea what i wanted to do instead. And i learned that when talking during programming, i start swearing when bugs happen
If i just code quietly i never had the tendency to curse myself, i just fix the many bugs i make.
I'm sure you know who's the real deal and who's a wanna be hacker.
Your best use of time is writing more scripts.
Mozaic is a brilliant Midi scripting system - thanks so much, @brambos!
Two quibbles with the editor (which maybe comes as stock functionality from Apple and thus not fixable - though perhaps could be 'externalized' as an option):