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.
Is parity not the objective?
I don't understand why/how some developers port their desktop plugins to iOS, and neglect to add key features from the original.
Shouldn't your 1.0 iOS release at least match your 1.0 desktop one?
Is there a deadline to meet? Does this bother others?
I often read the manual before I buy an app, and I expect the app to have everything that's in the manual. Am I entitled or insane for thinking this is the way to go about shopping for a new product?
- -16 votes
- Sooner0.00%
- Feature Complete100.00%
Comments
There's not an option that works for me in the poll.
I think it comes down to what works for the developer. Only they know how time consuming certain parts of a port will be, what they think they can pull off well on the other platform, what libraries they've used that are cross platform compatible and which need to be written from scratch ... software porting isn't like translating a book or remodeling a kitchen, especially between platforms that are so different in many ways.
The real question is more "Would you prefer ported apps always be feature complete even if that may mean the developer decides it's not worth their effort?"
Why a developer has to develop some product with a different characteristics for a platform where the base user is a ultra minimum in compare with desktop?
Right Wim. A common problem, for example, seems to be that devs often use JUCE to port, but JUCE doesn't support some functions, making direct ports of certain features difficult or impossible. So in some cases, parity would demand a complete rewrite of the app or would require leaving things out of the desktop version just to ensure parity. Rewrites would make things much more expensive, but iOS is an extremely price sensitive niche. I can see why compromises are sometimes necessary.
Agree with Wim. It's too simplistic a question for a complex topic. Personally I have little complaints for the most part for what we get on our iPads
I'm not so much looking for a straightforward answer, more to watch a discussion and to gain some understanding for myself.
I mean no disrespect, I'm just trying to satiate my curiosity and ignorance here. I appreciate the insight @wim
I agree with this sentiment. I also rely on my iPad solely for my music creation and don't want to be envious of desktop users that are supposedly using the same plugins as we are.
It doesn't sit right with me; that sometimes we get a "pocket" version of a plugin, and no iOS specific feature comparisons or manuals to judge your purchase on.
It's best to talk to the developers directly, asking them about the feature(s) you're missing.
Another aspect - on iOS we usually pay about 1/8 of the desktop price.
I can’t imagine there would be someone who intentionally doesn’t set the objective to reach feature parity, excluding the obvious “lite” version types of ports.
Things go wrong. Software can be very unforgiving if you made a choice in the past which turns out to be the wrong one for the present or future. My personal experience is that feature parity almost always requires some code which creates said features to change, sometimes substantially. I’ve run into libraries that work fine on Windows, Mac, Android…and just don’t compile at all for iOS. Next thing you know you’re crying into a dusty old book on C programming from the 90’s and yelling at Xcode again. It gets gnarly. These are worst-case scenarios, of course, but it happens.
If an app was always intended to have an iOS variant from inception, the likelihood of achieving feature parity may be higher since there is a greater chance it was designed for. On the other hand, if an iOS version is added on later as a way to expand the product’s reach, and it hadn’t been designed around initially, there’s going to be some fun “refactoring.” Some things may just not be possible for one reason or another. Or, they may be possible at great expense.
This is all from the perspective of a developer. I know there are companies that do not care to do a good job. They will sell you a watered-down version of something without batting an eye. But, I don’t think this community and the apps we enjoy using here are [often] in that category.
I do think it’s fair for you to want a feature that’s specified in a manual to exist in the app.
Insightful comment Tom, thanks. I'm curious: when something like JUCE lacks a feature for the iOS port (let's say Drag and Drop) which is there in the original, what kind of shenanigans are involved in making it work. Because I remember that Audiomodern managed to get drag and drop working in their JUCE ports but I heard other devs saying, we can't add that, JUCE doesn't support it etc.
Yes, agree that not making iPad and iOS specific manuals is not on. I know the prices are for the most part much lower on iPads, but manuals need to be specific. Ok, I rarely read manuals as my printer died and need a new one (I try to print them, as have difficulty reading type on a screen for too long).
I think there may be another issue that this is a part of: that of releasing music hardware and software before it’s really complete or finished. Just look at the new Kontrol keyboards I’m eyeing up for this! Possibly not what the OP meant in this case, but the two may definitely be related in some instances.
As I say, I’m pretty happy with a few compromises in most instances so that I’ve got lots of apps at pretty low prices. I do find that developers are pretty fair and reasonable people for the most part; especially the one person devs that have kept the iOS music making community happy for so long.
Just to add to my comments and opinions as a whole, I believe as iPad apps get closer to Mac and PC prices, they should be closer in parity too as a general rule.
If devs ever want full Mac PC prices for iPad apps, then they better make sure that ported apps are made specifically for the merits of touch screen use!
I know iOS is a smaller market, but we also have no resale value and a few other disadvantages compared to Mac PC software.
I am, on the whole in the belief that devs are pretty fair and reasonable at the moment in their iOS treatment.
I’ll try to answer this generally, to avoid speaking for anyone else and their choices.
Often these frameworks like JUCE can function as a boilerplate or an end-to-end solution, or somewhere in between at the developer’s discretion. There’s a balance to strike there:
Using the framework for boilerplate functionality decreases reliance on it. More of the app will have to be made custom from scratch. This is the hard way, but it reduces the risk of getting trapped by any framework deficiencies. In the long run this almost always pays off, if there’s enough funding to support the longer development cycle.
Using the framework as an end-to-end solution will likely get the project to the finish line faster, but it will be heavily reliant on someone else’s code. This is the path of least resistance, and is a very valid path to take. It’s often great until there is an encounter with a feature that is not supported by the framework.
Using JUCE as a boilerplate gives developers a way to build VST, AU, etc., without having to write that system-level plugin code over and over for each system. This makes it the app developer’s responsibility to create all the feature and UI code. If this route is taken, it could be easier to deal with UI-level issues like Drag and Drop.
Using JUCE as an end-to-end solution will likely mean that the JUCE UI system is in use. If the UI system doesn’t support a feature it could be quite difficult to add it. This can be very difficult to back out of later. It may be very error prone, too, if a developer leverages something like JUCE to work around a lack of experience with C++, for example. The cost of undoing this choice can easily be greater than making the “hard way” choice the first time.
This is very useful and interesting, thnx for taking the time 🙏
Yes, 100% agree. Manuals should never lie to the user, to the extent possible (typos and bad editing happen).
Asking out of genuine curiosity:
What do you think is the breaking point where iPad app prices can realistically hit desktop levels? It’s not uncommon for good (subjective, of course) ports to cost well below what their desktop counterparts cost. I think Audio Damage, on the whole, is a good example of this. I can’t imagine anyone paying “full” price for Other Desert Cities on the iPad for example…but is it missing anything? It works fine, IMO, on touchscreen…but to your point it isn’t purpose built for the touchscreen.
I know the argument for resale value, I’m curious specifically if there’s opinions on whether or not these are limited products in usage comparisons. As it pertains to the thread question, how realistic is it to expect the ports to mirror the desktop versions if the developer can never charge the same price? Maybe this is a chicken and egg problem?
Again, really curious here, and I value whatever opinions you all have.
I'm wondering that feature/economics breaking point as well.
On one hand; I'm beyond pleased, enamored with and grateful for the vast majority of apps I purchase, and even though I can't directly compare their desktop counter-parts for myself usually, I usually do not feel any kind of real world disparity in function/performance. What is an essential parameter for one, is not for another, etc. Other Desert Cities never leaves my screen FWIW
I only really have problem when a plug-in advertises a feature as a selling point, that is featured in the only available (desktop) manual, and that feature is missing from the port.
On the other, I am willing to pay more for a more polished experience, that much is certain. For UIs that scale properly; reworked fonts and gestures that take into consideration and respect the device we're purchasing them on. Standalone and AuV3 support as at least a consideration, exposed AU parameters that actually function. Optimized file sizes and innovative layout designs, I will support and purchase apps for those alone sometimes.
Sure!
As a developer I am cautious in these conversations, as I’ve been through enough s*** to know better than to criticize another developer’s choices or issues.
As a user, I totally agree with you about the misleading nature of a missing feature(s) that isn’t explicitly noted. That doesn’t feel good, especially if the expectation of that feature was a basis for the purchase in the first place. The frustration there is understandable. I do believe that most developers in this niche would welcome direct contact to address those types of issues.
Thanks for sharing your thoughts on what you look for in a plugin, too!
All fair questions and obviously my answers may vary on a case by case basis.
I will just give a generalised response at the moment as going to be busy with music stuff soon and haven’t got the time for an in-depth response.
Let’s just say, that for the general disparity in price between Mac Pc apps to iOS apps, I would say that feature for feature, iOS apps give so much more bang for the buck. That’s why I would rarely complain if devs have to make a few changes here or there, most of which are not an issue, as you pointed out with certain apps being lots cheaper and having most their Mac features. I think the buyer generally comes out on top for what we get, with some system disadvantages.
I couldn’t say there is a breaking point, as it’s so individual for each buyer. After all what is software worth, especially when it can be broken or become useless at a moments notice by an iPad or laptop update! Would you pay the same money for Cubase on iPad, even if they could make it work well for the touch and smaller screen? Maybe you would, but then you would expect the same updating service and backup by a team as large. Cubasis is a compromise and that is born out in the price. I think as a rule devs try really hard with their iOS apps. I wouldn’t be surprised if Cubasis makes very little money and is more of a device to lure Apple device users towards the full Cubase for Mac.
Also keep in mind, iPads have disadvantages over other forms of computer (lack of ports, screen size, relatively higher cost for high spec models, lack of 3rd party peripherals and support, some closed environment differences etc). I think that I’ve lost the same amount of money in apps lost to time on iPad as I have my PC music software in the past. Will see if the same ends up happening now I have a Mac.
I love most of the ports we are getting, but I personally would love to see some more very creative touch screen centric apps like Borderlands, Drum Jam, TC11, Gestrument Pro and Samplr
Oh, I suddenly had flashbacks...
I'm willing to pay more for UIs that scale properly etc too. The problem is though, based on discussions I have had with some devs, that many users are not. Devs need to be so careful in their pricing, as even just an extra 5 bucks can lead to a lot fewer sales. It's a tough market with, for most devs, skimpy payback!
I've usedmany apps on different platforms over the decades, like Word for Mac and Word for Windows, Photoshop, Linux ports. More often than not the ports are not identical, including lacking features found in the alternative platform version. Nothing new. Carry on.
This.
Fun to chat about but, in answer to the question at the top, the devs’ chief objective in porting software, rather than parity between ports, is probably to make me something I will buy. Maybe also to make something cool, for their own satisfaction.
The two apps that I use on both iPad and laptop deliver exact parity
(okay one of these is missing a laptop feature in its iPad version. Which I’m pestering the dev about on his forum)
(The other one achieves parity on four active platforms and at least another three deprecated ones)
When I think about what these two dudes objectives were when they built their ports. I could speculate that they thought parity is the correct function of ports
But the devs themselves are very interesting and very talented characters, their software is incredibly elegant and powerful, and they don’t seem particularly interested in making money.
Figuring out their true objectives is way above my pay grade, but whatever their objectives were, the results on both platforms is magic to this primitive.
@Goldiblockz : I think built into the question is an implication that when mobile ports do match the desktop it is because of neglect — when it is often a matter that achieving parity may come at a price a developer (and we are most often talking about tiny organizations that may be one to a few people) finds they can’t afford.
Most developers porting from desktop find that they essentially lose money… the amount of revenue their iOS apps generate is tiny.
There are two different issues that play into this: fewer pros (or pro-level amateurs) are using iOS than desktops, the prices that the market will bear [if a developer charged desktop prices, their sales would be tiny].
The result is either a developer does a complete, well-documented port as a labor of love or the releases will be incomplete in some sort of way.
I think “ Is parity not the objective?” has a built in bias/slant.
A better question might be “why isn’t there more parity between desktop and mobile releases”.
I think devs should be up front about missing features, but when they aren’t it is more likely an oversight rather than an attempt to deceive.
Haha, I did it to myself too by typing that statement.
The point about iPads having disadvantages is an interesting one. Essentially, does it make the system seem less valuable, and therefore does that make the programs that run on it less valuable as well? I would guess many people may see it that way.
For me the iPad is very often used as a component in my setup, rather than the centerpiece. I use my Mac more often than not, and I use the IPad “solo” when I am just messing around. I imagine this is a different equation for someone who wants to centralize the iPad more. Individual to each buyer, as you said.
Bringing us back, I wouldn’t be surprised if many ports do exist as a vehicle to bring people ultimately into the desktop-class versions at some point. Simplified versions of larger apps, like Cubasis or the iPad version of DaVinci Resolve, are good examples.
Yes interesting avenue of thought. My personal perspective is from someone whom has used an iPad for making music for over 10 years, but literally just bought a Mac in the last week!
My first experiences with my Mac are an instant disconnect as I do not have my intended purchases of a controller keyboard and proper audio interface yet (using an SP404mk2 as interface for testing). So at this time, my iPad is not only more known, but easier to engage with via the touch screen.
As with all things, I can envisage somethings worth without being able to physically experience it just yet - I know that the Mac will eventually become my main recording hub and with Arturias Keylab mk3, I will have decent access to a range of software synths. My hardware gear will make up the rest of my setup, with my iPad as a sound module. I currently write my tracks on the iPad, but jam for fun with a Circuit Tracks controlling a Minilogue XD, while I use the XDs keyboard to play my iPad synths in AUM via the USB midi of my SP404mk2. I make beats on the iPad, which I record onto the SP404MK2 to use to jam with.
So for myself, my iPad currently has a greater role in my setup, the plan is for my new Mac to take over many of the iPad roles. Sorry if slightly a tangent, but it's to give a view on my perspective.
Now if we look at what the Mac has: a rich history of software development and music making software that just isn't available on an iPad. The use of more, larger and easier to connect screen realestate. The use of a greater selection of 3rd party peripherals. Much better battery life. The Mac however lacks the intimacy of the touch screen interface.
Now if we look at what the iPad has: even smaller and lighter than the Macbooks without the keyboard. The great touch screen interface which makes it feel more directly like an instrument without adding external peripherals. The downside is pretty much all the positives of the Mac.
There is more to it than what each device does best though. They both have a place either individually or together (where I think they shine). They both come from different backgrounds and these backgrounds have shaped how these devices are seen by developers and users:
The Mac comes from a business background where large bloated software packages became the expectation. Only recently are more selective, specialised and small 'app' like software becoming a big part of the market. The Mac is also firmly entrenched in the professional music making arena.
The iPad is the new kid on the block (yeah I've been watching It!). It comes more from the mobile phone market of sell cheap , sell lots! Problem is the market of music making on i-devices is relatively small and I don't believe that the really cheap prices work, so prices are steadily rising at a slow pace to get people used to them. I think this has held the software development back to some degree, especially in the larger DAW environment. Add to this other Apple decisions in hardware design like the slow take up of USB C and other standards, has kept the 3rd party peripheral market small.
Sorry for the long winded reply. My head isn't at its best.
As with all things, a combination of market forces, changing standards and many other things have brought two devices together into a specialised market from two different directions and yes they are going to go through change as they are forced together in various ways, sometimes smoothly, sometimes not. But the OP question is about parity and to be honest, I'm not sure that parity of the two systems as a whole is the best possible outcome. For myself, I don't want my iPad to become a laptop or my new Mac to have a touch screen - their benefits lie in their particular individual strengths when combined in a set up of multiple devices, hence software parity isn't the best outcome in all cases.
Thanks for all the insight. I agree that complete functional parity between a Mac and iPad isn't really worth striving for, as they each serve different roles. As it relates to the OP question, I still feel that from a developer perspective feature parity on a per-app/plugin level makes sense. It's not always easy to gauge how end users feel about that, outside of OP's more objective issues like missing features with no prior warning, so this conversation is really helpful!