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.
Mozaic midi file player
does anyone know, is there a patch for a midi file player in Mozaic? I’m not sure if it is even possible, but that would be pretty cool. i’d love to be able to load in a midi file and ha ve it play other apps
Comments
There is, as far as i know, no file in-/output in Mozaic.
Correct. There is no access to the file system. Mozaic does amazing things but it doesn't fit this use case well in this and other ways.
I wrote a script that somewhat successfully could record a respectable amount of midi and play it back, but it was stretching the limits of the app way too much to be practical, and without file access would have been of limited usefulness anyway, so I scrapped it.
May I ask, in what ways were you stretching the limits of the app?
The most challenging aspect is midi playback. Recording is a bit easier.
Accurate midi playback requires a timer to be running in Mozaic at the highest resolution possible. In that 1ms or so time a LOT has to happen. Since Mozaic arrays are limited to 1024 cells, midi events need to be stored in a large number of arrays to get longer recording times than just 1024 events. These are then recalled into the current buffer as needed during playback. Two correlated arrays must be fetched: one with the timing, and one with the midi event (three bytes packed to each cell). I pre-allocated two sets of 32 arrays for the ability to store 32,768 events. (With no cc automation that is a very long recording time. With a lot of automation or MPE it is shorter of course, but still plenty long for most purposes.)
So, during that 1ms timer, the current time needs to be checked to see if the next event is due. If it is due then the midi message must be unpacked and sent out as a midi. If the end of the buffers have been reached then the next buffers must be retrieved and the next event time read. All that has to happen in a 1ms loop to get the best available timing. It actually works but I expect is tough on CPU and might not be reliable under load. I found that a 5ms timer still worked well enough, but of course with less accuracy.
To be honest, I couldn't believe how much I was able to get away with. I never really thought it would work - it was just an experiment. But it's just way outside what Mozaic is designed to do. However, the main thing that makes it impractical is the limited use case of not being able to load or save files. I didn't see the point in releasing something that might not work well all the time (esp. during high CPU load), that you'd have to save as a preset every single time, and that you'd never be able to export to a midi file.
It was a fun and super educational experiment though. Mozaic is amazing.
( Sorry for the thread derail @eross )
@wim if you could be granted one wish from the Mozaic Genie would it be:
character data types
read/write to local files or some persistent storage mechanism
Ableton Link
MacOS Mozaic app
Anyone is free to weigh in here except the Mozaic Genie.
Access to the file system, including the ability to "include" scripts and to stream data to and from files. Some amazing things could happen with that.
But - to be clear - I'm not asking for anything. If Mozaic is fully baked, I have no complaints whatsoever.
The Mozaic Genie has many duties so we will get something new like clockwork...
since Mozaic the Genie has conjured Mononoke, Scatterbrain Audio Splitter, Woot
and 2 Mozaic updates fixing bugs.
I suspect Mozaic is one of those apps that the Genie would not add features in the interest
of maintaining stability for us that push it to do amazing things with MIDI streams which
is the essential use case. The extras for GUI and data management are wonderful
extensions to the stream-processing core design.
i also vote for access to the file system to import midi
I could imagine a Genie giving you a function to write variables to a "file"
and a function to read from that file into variables but probably not
opening and reading from a *.mid file.
But Genies are a type of God... you can talk to them and pray they hear you and
give you a sign. It wise NOT to offend one at any cost. If you want the extra goodies.
You may curse them under your breath.
Now, @wim also asked for the capability to "include" Mozaic scripts which saves time
adding repeated text across many different scripts and helps make the new script a lot easier to read assuming we all know what those "include" scripts contain but more than likely we'll have to open yet another file and read it to try and follow the code. But
proven, rock solid "include" code is usually documented and stable: high quality code produced by more gifted programmer's. Like a "ready to bake" cake box from those Genie's at Pillsbury.
It probably still wouldn't be an ideal platform for playing back said midi. I won't go into the technical details (and could well be wrong if I did).
It seems like it would throw you back into "timer" hell trying to see what needs to happen
now every 1msec. I played with the idea of setting a timer for the time to the next critical event in a MIDI looper. The "time since" start was saved for every incoming MIDI note so I could calculate time intervals between events easily.
If you had time since start info for each MIDI event, you might be better off having a regular timer event that would encompass a number of MIDI events, read all the stored MIDI events that need to happen before the next timer event and fire them off all at once with delays that are derived from time since start minus the current live playback time since start. That way Mozaic can handle all the micro timings and your script only has to worry about servicing the longer interval of your timer event. In theory, if that interval is smaller than the maximum permitted delay parameter, it should work, barring discovery of any new Mozaic limitaions.
Yes. That should also reproduce the midi events with accurate timing.
Solving the problem with actual code would be useful to learn more about Mozaic. I got distracted and didn't get to the "play" aspect. I just made a script to save Note On event
data with timestamps. I saved some number and logged the data out as a test.
There's a good possibility that any existing script that has a record/play feature has already solved the problem. I like that fact that any script you can download is readable too.
@_ki and/or @wim have probably written play/record code for a looper type script. There
are some others that have tackled it too.
i didn‘t yet publish any sequencer/looper script - i my tests were not as advanced as @wims (unpublished) recorder that spanned over multiple arrays.
My version uses a single array and an OnMetroPulse with 1/256 timing resolution (ppqn=64). And it didn‘t record pitchbend nor CCs, so i don‘t know if one would hear the pitchbend/CC stepping.
Here's the source code for my experiment. I only attempted to get it working to the point that I understood whether my approach was feasible. I didn't get to any kind of optimizing phase. I also didn't experiment with pre-fetching events as @TheOriginalPaulB suggests, as it seemed to be performing fairly well (better than I expected at any rate) without it. Bram indicated that scheduling midi out with delays is more resource intensive than just processing within as long a timer loop as possible is best so my focus was on doing only as much as needed at one time.
I don't plan to give this script any more attention. I'm not a fan of trying to force tools into doing things this far beyond what they're designed for. I learned what I wanted and cleared out the ideas cluttering up my brain, which is all I intended to do. Feel free to do anything you like with the code but keep in mind that it's not the product of a real coder, just a hack, and not even my best effort at that. I prefer not to be credited if you do publish anything based on this because none of the code satisfies the quality standards of something I'd put out in my name.
That said, I think there's plenty of interesting stuff buried in there.
https://www.dropbox.com/s/mpnxufk3fhazfk1/MML Mozaic Midi Looper v0.01.mozaic?dl=0
Thanks for sharing your experiment and slipping us a clue that Mozaic as a Looper is
not a great idea and many AUv3 Looping apps have also learned that music creators are
very demanding when it comes to what they want in a looper (Enso, L7, etc). The limitations of Mozaic's persistent storage, data structures and GUI features make it
like a skateboard made from those skates that adjusted with "keys" and had cheap metal wheels. Is anyone that old? We used segments of 2x4's and typically made a 90 degree upright handle bar and called it a scooter but eventually we just used a wide flat board
and the future opened up to wheelies and the rest is history and a billion ER visits.
It was especially fun when those old skateboards stopped instantaneously due to a piece of gravel lodging under one of the wheels.
"Look Mom! I can flyyyyyyyyyy..."
Yeah. That's probably the only time I used a broom on the sidewalk... all the way around the block.
Right after that phase of development I got a unicycle. It's amazing that I never broke and bones... just lost a lot of surface skin.
Kids would throw gravel in your path just for the fun of watching you take flight.
Interesting attempt to get this working. Sometimes it can be fun to try to work around constraints built in to your language and development tools. (Other times not so much.)
I'm not sure I understand fully what you were doing. But it seems like Mozaic already has its own sub-system for scheduling and sending midi commands with 1ms accuracy. I'm talking about the optional fourth parameter to the SendMidi... commands that lets you set a delay that, once you issue the command, Mozaic will queue commands and monitor and send them at the appropriate time. Is there some reason you weren't using this fourth parameter to pre-issue commands and let Mozaic handle issuing them at the correct time? Or were you?
That was my first assumption of the best path too, but I checked with the developer and he said queuing up a lot of delayed midi events would be disastrous. He recommended keeping with a timer, and keeping the timer interval as long as practical.
If Mozaic can’t handle 125ms worth of queued MIDI events fired off by a timer event called every 1/8 second then there’s not a lot that can be said...
No-one said it can't. I didn't try.
I'm not convinced that's a more efficient approach anyway. And don't care enough to bother finding out.
btw, 128 ms worth of events can be a shit ton when you get midi heavy automation or MPE involved.
Someone has to be checking that event queue no matter whether it's in a scripted timer or in the background code. I don't think it's clear at all which would be more efficient. But that's coming from a self-taught amateur, so I don't claim to know anything.
Just to be clear for all - I never said Mozaic couldn't handle my script. It seemed to do pretty well. It just wasn't a good use case for Mozaic IMO. A midi recorder that you'd need to record its output into something else to do anything with isn't all that useful to me.
f> @wim said:
I must have misunderstood. I thought you said that the dev said it would be disasterous...
He said it could be disastrous to queue up a huge number of events. He didn't provide any numbers. It was general guidance only.
@TheOriginalPaulB
My memory was faulty: Here's the actual exchange. https://forum.audiob.us/discussion/comment/726653/#Comment_726653. If you read down a bit you'll also see he thought some limited buffering might work. I decided just to do one event at a time.
I'm going to bow out of further discussion on this topic here since it's OT to the thread.
All things being equal, if there’s no efficiency gain in using the delay queue, then the big win lies in not having to complicate the script by duplicating that functionality. It’s there, might as well use it if it can be made to work. The 125ms figure can be reduced if the density of MIDI events is too high, I just plucked that figure out of thin air.
I’ll let you all get back to discussing skateboards...
touché 😂
The general pattern for Mozaic designs has typically been we ask hard questions and
@_ki writes code and let's us know if the idea can be done. The questions are usually
in the form "Cam Mozaic do ------?" @_Ki says "No." and someone says but what if you:
"Tried bit masking
"or evaluated notes for chord structure and determined the root note for a new baseline"
"computer all primes up to 1024**2" and used them for polyphony in 4 different PPQN's
The trick is always to engage @_Ki's curiosity.
Now, @wim will tell you there's a perfectly good app that does what you want and he's not going to waste his time making you a free looper.
But sometimes @wim says... "Hang on. Let me thing about it" and someone gets a custom
solution.
The secret is always getting someone interested in the problem that has the skills to crack the puzzle.
The code to compare the 2 solutions being debated can be written in a couple days and then the solutions could be evaluated for any perceived benefits. In reality for most moderate MIDI stream they may not show an appreciable difference. IN one the script
manages time spacing and in the other the Mozaic engine accepts lists of time-based outputs. One would probably prove superior as the input stream becomes denser and
something breaks.
Who ever accepts the challenge will learn more than the rest of us that wait for an answer.
L7 is a nice little looper by the way in an AUv3 package and costs very little. I never got fluent with Atom to that other one. Real Loopers want a huge list of features anyway so
there are no users for the effort. But it's a tricky programming exercise to learn data structures and timing as well as basic MIDI event types.