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
What's a low ceiling for some, is a nigh unattainable ceiling for others. And I reckon it's almost impossible to create a tool that is accessible and instantly-gratifying to absolute beginners and deep enough for people with years of low-level coding experience.
For advanced users XCode offers multiple other languages (instead of a script). Mozaic was made as a quick and relatively easy solution for exotic MIDI problems that would never be solved by general purpose MIDI plugins (people kept asking me to add plugins to Rozeta for really obscure one-off use cases... So that's the need that Mozaic tries to address).
I never even imagined anyone would write a script of more than 100 lines
It’s not the stuff under the hood that Mozaiic lacks. I haven’t once felt the need for low level functionality. It’s the UI that’s crippled. Without the ability to give adequate visual feedback to the user, (barring writing thousands of lines of code), applications become obscure and difficult to use. I’ll carry on writing scripts for my own purposes, my current project generates 4 part fugues, either on its own or based on a theme played by the user, but because the UI will be too opaque, I will not be considering sharing it on PatchStorage.
@TheOriginalPaulB You probably wouldn’t have liked coding for StreamByter, which initially was more like assembler with its 3 char per instruction, one letter variable names, everything capitalized, no expressions, no logging etc. Got better and offered more language features in the end, but Mozaics more high level approach convinced very quickly as it’s easier to try things out and the scripts are more compact and readable.
In my opinion Mozaic is the best and most advanced midi scripting option we have on IOS and its practically bug-free, everything just works as stated in its excellent manual.
Mozaic is capable of performing many different and even complex midi tasks, but one has to cope with the language constructs that are available. You gotta do some maneuvers, but you can emulate data structures and linked lists even with linear one dimensional arrays. I understand that this kind of juggling isn’t everybodies cup of tea.
.
I still enjoy scripting in Mozaic, even though i managed to hit the barriers of what‘s capable of several times now and even in different dimensions (cpu, event-max, var-max, script-length-max, if-cascade max ...)
@_ki I’ve coded in a lot of languages, from assemby upwards, so it’s basically horses for courses. Streambyter doesn’t even pretend to have a UI, so this issue wouldn’t arise, as I wouldn’t use it for tasks that require one. Mozaic has a lot of possibilities and most of the time a little ingenuity can overcome its limitations, but you yourself have acknowledged that there’s no way to build dynamic labels other than if cascades. Writing thousands of lines of highly repetitive code just to support the UI is not juggling, it’s tilting at windmills and really not worth the time and effort.
Agreed, Mozaic's UI capabilities weren't really meant for that. Just for adding basic labels to knobs and controls to indicate their purpose. All script tools have grey areas where you start straying outside the realm of intended use cases, this is clearly one of Mozaic's
I think I said this during the good old Flow days;
If Mozaic supported appending to labels such as ”LabelKnobAppend”/”LabelKnob+” we’d need to write a lot less code for a lot of UI purposes. It clearly doesn’t solve all cases, but it would address most ”string concatenation” needs I’ve seen discussed in this forum over the last year+ or so.
@Brambos and @TheOriginalPaulB I just had a look at your example for the extreme long pad label setting if-cascade you uploaded to PatchStorage
With my two proposed functions all the 681 lines of code needed to just set a pad label would collapse into just two lines:
The second line wouldn‘t be that long, if a) your variable name was shorter and b) the ‚GetConstant‘ function name would be shorter, like when using ‚String‘ and ‚SetString‘ as new names
Its safe to call the SetStrings function not only in the OnLoad, but even in the knob labeling event as no new mem is allocated or things need to be copied - its just that the references could change during runtime.
.
Your case was 4x4x4x4 = 256 variants, but the needed if/elseif/endif add up to over 400 lines.
As said, i have use-cases ideas where i would need about 10 of these (String xx) in a single LabelPad line, its impossible to unroll that to an if-cascade due to number of possibilities.
And you probbably didn’t expect the multi-line pad label UIs when you though about that labels:
All done with the the cost of extensive if-cascading... and we could do even more crazy things if we had the String constants
.
Okay, okay - i admit, some of these (HostClock & NoteStatistics) wouldn‘t really profit from the feature-request... but i wanted to show the variety. And not to forget that others also have done cool UIs with icons and stuff in the labels, which probably also wasn‘t in the intended scope of the ‚LabelPad‘ or ‚LabelKnob‘ functionality
All I’d have needed was
Part1str = {S.}
Part2str = {A.}
Part3str = {T.}
Part4str = {B}
// Elsewhere in the code.
LabelPad pad, {Part Registers (}, Part1str, Part2str, Part3str, Part4str, {)}
I really don’t understand why brambos is so insistent on hamstringing Mozaic for the sake of not implementing this one feature. It would really improve the user experience.
@Peblin Cool, i see a different idea
But appending wouldn‘t really help in case of TheOriginalPaulB problem, instead of one 256 variant if-cascade, you would reduce that to four if-cascades with 4 variants each. With the if‘s thats still about 40 lines of code - versus the two lines i came up with that get rid of the cascades at all. With my approach you only need an if/else/endif, if the stucture of the label output changes, but not for different contents in the same order.
@TheOriginalPaulB Strings as datatypes are completly out of the scope of Mozaic - adding them is like opening pandorras box. Internally there is only one data type - a number. And anything else would require a complete rewrite and new software architecture - including all needed testing and so on.
Don‘t even think about having strings or string constants that way in Mozaic. Its simply not possible.
.
My proposed feature offers the same result, but doesn‘t need strings to be implemented at all, or any change of data types or expressions.
That’s bollocks. Mozaic can read and display string constants, so there is some capability for handling strings already. All Mozaic variables are arrays, strings are a special form of array. All you’d need internally is a flag to denote that the array is a string, (perhaps its length would do for this, being useful in assignments to other variables, with 0 signifying non string variables), that would also tell the mozaic engine to interpret ASCII values, storing letters as ints and translating back to letters on output in Log or LabelXxx calls.
Your way would confuse beginners, my way is completely transparent.
Don‘t get me wrong, i don’t want to start a fight or endless argument, i hope this will be my last post concerning this topic. I start to fear no-one else understands what i‘m talking about, and that my proposed feature was very carefully designed in that specific way and why it did it that way...
.
I had lots of PM discussions about about Mozaic internals and especially strings back and forth with Brambos last year.
.
Strings are only allowed as parameters in limited number of functions, like LabelPad, LabelKnob etc. Never in expression or variable assignement.
And then there are just some few functions that internally produce strings like ScaleName, NoteName etc - beeing only allowed as parameters to the mentioned functions allowing string paramaters.
.
Your idea requires a change of the innards of how Mozaics interpreter work - it‘s not just an extension that doesn‘t touch other parts of the interpreter engine. Your proposal adds variable-types to language without such concept and also new type of assigment. And if there is an assignment, people want to also have string operations like concatentation, etc. Pandoras box
.
I fully understand that ‚my way would confuse beginners‘, but i fear that‘s the only bridge we could get as it tries to minimizes the changes needed to be added to the interpreter and it fits with the concept like the existing RootName, ScaleName etc functions.
.
But with all this ranting about this single feature, which wasn’t indended at all for Mozaic i supect Bram is already annoyed. So it‘s back to long if-cascades for us script slaves
I did see @j_liljedahl write that we wouldn't make AUM a slave to another MIDI clock since it's a DAW and DAW's have to own their clock.
But after months of the same question re-surfacing he wrote he'd give it a shot but he's
not making any promises for timing quality.
I guess, never say never.
@_ki's scheme of the scripter providing a list of labels and then using list item numbers for labeling would be very useful as a "good enough" enhancement. I wouldn't expect more than just the display of the text I created in the list.
I was a professional software engineer for 18 years, 10 of those in an odd combination of embedded systems and user interfaces. I know exactly what you’re talking about.
I suspect brambos says whatever helps his case.
So he already has a way of handling them.
We already have concatenation, where strings are passed to the Label and Log functions. No need for it elsewhere.
Your way is a kludge, but neither your method nor mine will get implemented. I’ve seen this before. brambos is no longer listening, Mozaic will remain as it is.
I don’t care whether he’s annoyed or not, his implementation is flawed and he can’t admit it.
Anyway, I agree with you on one thing. We’re done here.
Never say never.
The implementation is extremely solid and powerful as is. Still... nice to have
this one extra feature and it might stimulate another round of users to invest.
Maybe split it into a $2 runtime app pre-loaded with scripts or the automation of
PatchStorage installs. And a new "Pro" developer's app to justify the extra work implementing this extra feature and it's anticipated support requirements.
I'm in the middle of a 5 hour process of writing an "if" cascade to put a series of on/off lights (in the form of white/black square emojis) into the knobs header, for the view where the "knobs" are sliders. Having spent so many hours with Mozaic, I'm hoping that Mozaic becomes a cultural phenomenon, as is.
I'm not such an experienced programmer; I've learned the most by inventing apps with Mozaic. Sometimes the limitations have been fun. Not for my current project, but fairly often. Slippery slope aside, I do think some string functionality would be nice to have.
I would like to see a sequel to Mozaic, maybe like three years from now. We'd then have two options for complexity, without splintering the community early on. It could have "Make your own layouts" and features like that. Very few people have the knowledge or time required to create such a thing, and maybe those few people won't have the desire. But it's easy to imagine pads and knobs with attributes for visibility, size, and position, being placed wherever you want. Or multiple XY pads, or different background colors. I support the quest to add simple features to Mozaic, but I would also love to see something more powerful in the future. @brambos Have you ever thought about it? Helping Mozaic to outgrow its intended purpose? Mozaic hats, Mozaic water bottles, Mozaic toilet seat covers, sports games at the Mozaic Center, roller coasters at Mozaic Land.
OK, Strings are out. I can live with that. I respect @brambos sticking to his vision. I feel bad for those that take it personally when his vision doesn't fit theirs, when it does so much.
@brambos - how about something like this possibly very simple enhancement?
No need for changing storage, string manipulation, manipulation or anything. The user stores integers in whatever way works for them. I don't know if returning a null character or some dummy character, or throwing an error is the best way to handle non-convertible characters, but the basic idea seems like it might be very-low impact to the language.
I haven’t taken it personally. I’m just pissed off that it only took me 3 projects to run up against such a needless showstopper when the rest of the package had such potential.
I’ve accepted he isn’t going to do anything about it and have adjusted my expectations of Mozaic’s usefulness accordingly.
He isn’t going to bother to do this, either, just wait and see.
Yeh, you're not bitter at all.
It's totally up to @brambos if he takes that suggestion or not. It won't bother me in the least. It ain't my product.
smooch
✌🏼
How is it a "flaw" and a "needless showstopper"? Sorry, but that's a little unfair.
Mozaic does exactly what I designed it to do: MIDI handling with a minimally adjustable UI layer and a syntax that's conceptually easy enough to grasp for literally everyone. Nowhere have I promised a fully programmable UI design tool or C-level language features. That has been quite clear from the start.
I have also explained that adding string handling is not trivial. You may dismiss this notion, but I am convinced that it would complicate my engine massively. And for what? Just for doing labels in the UI, which is barely a secondary use case for Mozaic.
I apologize if this disappoints you, but I have to make decisions - I can't magically make anything happen without much effort. Some things are simply too much work, too much risk and too much hassle with limited added benefits for the core target use cases. Mozaic is nice and stable and bug-free now, I'd like to keep it that way. Adding string handling would be like half a year of added work, lots of beta-testing and potentially lots of new bugs, crashing and other undesirable side-effects.
If it would be a matter of adding a function or three I wouldn't hesitate (like adding Sysex which wasn't originally there, but many people saw use for it), but it's quite a bit more involved than that, unfortunately
Just for the record ...
Features I can think of off the top of my head that have been added in response to user suggestions:
ColorPadsScaleName [<scalenum>]SystemTimeGetXYMorphValueA clear explanation (not a defense) has always been offered when he doesn't want to do something. Every known bug is always fixed. Best of breed developer approach IMO.
Also, leaving a 1-star review? Seriously..? 1 star usually means an app simply doesn't work, is made to scam you or has no redeeming qualities whatsoever.
Wow. That is sad.
This prompted me to check if my review is still active. It's not. I hate that.
Fixing ... another 5 stars on the US App Store at least. But ... Mozaic is at 100% 5-star there already.
I like that idea, seems like it could be very useful. We already have string concatenation for labels and log lines, this could simply be a single function that operates on an integer, yielding a character that can be concatenated in labels and logs. I'm no expert in constructing interpreters, but I can't see how this would be difficult to add to existing Mozaic framework.
Nobody is saying brambos hasn't delivered what he promised. Mozaic is already an excellent tool. However, the explanation that Mozaic is simply "done" seems really odd to me. It's a rare piece of software (and/or a dying piece of software) that doesn't grow organically over time, depending on the needs/desires of its users. Of course, developer economics/time/effort/complexity always factor in. But the suggestion by Wim seems like an easily implemented change that would address a lot of people's gripes.
Syntax ideas:
NumToChar <variable>, <start> [, <length>]NumToChar <variable>, <start> [, <end>]Log {Hello }, #myVar[0 ... 4]#, {!}Anyway - just some loose thoughts. ✌🏼
And for the record, I have no idea if this would be an "easy" request or not.
He's saying he believes adding this feature will de-stablize the application and
not serve the interests of it's users. If we proposed a useful feature he believed would
add extra value I'm sure he'd consider putting in more effort but he gets to
make those decisions of what to add and what to avoid. He's shown excellent
judgement over a huge collection of applications on many platforms and not
lost his focus on making high quality solutions that sell and deliver value at a fair price.
We should try to gently influence him to consider adding @_Ki's "indexed label lists"
because that would save a lot of if-then-elseif table madness for each label option and probably still be stable so everyone wins. We write more scripts and prove the value to users and more purchase the app to run them. Win for @brambos, scripters and Mozaic MIDI FX users.
Don't attack the source of the potential solution.
nvm. deleted.