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.
ELK Audio OS goes open source Raspberry Pi dev kits coming.
Could be big news. Let’s see what people literally make of this. I’m tempted to put a pre order in.
Comments
Looks like a solution made for building your own Eurorack modules with audio I/O, CV/Gate I/O and lots of buttons, LEDs and knobs.
I wonder what the DSP performance of a Raspberry 3 or 4 is like, compared to e.g. the Zoia.
Can you imagine something like Mozaic App inside a Raspberry Pi that would be cool. Or a programmable effects unit for loading in different delay or reverb plugins.
Amazing news! Thanks for heads up!
Last year I felt like giving an old Pi B and a Roland UA-100 USB Audio/MIDI interface some love. The MIDI part was easy, I've written a small MIDI note transposer and chord memory in Python, all worked well with very low latency but I have yet to spend some time to make audio I/O work. The UA-100 doesn't seem to be the easiest candidate for the RPI...
When it works, I'd use PureData patches for audio and MIDI, they're supported on the Pi.
My very first thought when I began beta testing Mozaic was how utterly fantastic it would be to have a hardware box with the Mozaic pads and knobs that you could download scripts into. I figured an interpreter-only version running in a Raspberry Pi as the engine would be relatively easy thing to do. @brambos was wise enough to politely ignore my lunacy.
This looks interesting. I've been looking into ways to do some CV control stuff and this could be a fun way to do it.
The Pi's are going to be much more powerful in a general way, but it will depend a bit on what you are doing. The Pi 4 has a ton of memory to work with so that's a big point in its favor for me. The Zoia and things like it that run directly on DSP processors have less overhead to deal with. You could expend your Pi with some DSP or even FPGA if you decided you needed to.
I have a a model 3 configured to work as a little synth dev module. I was only doing audio out with it and really only at an experimental level, but they are pretty capable little computers. The RPi 4 looks like it's going to be much more powerful.
Since Mozaic scripts look like a mix between shell scripts and Python/Basic/Java code, writing such an interpreter shouldn't be too difficult, but it would take time of course.
Who knows, releasing the source code of the core interpreter could indeed be something for @brambos to think about... I don't think it would hurt Mozaic sales.
I'm using MidiFire for the same purpose for two reasons:
First, MidiFire works as a standalone app (with its own functional modules so sometimes you don't even need to write a script), and second, v1.15 still runs on an old iPhone 4 e.g. with an iRig Midi connected which is cheaper than a Raspi plus MIDI interface plus touch screen.
I wasn’t at all hoping for anything with a touch screen. Real knobs and pads in a box or what’s the point? The Raspberry Pi would only be doing the I/O and script interpretation - which would also remove the need for screen interaction - probably a massive percentage of the code base. The attraction is the ability to turn good Mozaic scripts into something that works exactly the same as the script, but with haptics.
I also definitely wouldn’t want to go to the work of building that interpreter even if the Mozaic source was available. I don’t see why it would be of any benefit for Bram to release it in any case.
I had similar idea for any iOS app and I don’t think it will be bad for developers... in fact it could be a solution for low revenue due Apple price policy even as a complement (instead substitute).
https://forum.audiob.us/discussion/31931/finally-some-open-source-serious-embed-platoform-is-emerging
Then keeping the apps on iOS as main development and embedded as stable version (think on devian over other distros) and also as project manager (think in looper apps like loopy or gtl) and you have a nice business model. Obviously it requires some hardware knowledge if you want to release custom UI but even just doing the class compliant thing iOS does it’s just translate app bones into new body.
I will love apple releasing something like that (opLab, iPod touch bones, appletv as embed...) but probably not going to happen never. ITOH mobmuplat works on android too...
I don't think you can easily transfer any IOS app into the Pi environment.
The GUI and Libs don't have a counterpart, there's only VST support mentioned.
Of course you may transfer your own custom ARM code, which is probably a rare case (guessing fom Apple's extensive libs and the sheer amount of apps released in a relatively short timeframe).
Imho this SDK adresses the Eurorack folks in the first place, providing signal channels that are not available on a standard audio interface.
@Telefunky
I suppose you didn’t read the Juce part of ELK or libpd library neither (which people is using to port patches into booth platforms).
Juce is multiplatform includding iOS and linux so you can code and then export to both iDevice and Pi. ELK makes even easier bringing the Juce audio API into its development tools...
https://juce.com/
@TheDubbyLabby I didn't overlook these, but admit I'm not familiar with statistics about their actual presence in released apps
I'm basically interested because there's this Pi thing I scored for a few bucks sitting idle on the shelf...
(will check JUCE's interface handling, though)
Roli apps are an example (since they own Juce it seems legit) but also Gadget if I remember well...
https://juce.com/discover/stories/korg-gadget
https://juce.com/discover/made-with-juce
https://juce.com/discover/stories/building-max-with-juce
Check my Gtl forum post to see more info (and also other platforms
https://forum.grouptheloop.com/index.php?p=/discussion/259/turn-gtl-standalone-hardware-gear
did check and my concerns are similiar to Jacks's
just illustrate what crossed my mind, not to state true or false.
Yes these concerns are valid but if you keep reading will see my idea about not porting actual apps as is more than lite versions keeping the main development inside iOS realm. Which comes to my mind is major updates being rewrote in juce so developers could embed their apps outside Apple ecosystem as alternative income... giving them the numbers they usually don’t get and also to users the standalone gear which usually it’s willing to be bought at higher prices. Atm that hardware are iOS devices themselves but, being not a music focused platform, time to time you find issues like cpu throttling or fixed 48Khz bug due in essence phone duties are on top over the rest (maybe Apple Arcade will balance that but don’t hold your breath).
Said that, ELK provides API and probably solutions to these concerns by their forum. If Juce is good for gadget or maxmsp I can’t believe it will be so hard to port regular apps.
For me the true issue is hardware UI (aka buttons, faders, leds and lcds...) for software developers who had any experience with that side... (microcontrollers). Anyways class compliant controllers could be a solution for that if you just decide to release a AUv3 host box.
Where people see issues I see opportunity...
I've signed up through their store link to do the preorder. I'll definitely be porting my AU's to work as Linux VST if the whole thing actually works out. My AU's are pretty heavily dependent on Apple's libraries since I don't use any library like JUCE and I do use a ton of the vDSP stuff. Still, the core algorithms will port easily -- just need to learn new ways to optimize where needed.
The more interesting side of things is going to be setting up the UI running on iOS to control the VST and perhaps even the DAW. I've been reading through their docs today and it looks like there are some pretty cool capabilities in this direction.