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.
Fireside chat: The state of iOS music
Like a lot of people on this board, lately I’ve been experiencing a lot of frustrations with iOS music (no I have not upgraded to iOS 8, I’m still waiting). After thinking about things I've concluded that some of these issues are not related specifically to iOS 8. Rather, they are big picture issues about iOS music that I have not been seen discussed or addressed in one place. My goal in starting this thread is to get perspectives on the following issues, and hopefully responses from developers.
I’m not looking to start a flame war, troll anyone or stir the pot. Start another thread for that. What I’m looking for are honest answers from developers and well-articulated thoughts from app users about the following issues. Thanks in advance for respecting that.
First, Apple’s breakneak iOS upgrade cycle seems to be causing a lot of problems. It seems that every other version of iOS (not all new versions) cause major problems for audio apps. I am not a coder and I am not a programmer so I don’t understand WHY new version of iOS keep breaking apps. I’d love if someone could explain it or shed some light on the issue. Is Apple changing things so fundamentally from version to version of iOS that app developers are caught out having to rewrite large portions of code? I know I’ve read on this board that Apple sends out early versions so that developers can begin to “catch” up, and in fact, prior to iOS 8 being released several iOS music app developers had iOS 8 versions ready to go. What’s going on that causes these massive problems? I’ve never experienced something like this on the OS X side with music software (DAWs, VSTs, AUs, etc.). If the iOS platform is so unstable after 8 (!) iterations, that doesn't seem to bode well.
Second, and I think this issue is the one that cuts the deepest and hurts the most: the lack of standardization regarding what IAA integration means is making iOS music incredibly frustrating. If I may be so bold, and I know I’m going to catch heat for the following, but the basic Audiobus IAA framework has not helped – it’s only confused things. It seems like the IAA label is being slapped on every app now even if the IAA support provided is almost non-existent. The IAA transport panel is essential. Further, without the “fast” switch icon using an app as IAA is LESS convenient than Audiobus because changing apps requires double-clicking the home screen button, rather than simply touching an icon. Even given this significant difference in the user experience, developers often claim that an app supports IAA but are not clear or explicit about what kind of IAA support is provided. Will it have transport? Will it have icon switching? Will it send and receive MIDI when it’s hosted? Who knows.
I suspect that the lack of documentation for the IAA protocol is what’s causing a lot of these problems. And frankly, that’s bullshit. It’s completely unacceptable that a company like Apple half-ass something like IAA. Developers are professionals and should be treated as such. Further, there is no way that Apple could NOT have anticipated that musicians would gravitate to the iOS platform. I know it’s probably not a high priority for them, but now that the company is using iOS music apps in advertisements to sell iOS products Apple needs to get its house in order on that front.
In any case, maybe it’s possible for some developers to band together and create a kind of “seal” of approval that guarantees that an app has full/proper IAA implementation (transport, MIDI, etc.). Or perhaps developers could just be up front about what IAA features are/are not included so that users don’t have to guess. I’ve had to create tables that index my audio apps because support is so erratic. Having to spend time figuring out which apps work with what, fiddling with connecting them up, is a creative killer.
Third, I don’t understand why some developers are re-inventing the wheel on some things. Stated another way, well-known developers seem to be leaving out “standard” features that, in my view, are absolute no brainers. I’m sorry to use specific examples, but I think it will help illustrate my point.
It is mind-blowing to me that so many synthesizer apps do not have MIDI out. The Virsyn synth apps are flat out excellent and have solid built-in keyboards. But, if I’m working in Cubasis, I can’t load up Addictive synth as an IAA, play some keys in the app, and have the MIDI be recorded in Cubasis. I’m actually stunned at how few apps can do this (off the top of my head iSem and ThumbJam can, and it’s lovely). Thor, which probably has the best built-in keyboard of any synth app also has no MIDI out – why? Do developers really not expect users to want to perform using the built-in keyboard and record that performance as MIDI, not just audio? Is it really so much additional work to add MIDI Out? Why implement one but not the other? Is it possible that developers just don't know what common usage scenarios are?
Fourth, sometimes it seems like developers are releasing apps without bothering to test them in common usage scenarios. Yes, I’m aware that there are MANY different app combinations, but there are only a few basic workflows on iOS – you either record the audio to an external source; stream the audio internally to another app; or record/bounce the audio within the app and then export it (via copy paste, open in, etc.).
CsSpectral is a recent example of this issue. The app is a disaster as IAA and in Audiobus, but seems to work ok stand alone. Did no one test the app in either of those usage scenarios before it was released? I find that so hard to believe, but I’m not a developer, so I have no idea.
Finally, what in the hell is going on with the app approval process? Are other types of apps suffering the same delays? Have developers been provided with an explanation for the new extended times for approval?
As a precautionary measure, I have returned to my bunker to await any responses...
M
Comments
I will probably chime in further on this, but I have to disagree with the sentiment here and elsewhere about CsSpectral. I've used it plenty as IAA and have not had issues. I'd consider the term "disaster" to be pretty major hyperbole.
@CalCutta said:
Fair enough. I'd love to know what you're using it with, etc.
I think this brings up another challenge developers are facing: different experiences by different users, even when they're on the same version of iOS. I can't imagine how hard that makes tracking bugs, etc.
Wow, there's a lot there, so I'll keep my initial response short. But I agree with a LOT of what you said. Most of it just simmers in my mind, somewhere below the level of "active annoyance", but some of the broader issues are of great concern.
Let's start with a positive note, at least from my perspective: I put very little of the "blame", "responsibility", or whatever term you want to place on it on the developers of these apps. The developers, as much as the musicians, ARE "iOS music". We all have our favorites, but even some of the "mediocre" stuff out there is still pretty damn cool, usually very affordable, and represents someone's passion for creating music.
And while Apple may deserve some (more?) criticism, the only reason there IS something called AudioBus and "iOS Music" is because we have this Apple ecosystem where we have enough similar devices that people own and use to support development and sales of these apps.
But, in particular, before I chime out, I was really alarmed by how many of the apps already installed on my devices (one of which is still iOS7 and one was iOS8) were effectively "bricked" by the introduction of a new operating system that, frankly, doesn't function that differently than the old one from a consumer perspective. Obviously, things are going on with programming that cause problems.
And it's also alarming to see the escalation of operating systems, where apps that previously worked as far back as iOS5, suddenly require 7 or even 8 to function. When people in these parts say that there's a reason these apps generally cost $20 or less, as compared to desktop "versions" costing hundreds of dollars, this is one of the reasons: there's a lot of risk here.
@StormJH1: "When people in these parts say that there's a reason these apps generally cost $20 or less, as compared to desktop "versions" costing hundreds of dollars, this is one of the reasons: there's a lot of risk here."
Good point.
@StormJH1 said:
Lol, yah -- I'm guessing the length of my post will put people off, but that's ok. I'd rather discuss with people that are willing to take the time
As I understand it any App that wants to use the current version of Audiobus HAS to use a minimum of IOS7. and HAS to become an IAA generator.
I might be wrong but again my feeling is that what got Bricked by IOS8 was Audiobus, with consequent knock on effects for all the apps that have incorporated it.
I still have an Ipad 1 and all the apps that worked on IOS5 still work at that level of functionality of course they don't have IAA or Audiobus but they still work and I can re-download IOS5 versions of Apps to run on it.
As for midi out on synths it would be nice to have maybe but how many daws could actually make any use of it? My work flow is to conect the daw to the synth by midi and audiobus or by IAA and use the keys in the daw or an external keyboard.
There have been various attempts at developing a "Gold Standard" Open Music App Collaboration being an obvious one and the midibus SDK as another. And of course the one that we expect all devs to adhere to namely Audiobus.
however with the exception of Audiobus none of them ever really gained traction
@papertiger said:
I take care to use it with some (but not a ton) of automation going and not running other apps in the background. I wouldn't dare use it in a live setting or expect it to run really smoothly with a lot of other resources in use.
I personally try to remind myself often of the current differences in power and capabilities between an iDevice and a laptop/desktop. I like using iDevices because of the interactive nature. I also see a bright future as tablet technology is nowhere near a plateau.
I think your second paragraph here is critical, and why I get disheartened at some of the negativity I've seen regarding the iOS upgrade and app issues. I've seen some posts here that come with an air of objectivity which I think is misguided. There is nearly no objectivity to this stuff. That objectivity will usually lead to finger-pointing and judgments which I also think are misguided.
In the end, I think it's still a very early state for iOS music. No other company has even brought serious competition to Apple yet as far as a good tablet for musicians. I enjoy being on (what I still see as) the ground floor of an era which I think is going to eventually rule the production landscape...
I think a short illustration of what I'm talking about can be illustrated by how things work with VST or music programs on PC. If I bought a VST to use with my DAW on Windows XP, and then either upgrade or buy a whole new computer with the newest version of Windows, things still generally work.
Heck, I have a free version of Propellerhead's Rebirth software from their website - I think that was originally used on Windows 98(?). I can run it on my 2010-ish PC with Windows 7 - it has a boot disc they provided, but it works.
All of us here could probably fire off a list of apps that simply did not work after going to iOS8. Many of these were quickly addressed by the developers, which is great on them. I guess I just don't understand why a "new and better" operating system doesn't necessarily have backwards compatibility with programs designed to function on an older version of it.
@BiancaNeve said:
To clarify this point, if the app uses the latest Audiobus SDK >= 2.1 then it will only work with Audiobus on >= iOS7. This does not mean the app itself can't be used on iOS versions prior to iOS7, it is just that you can't use it with Audiobus anymore on those devices. The AB guys recommend that app developers set their minimum required iOS version settings to iOS7. However, doing so effectively locks out people who keep older iOS versions on their devices from getting any of the app's new features. This tradeoff was not something I was willing to do with my apps, but the result is that people on iOS 5/6 can't use the latest TJ with AB anymore.
I'll comment on the rest of the this thread's subject matter a bit later after it grows....
@sonosaurus said:
I'm very interested in what you'll say, so thanks in advance for taking the time.
Thor does do midi out....into cubasis....
from the Thor keyboard )
@commonstookie said:
Can you post precise steps on how you got MIDI out from Thor into Cubasis working?
Who's said anything in this thread about apps being cheap so noone has a right to complain? As well, no one here has said that people don't have the right to complain at all...
edit: To answer your question, frankly no I don't think it's that expensive when all's said and done. I also don't think it's fair to add up the price of all your apps and then blame a single developer or Audiobus when an update comes out beyond their control and there's corresponding technical difficulties.
Wow, there's a lot there, so I'll keep my initial response focused on one part.
An actual iOS developer could answer this better but I'll try to put what I understand of it into English.
From a programming point of view, consider the OS a set of services. Services are accessed from APIs (application programming interfaces). An app developer doesn't, for instance, need to write the machine code that connects their tone generator app to the sound chip that connects to the headphone out. Instead, the OS provides an API called something like 'soundOutToHeadphoneJack' and the developer points their tone generator at it. And hurray, we have headphone out!
iOS provides thousands of these APIs. Tens of thousands. Everything from core audio and core midi to UI stuff, touch interactions, 'open in' type interapp stuff, networking, file storage, memory management, screen orientation, gyroscope, camera, icloud, IAP, security, text input... You can probably imagine from there that each of these sort of larger chunks/broad strokes of OS functionality are made up of hundreds or thousands of individual API endpoints.
When a new OS comes out, sometimes some of those APIs change. Sometimes drastically. I couldn't say why but let's give apple the benefit of the doubt here and assume they're not changing API endpoints in order to piss all of their users off. Best case scenario would be 'hey, the method you call to send audio to the headphone port has a new name'. Find and replace, bit of testing, off we go! But what if the type of data the API is looking for changes? It used to want fixed sized packets of audio sent at a particular rate and you've architected some portion of your app around those expectations but now it wants the audio to be streamed but it has to go through some other subsystem first. That could be a big deal and we're just talking about getting a sine wave out of the headphone socket.
That is really all to say, Apple does not need to 'change things so fundamentally from version to version' to cause pain for developers. Even small change could reak havoc on some people's apps. Mind, back to giving the benefit of the doubt, while any API changes can cause a headache for an existing app most API changes happen to make developer's lives easier (easier=more+better apps=more app store sales=platform looks more appealing compared to android=more platform lock in=more device sales). Perhaps the soundOutToHeadphoneJack method changed as part of a larger effort to make moving audio around easier on developers. Progress, pain, all of that action. Sometimes, it does seem like they are straight up developer hostile as was (is?) the case with IAA details but keeping developers happy is key to their strategy.
So, I'm Jane Devo and I update my soundOutToHeadphoneJack related stuff to work with the new OS/APIs. Tested. Working. Hurray! No, wait, shit: The last version of the OS, which lots of my users rely on, still needs me to do it the old way. What do I do now? I can fork my code (either two separate code bases or a crap stream of if iosA do blah else if iosB do blahblah), get another device to test on, compile any feature updates or bug fixes for both target platforms each and every time or... just shoot myself in the face. As surfaced my @rhism and plenty of other developers, I'm looking at a lot of overhead and work for a minimum wage job, if I'm lucky. Or let the old OS go and hear about it in the App store.
Well, first, see minimum wage job above.
But also, while they do make beta versions of the OS available they don't send out the 'golden master' until at most a few weeks before launch. So you're testing against a beta version of the OS with bugs and potential API changes still out there. Smashingly unawesome. Plus, it's summer when they release it! Bet we see a lot more devs updating more quickly if they released it in February but that will not happen since they have tied the release schedule to the phone release schedule which is fall. John Gruber and Guy English yack about this for a while here, starting at about 15 minutes http://daringfireball.net/thetalkshow/2014/10/10/ep-097. Drops off and picks up again around 34 minutes.
I think that we saw a clutch of 'iOS 8 Ready' versions of apps released before the update came out says everything about how on it the AudioBus team is. Not to take anything away from that but to put it into context: I don't get the impression that AB is a minimum wage job. Also, I think they take very seriously that a lot of developers are counting on them to come through. And they did.
Speaking of jobs... I swore this was going to be short when I started!
Long posts are good! Some concepts require more depth than "tweet" level can provide.
Cracking opening post with some great points. My nervousness around iOS has grown considerably over the last six weeks with iOS 8. I spent about six months debating whether to invest in a new studio PC or take a gamble on an iPad. I only got an iPad to produce music. In July I bit the bullet and duly headed over to the local apple store and parted with the thick end of 600 quid. I haven't dared work out how much this lot owes me now I have been buying apps. I saw this as a long term investment.
I know the tech moves on, but my rationale was to build a system that was stable and did a job. Eventually I will end up with a dock and I would expect to then just integrate the pad into my hw and replace the pad with a newer version for the mobile side of things. I tend to drag as much value as I can from things. My studio PC is eight years old, runs XP and drives my hw synths just fine. I expect a similar working life from the iPad.
I still think iOS music has tremendous advantages and I think it will continue to evolve in a positive direction, in spite of some key challenges. Apple have a closed system. In evolutionary terms, that is never wise. iOS architecture clearly had an early advantage for music and hence it quickly became the platform of choice for pro/semi pro/serious hobbiest production. Make no mistake, Android will close that gap in the not too distant future. At that point, we will see if iOS remains competitive in the mobile/touch interface music production market.
A lot of this will depend on Apple. They are clearly smart and the App Store model is extremely savvy from their perspective. I notice with your Apple account you can't pull up a summary of your spend on apps. Simple function that could be added. But apps are coffee and donught prices. If we could quickly see how much those impulse buys are costing we may become more discerning and disciplined. I suspect Apple are smart enough to have thought that through for themselves.
If Apple don't factor the impact of their technology development strategy on niche and specialist applications and their users then further development will find the path of least resistance, which I predict is likely to be Android. A more open system, hardware can be developed by any manufacturer, the OS is designed to be compatible with technology from different manufacturers. Long term, I predict we will see Andriod OS specific hardware being developed by the big names in music hw. Eg, a Korg tablet, pre loaded with Gadget, iMS, iP6 etc and all integrated seamlessly. Parnership deal with Steinberg providing a studio interface and DAW as part of the base operating system. Perhaps, perhaps not... But I can't see that sort of development within the Appleshpere unless they rethink their long term development strategy.
With regard to devs, all credit to them all. They have provided us with some serious tools and are forced to operate within the constraints of the coffee and doghnut price point. I did this stuff at uni and have seriously contemplated brushing up on my SDKs and coding skills and ditching the day job to give development a go... But the constant updating that would be required to keep an app meeting the markets demands... Not sure if that's for me (interested in a devs perspective on this side of their business)
But ultimately, the future of iOS music is down to us. If we keep using the system and the devs keep improving the tools then the future is bright. On the other hand, if the platform becomes unworkable, the pro/semi pro/serious hobbiest will migrate to where the tech is the most transparent.
open cubasis
select audio track
tap routing,select inter app
select Thor
add midi track
goto media>instrument
select no instrument
goto routing panel
select midi out > Thor keyboard
important bit...
chose 2 bar count in.
midi track will already be armed.
do not select Thor icon to jump to Thor.this will also arm the audio track
and record both audio and midi.
press record
use the home button to close cubasis window.open Thor>play
works for me
you don't need to touch any of the settings in Thor
@commonstookie said:
I appreciate you taking the time to do write this out. I will try it after work. That being said, does this approach not seem convoluted to you? I don't know that I would remember not to use the Thor icon to jump to Thor.
np
Id like all the apps to use the yonac model
for their transport bar...doesn't get in the way..
but for now i don't mind the odd quirk.
I luv my iPad and the apps I use.
to date I've not used it with a controller.
it's been touch screen all the way. )
Part of the issue here is that iOS and the devices it runs on are seen much like appliances, like a toaster. Simple, stable, turn on, turn off. This sets high expectations of stability. The stuff we do on iOS is far from representative of what the vast majority do on iOS. If you stick to surfing the web, email, reading a book, playing games, and looking at photos, most likely iOS 8 devices will be very satisfactory at this point in time. Music production on iOS, however, isn't like a toaster.
On OSX and Win, I, for one, ponder OS and app upgrades over time and am patient about the process. If one carries over this patience to iOS, one will have little trouble. If, on the other hand, one is anxious to have the latest whatever, then one has to assume the risk. I think Sebastian has posted here quite a number of times that if you consider iOS music production important and need stability, stay on iOS 7 until the dust truly settles.
^ Very well put
Agreed @miguelmarcos - but then there is the issue of app updates on 7.1.2. While the issue of getting the latest, greatest feature set may be a driver for some, it isn't for everyone. And, planning for iOS 8 by updating apps on iOS 7.1.2 was - in my mind and many others' - thought to be safe. It appears it isn't. The problem that then seems to have compounded the situation is that in some circumstances, even reverting to older app versions pre SDK 2.1 update is appearing to not be stable. I and others have done that, and, while successful in some cases is proving not stable in others.
So, 7.1.2 isn't behaving like many thought it would - even while we are still patiently waiting for the dust to settle and all our staple apps - plenty yet not ready - to be updated for 8.
The question was asked around the 23rd of June (and I'd quote it but I can't find the question and answer just at the moment) whether apps that were ready for 8 by updating to the 2.1 SDK would continune to work OK on 7.1.2. The indication was given that that should be the case. But it isn't...
How are we to understand that?
@musicinclusive I think it would be much more helpful if you gave examples of the apps you're talking about.
@MusicInclusive
When you ask how are we to understand the problems you describe, it is a good point and is the source of my unease about the longevity of my investment. However, I honestly believe that both users and devs have been caught out here. There was clearly a lot of effort from a lot of people to get ready. Not all devs were at the forefront, but the majority of the community has clearly made an effort. The problems are disappointing, but not wholly foreseeable.
For me on the serious hobbiest side they are frustrating. I work long hours and my music time is a precious commodity that I squeeze into what gaps I can between work and family. But fundamentally, I don't rely on it to put bread on the table. My workflow stress because I can't hook a synth/DAW combination up is clearly a first world problem for me. The sort of problems we get when the basics are covered and we have the luxury of some free time and a modest slice of disposable income.
However, some people (and IIRC this applies to you) have gambled on iOS as a part of a bread-winning set-up. And that is where the events of the last few weeks will determine the future of the platform. People like me aspire to make a living from this stuff. If the people who do make a living from music turn away, we will be influenced and confidence in the platform will diminish.
But who is ultimately responsible? Until recently I wouldn't have expected Apple to take much notice. But as has been pointed out above, they are using developments in iOS music to attract customers. They are now saying to the world, "the pros are buying into this platform". In my mind that puts an obligation on Apple to ensure the needs of the pros are maintained. Hopefully recent events will filter up the chain to the Apple execs and they might take notice of the impact this update is having... We shall see.
@xen said:
Your situation sounds like where I am headed -- starting a family -- and I know time will be precious. That's why I want desperately for iOS music stuff to work as well as it can. Since I have the iPad with me on my commute, on the couch, etc. it's a lot more handy than using a laptop or a piece of hardware like an MPC or Octatrack.
More and more I'm thinking that I need to just get over it and cull my music apps down to a few that work well and consistently, awesomeness of those apps that don't be damned...
And by the way, thanks to everyone that's participating. I'm happy we've got a good discussion going!
@CalCutta - since I've done that extensively elsewhere - here I'm just participating in a fireside chat asking general questions of all thoughtfully. This chat is not the place for those details.
Great thread! For as much as all of this is a bummer, I think its unfair to accuse anyone of incompetence, or act as if absolutely nothing is working properly. For as upsetting as it is to have a business or performance that relies on these apps working properly, it's not just your livelihood at stake. I'm sure the developers who are being accused of such incompetence have even more at stake in this platform than their users, and would like to see this resolved just as soon as anyone else.
@papertiger said:
This.
Yeah, don't like the iOS upgrade cycle either. Seems to be a stumbling block every year. They need to sort that out so that the transition is smoother and without a hitch.
I'm sticking with Gadget for now. No IAA, no Audiobus, no AudioCopyPaste, no MIDI. Why? Because it's a lot easier. Am I missing out? Yeah, but as an Ableton Live user I can always just dump my Gadget project into Live and not deal with the hassles. Yes it's true, the hassles aren't always that big of a deal, but at the same time not having to think about whether something will work or not is liberating.
Seems to me that iOS music is still sort of "in the process of". That is to say it's still taking shape. I suspect once it becomes more clear what the "standards" are developers will follow suit.
There are sloppy coders out there, not just in iOS music or even iOS, so it goes without saying there will be sloppy apps. Best to kind of sit back and let them fall by the wayside, rather than serve as a tester for them.
With regard to API changes, the OS should provide old and new variants of the function call, along with documentation alerting developers that the old version will be deprecated within a few updates. That means that old versions of apps still work with the new OS and gives developers time to plan their updates so as to cause the minimum of disruption to their customers. The current situation makes a mockery of Apple's line that they disallow apps that use unpublished API calls because they may change those functions at any time. The reality seems to be that they will happily change ANY API function call at any time...
So, hmmmm. Adding MIDI to my MonoPoly (if I had one) - somehow mysteriously broke polyphony. Is that Korg's fault? After all, Korg never designed it to have that add on. Is it the MIDI kit designer's fault? Maybe - hard to tell - it's worked on some MonoPoly's apparently - so say some folks. How about (I say tongue in cheek) Dave Smith? Probably not - but - who knows? Hard to tell.
But - someone is responsible here.
OK. Now, what should I do? Well, it doesn't work any more. Can't get answer from Korg. Can't get an answer from the MIDI kit designer. And Dave Smith is busy building Prophet 12's and Pro 2s. I know - I'll just cull down my synths. Throw this one out. That'll show them....
Never mind I use it integrally in my set for paying gigs. After all - I bought it second hand off ebay and at a fraction of the cost of what I would have paid for other synths. I should be thankful it's lasted me 3 gigs. Should not expect it to continue working. No no - get the shiny new stuff. Also - I've got too many synths already - I'll just throw out all the ones that don't work with the MIDI kit. Or.... maybe it's the MIDI kit's fault.... Huh. I wonder?
(Note: No real MonoPolys were harmed in the construction of this post - since I really don't have one...) - Oh - and no disrespect intended to Korg, MIDI Kits for the MonoPoly or Dave Smith :-)