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
Thanks @moForte!
Here is another update. We had 2 users from this group install a testflight build with a speculative fix. Unfortunately it did not fix the problem.
Note that we are not able to reproduce the problem and putting out feelers to various influencers they are not experiencing it either. Because we can't reproduce it, the debug strategy is speculative... try to guess what is failing. The part of the system that is failing, the preset cache was not changed at all between the Dec release and the Feb release, so it's something else.
That being said there are 2 users in this group who have been helping by doing testflight installs. We have another testflight build in review now that is highly instrumented so that we can try to figure out what is going on. I'll post an update tomorrow once we know.
Again if you have a project and you need to move forward, a preset backup, delete, clean install, preset restore will address the problem. That being said we prefer to deliver a hot fix that will address the problem.
Thanks,
-pat
Since it looks like this problem may not be solved quickly, I had to go ahead with my "not preferred" option of manually backing up all my custom preset data, then I deleted the GeoShred Pro app and then carried on reinstalling everything.
It now works, but I still hope you're able to find a simpler solution for people because it takes a bit of time when you have a lot of custom presets like me. It appears there's no way to export and import a folder full of our presets, so each one must be carefully manually exported and imported.
Please consider an easier option for users so presets can be saved or imported by folder instead of individual presets if possible in a future update. Thanks.
Another update this morning. Late last night we created a second testflight build that may fix the problem based on a speculative fix. We also added a new settings switch (in the settings) app that can be turned on to generate extensive trace about the GeoShred boot sequence. That testflight build cleared Apple's approval queue in the last hour and our 2 users have agreed to install this second build, let us know if it crashes and send us the trace.
In looking at Apple's analytics it looks like about 12% of stand alone app sessions (not plugin sessions) are affected by this problem. That comports with our not being able to reproduce it on any of our test devices.
I also note that the work to create the extensive trace is most of the work needed for a bulk backup/restore which is on our near term list. I expect we will add that feature soon.
I will post more info later in the day. -pat
NeuMuzik, I'm glad that you were able to successfully do a clean install and GeoShred now works. That being said, we will release a hotfix as soon as we can track down the problem.
I note that the work to create the extensive trace for the second testflight is most of the work needed for a bulk backup/restore which is on our near term list. I expect we will add that feature soon.
Thanks,
-pat
A further update. One of our testflight users confirms that the testflight build of the hotfix solves the problem. I'm waiting for the second user to respond. Also this build with the hotfix is now in review. I expect Apple will clear it in a few hours.
Thanks,
-pat
Another update. The hotfix has passed testing from both of our users. It's also cleared Apple's approval queue. We are going to test for a few more hours and then release it. I will post an update when it's released. Thanks, -pat
The hotfix is live. GeoShred 5.941.1.1.1. You should be able to just do an update install and the previous stand-alone app crash should no longer happen.
Thanks for everyone's patience as we worked though this issue. And thanks to the 2 users in this group who assisted us with qualifying the fix.
As for what went wrong it's not entirely clear. We know from Apple Analytics that 12% of stand alone app sessions (but not plugin sessions) were affected by this issue.
What we were able to tell from the 2 sets of instrumentation files that were sent back to us is that both users had data in their caches dating back to GeoShred 3. GeoShred has handled this old data for years, yet somehow with this release it was not handled correctly. The solution was to re-implement that code a different way. This is in code that has not changed for years, and its unclear why it is behaving differently now than from the Dec release. I have a gut feeling that something subtle changed in the iOS SDKs. We've seen that before.
That being said, if your project or workflow was interrupted, please reach out to me directly at [email protected] and we see what we can do to help you.
Thanks,
-pat
Always an inspiration in your beautiful approach to customer care and impeccable communication skills Pat, major kudos 🙏
This thread should be made into a "How to" for iOS developers on how to engage with and use this forum to cooperatively address an issue and achieve a textbook win-win result.
I wasn't affected because I had not updated the app before reading about the issue, which enabled me to sit this one out, but respect to both moforte and the forum testers. 👍
+1000
Although I was unable to wait for the App Store fix, thanks for the rapid response and "all hands on deck" approach to getting this fixed fast. I appreciate it, folks.
Hi, can confirm it’s working now for me too 👍 Thanks Pat! 😺
Quick question…
I thought geoshred had some parameters exposed to automate. I’m in AUM got a nice track but it’s dying to have the vibrato and filter sliders LFo’d. Maybe this is something I have forgotten about but I thought stuff was exposed. when I open up the midi there is only a couple. One is preset changes, another is geoshred version, what’s that parameter? I also thought you could set the vibrato and filter slides to lock instead of a snap back to 0. Maybe I’m just blanking on this or but hoping someone can help me remember? Geoshred Exposed parameters in AUM? Lock on expression sliders?
Hi @Poppadocrock . GS doesn’t make the parameters visible in the normal way as there are thousands of them and they are dynamic but they are automatable.
If you go to the menu and then Control Surface then press the control you want to automate, then press the MIDI button this will show you the CC you need to use. 107 and 111 for Vibrato and Filter for me.
Set up your LFO and then in MIDI Routing point the LFO at GS. This should work.
For the lock go to the Control surface again from the menu and press the control you want e.g. Vibrato Depth. Press ‘Vibrato Depth’ with the little guitar picture to the left. ‘Set value on release’ will be blue meaning it will go back to zero. Press the blue bit to unselect it and this will lock the value where you take your finger off.
You may have to save the preset your working on for all of the above to work.
Hope this makes sense and works 😊
Thanks @GeoTony that makes sense. I thought I had automated GS before… Thanks for refresher, cheers.
I dug up the wrong thread too, my bad.