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.
Early release vs waiting.
I was thinking about Skram as I had an app cul.
Skram had quite a bit of positive reaction when it was initially released, even though due to its limitations, my opinion is that it is not ready for prime time iOS integration.
I can understand early releases may be needed to raise finance for further development.
Yet as time goes by, the initial positive reaction naturally wains.
Yes we are not very patient as consumers these days, but devs know that.
I'm just throwing it out there. Do you think that developers are more wise to wait until apps reach a certain level of use before release, if they know that further development will take a while? Do you think it's better that devs release paid for apps at early stages to release dev funds, even if their initial impetus may be lost? Any ground in between?
Comments
Release early and update often seems a good way to go. Blox wave being a good example.
It depends on the agility of the dev team.
If you are able to be properly agile with enough resources to do regular incremental releases and your motivation for early release is to get feedback and adapt your product to suit, then early release is a good thing, otherwise it can do nothing but harm.
I won't buy apps that don't have all the features I want in place. "We will add feature X soon" gets a pass from me. The flip side of that is that when I buy an app I don't get upset if the developer doesn't add feature Y later on. Bug fixes are a different matter.
I think devs would be better able to answer what works best. There are likely several different answers depending on the circumstances. If I was an iOS dev, I probably wouldn't want to sell short on an incomplete app.
I don’t buy anything unless I can use it as it is, and it’s worth the time and money as it is. I’m more interested in what the app does than how it integrates, unless integration is its primary purpose. I think if anyone wants to buy on speculation, that’s nice for the developer, but the buyer should know there are no guarantees.
FWIW, I personally think it totally depends on the app / intended users and the developer's circumstances. For example, I don't think it would have been a good idea for Moog to release the Model 15 saying "AudioBus and MIDI support coming soon" Some might argue it's a bad idea for a "one man band" / "this isn't my day job" developer like me to be doing that, but I get more positive feedback than negative on that stance, and I do my best to explain why I've chosen to update my app with small, frequent, and primarily user-driven updates. It's only been a few months in the game for me and it's my first iOS app, but I certainly don't regret taking that path.
If it works out of the box and performs a function that I desire plus has a way to integrate its output via AB or IAA without having to use iTunes then that covers many bases. Easy file management and easy import if sample based are important.
Syncing capability if appropriate is good to have. After that is bug fixes and then additional features.
AB, sample IO and Link seem to be the things most often missing on new apps and most called-out in this forum.
Moodscaper is a good example. It makes atmospheric ambient backdrops. I can use AUM to record it. The resulting file can be used any number of ways on my iPad or my desktop. Not something I do every day, but that’s functional for me. I’m glad the developer didn’t wait to release it. If it can do more in the future, that’s gravy.
Wow. +1 at pretty much every single reply here.
I think the difficult aspect with how Skram has been developed so far is that the app works as is, but the developer promised there'd be additional functionality and connectivity soon. "Soon" has yet to translate into any sort of specific timetable so if your idea of what soon is has already passed, you're going to be disappointed with what you expected from the app based upon the developer's initial claims. I think the degree to which a developer can come up with a reasonably specific timetable they can make good on, the better off they'll be. If they can't make any of these sorts of assurances with any degree of confidence, my belief is they shouldn't make any promises.
Because my experience with Lemur over the years has been good, I've given them quite a bit of slack with Skram. If something doesn't materialize by the end of summer, my willingness to give them the benefit of the doubt with Skram will have expired.
If it's a new developer, I tend to evaluate based on the current functionality of the app and take whatever promises they make about future additions with a grain of salt.
When a new developer comes out with an app having functionality I'm interested in, it has connectivity, and the reviewers seem to think it works (i.e. thesoundtestroom and the like), I buy it without much heming and hawing.
So all things being equal, if a developer is really interested in seeing how much support there is for their app and it's not an app that's marketed towards the general public, they're better off adding some essential connectivity rather than testing the waters without any connectivity because the interest may be low due to users not wanting to invest in promises which may never be delivered upon. If there isn't enough interest expressed via people getting the app to make it worth the developer's while, then the users will still have a useful app and the developer can focus on other projects.