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
Actually I don't think the Maths is particularly involved but the JavaScript probably makes it look more complex than it is.
You might be right that the Maths is fairly basic but converting that code to Mozaic will
require a gifted programmer well versed in Javascript. This is the type of challenge that
@_Ki knocks off in a couple hours.
@McD Maybe i'll have a look at the javascript code on the weekend - but i have to admit i already started two new Mozaic sideprojects while still not having published my initial side-project for the In-Order ARPs. I tend to daily discover new 'things don't work as intended/expected' cases while testing, forcing me to hold it back until its fixed.
I envy your courage to go public with a beta with known bugs - these were fixed very fast either by yourself or even by community contributions. And now you already are in the 'what crazy thing can i add next phase'. Respect !
Wow, this script is huge. So many possible permutations. The rests work wonderfully.
Keep on your main projects. We can re-visit the idea of Euclidean Rhythms later.
Thanks. I keep adding features and Mozaic keeps up. I'm going to re-arrange the order of the knobs... with Arp related knobs on top and the associated chord knob in the bottom.
They really opened up new territory. I haven't even started to build out the arp and chord tables and it's already got a lot of potential soundscapes just because of the rhythmic variety.
I was able to load Mozaic in NS2 and drive several Obsidian synths playing arp’s and chords using the internal keyboard of NS2. Now I need to try that on my phone and figure out how to record and export the resulting audio.
So, @McD, if you have randomly generated three pages of incomprehensible (to me) comments there must be something to this. I investigated. I buy Mozaic and then can download your work of wizardry? Excuse my ignorance... but then what do I do?? I think you have found your metier... forget that music making and arch commentary.... become the Moses in Mozaic!
Don’t buy it! At least not until I figure out how to use it in Cubasis. Give me a couple days to check it out. I’m testing NS2 first. If you use AUM we can go now.
Just don’t ask me to make a video. That’s yet another application domain in some dark room down the dark hall of secrets.
@McD .... your wish is my command.
I tried out Cubasis and the AUv3 apps are acting weird with the MIDI input.
They seem to be playing in the wrong octaves to the point where the actual melodic content
becomes trashed.
I switched back to adding more features in the code.
I can't recommend this Mosaic script for use in Cubasis until I figure out root causes for
the behavior. NS2 acted more consistently and AUM is a dream.
Would you consider using AUM? If you want to stick with Cubasis, wait a bit longer.
@McD i found a simpler method for generating Euclidean Rhythms and posted a simple patch here:
https://patchstorage.com/joc-euclidean-rhythm/
Mine only outputs a single midi note per beat but feel free to rip out the CalcNotes function if you think it would be useful.
That's great. Don't hold your breathe for me to get to this however.
FYI: I was reading the manual and @Brambos writes this:
I'll use your code to understand better what these rhythmic patterns are like.
The v1.0 of the script i a massive re-organization of the knob layouts and it's really testing
my abilities to maintain a functioning application. I find that creative use of the Logging facility is essential to develop these scripts and insure you don't have flawed logic.
I've got the knobs layed out with Arp related parameters on the top line and the Chord related parameters on the lower line.
Hmm, my code isn't using recursion, just a simple loop. It is based on Bresenham's line drawing algorithm, which makes it sound impressive but really it is quite simple. Based on two variables num_notes and num_pulses it populates an array of size 16 with 1s and 0s. Also num_pulses is used to cut down the size of the array/sequence.
I think a good rule of thumb when learning to code is that you are writing it for other people to read. The fact that it tells a machine how to act is almost an afterthought.
In my Rozeta Rhythm (and Ruismaker) sequencers I'm using Godfried Toussaint's original algorithm for calculating Euclidean patterns:
http://cgm.cs.mcgill.ca/~godfried/publications/banff.pdf
Page 3:
But there are other ways to accomplish the same thing.
At my stage of learning, I get excited by the sounds that are generated.
My version 2.0 will be readable as I look at other well crafted scripts and apply what I learn
about variable naming and commenting to my functioning 1.x version.
I get frustrated with something aspects of the syntax and control:
like the inability to generate any formatting out the output
no facility for inputing text
I wanted to display the 1's and 0's of a 16 element boolean array and it took a lot of
code to log:
==== Arp Mask ====
0010
0001
1011
1101
But seeing that in the logging window really helps dial-in a specific 16 pulse rhythm.
I'm still wondering if there's a way to get it to display:
0010 0001 1011 1101
without having to create a massive if/elseif/endif ladder. 4 digits per line takes a lot of code
without any concept of "strings" or something simple like an optional "no carriage return" on a Log statement.
Nice
But at least half of the 'professional' programmers I work with shy away from recursion.
Also the absense of scope in Mozaic would mean that the developer has to maintain their own stack of inputs and ouputs, or do you have another way?
Yeah.. I second the notion of staying away from recursion. If it can be avoided, do so for your own sanity.
@McD ... will wait. You got a good thread going. You are in your element!
Thanks for your patience. It Cubasis ran without any issues I'd encourage you to
join as a knob tweaker. At some point I'll be asking you to send me some block chord
MIDI recordings I can use for structures to encode into the Chord Table of my script.
But first I need to make it stable and clean up the GUI. Then figure out what synths work well with it in Cubasis.
Best i could come up with:
The cursor control is hateful on iOS. You wouldn’t believe how long that line with all the str[] access took!
@Jocphone That's nearly what i would have come up with.
Instead of using the Pow function (internally quite computing intensive) several times in the loop, i would set up a mask variable that get shifted in the loop. If the str array is filled with 0's with a fast FillArray, one only needs to add the 1's. I have also added spaces every 4 bits:
@McD Outputs
ArpMask = 0110 1110 1100 0001
in the Log window(PS: edited variable name style to use _ as first letter for local variables which are only used inside a single event)
Log str[0], str[1], str[2], str[3],{ },str[4], str[5], str[6],str[7],{ },str[8],str[9], str[10], str[11], { },str[12], str[13],str[14], str[15]
Thanks guys! I was close to these excellent approaches.
It just didn't occur to me to output "white space" by wrapping it in { }'s.
My approach outputs all combinations from 0000 to 1111 as {0000} to {1111}.
I'm still glad I found a solution to display my Logical Masks before reading the right answer.
I will take away from this advice with a much better understanding of how to make better, readable and more efficient Mozaic scripts (or "tiles" since Mozaic's are made from small "tiles").
Hi @McD , I like your idea of combining an arpeggiator and a chordulator in your mcOrchestrator script! But before you go on implementing new functionallity, I hope you will investigate your code as it is now and make the script more 'robust' and reliable, because there are bugs and a maybe-bug:
The bugs:
The maybe-bug:
There seems to be no relationship between the arpeggiator and the chordulator... I have to dial the Arp- and Chordknob to the same value and only then the result sounds 'consonant'; is this by design? And why start the Arp on OnMetroPulse instead of on OnMidiInput?
Small tip:
Your very long MyLabelPPQNKnob and MyLabelPulsesKnob-procedures could be much shorter! Like this:
MyLabelPPQN
LabelKnob PPQNKnob, {PPQN=}, PPQN // values 0 - 24
End
MyLabelPulsesKnob
LabelKnob PulsesKnob, {Pulses=}, Pulses // values 0 - 24
End
Thank you.
Thanks. That is a great list of recommendations for improving the code quality. I know I dropped a buggy, poorly designed script on PatchStorage before it's a quality design and implementation. If you've heard my musical postings on the Forum you'll recognize my
total lack of attention to "production values". I'm a hack and I know it.
But making scripts do anything is fun and sharing them for comment is, in my opinion,
the best way to learn from your mistakes. I have benefitted from the early efforts and I will now turn my attention to making what I have limping along perform better and with more predictable results.
To me this biggest problem with Mosaic is the small community of users. The only solution is
to attract more users (of all types) and encourage adoption of this amazingly powerful app.
Writing scripts is challenging and the only way to get more beginner's to attempt it is to
encourage their efforts to try. And continue to assist them in their learning process as @wim, @_ki, @alfred and you are doing for me.
I have uploaded v1.beta of the script.
All 22 knobs have functions now:
Top Row impact the Arp functionality (Channel 1)
Bottom Rom impacts the Chord Functionality (Channel 2)
There’s still work needed on Knob Labeling but the Logging functionality displays the Arp and Chord Rhythm Masks. Populating these masks with the Euclidean Rhythm Masks seems easy with the example code provided. But I'll target the Labeling first and other
quality improvements.
@McD Nice The wrong labels are a bit distracting, but if one opens up the Log view, one can see what each knob really changes.
.
An easy way to get rid of the multiple log output lines (or multiple computations) when turning a knob is to just compute the new value into a temporary variable and compare that to the old value. Only call the log output (or heavy computation) when something changed. This 'trick' only works for 'integer' knobs, as 'float' values tend to always differ in some bits. (To compare floats, you need to calculate the difference and check if that's smaller than a tiny epsilon - then there equal)
Applied to your code i mean:
changed into :
I agree. But I get good input by sharing incremental changes. This was a really big one for me.
Nice. I've had some versions that broke the Logging function with excess output. At some point
I'm going to study the MIDI streams out to really understand how everything works. The last version of
the script kept changing the Preset selected in iSymphonic which I assumed would require a PC Command and I'm not sending any.
Lots of knobs that are fun to play with... Version 1.2.