But there are plenty of apps that don't have audiocopy or pasteboard, and I'd really like to understand why as it is probably one of the most asked for features for any app.
I think it would really help me and other users to understand some of the reasons why it is problematic or unworkable, or indeed whatever other reasons developers have for not implementing it.
This isn't an attempt at pointing a finger at developers who haven't implemented it or don't see it as a priority, but it is a way of bringing the issue out so we can have a proper debate about it (without any animosity) in order to understand the issues on both sides, the pros and cons and hopefully get a clear picture at the end of it.
12 comments:
When you develop a cheap app for masses, well.. 99% of them don't need it. So it doesnt influence your revenue unless you are targeting at pro users (hence the price point must be high).
I'm not a dev, and personally I don't care much for Audiocopy or Pasteboard. I see them as a temporary method until Apple implements something better in IOS (or until they let us use the filesystem or the clipboard).
Audiocopy and Pasteboard might feel necessary now, but there's no way to know if those methods will still work in 1 or 2 years, just like CoreMIDI made obsolete every other MIDI solutions on IOS, or when Apple locked the access to the DCIM folder making ioLibrary obsolete instantly (does anyone remembers ioLibrary?).
Just the fact that there is more than one method, and that some apps will support one method exclusively and some the other, shows how weak the system is and how important it is for IOS to support this kind of operations.
I have been wondering this very thing especially when it comes to some of the larger developers like KORG. I just have a feeling we won't see any audio copy/paste with KORG and I have wondered if its because its a 3rd party system and not something developed by Apple. Personally I think the KORG apps. (iElectribe especially) need more methods of getting audio places other than the flawed iTunes File Sharing. I think unfortunately johnnyg0 is on to something... and I remember ioLibrary.
If you can already save the audio to the iTunes folder or attach it to email, it is very easy to implement copy/paste. As with most everything on iOS, building a nice interface for it will take longer than the feature itself. The technical part though is simple with the sample code available.
Some large companies may shy away from it because, as others have said, the two current solutions involve relying on other companies standard/implementation (Intua and Sonoma). One of those (Sonoma) also requires signing some contracts/licenses, I think. Big companies avoid that sort of thing.
I'm guessing/hoping iOS 5 will include an Apple approved way of accomplishing this, which is why GB doesn't have it. That might just be wishful thinking on my part.
I hesitated to implement copy & paste in nanoloop because i thought both solutions were proprietary standards.
But that's not the case, audio pasteboard is actually a function of iOS. The only thing Intua added is the idea to concatenate multiple clipboard items if the data to copy exceed the maximum size for one pasteboard item - which is the most obvious and straigthtforward thing to do and hardly a new "standard".
I recommend every developer to read Intua's pasteboard documentation. It's a nice description on how to use the audio pasteboard in iOS.
I just figured out that I can email from GarageBand to myself, open that attachment in an app with copy/paste :-)
jeremywentworth.com: Are you saying you emailed an m4a to yourself from GB, then opened the attachment in another music app?
I will implement a form of Sonoma copy and paste into SynthTronica. However, I am frustrated by their SDK in three particular ways:
1. While they have established a kind of standard, Sonoma is not an official Apple pasteboard API. Yes this is Apple's fault, they perpetuate a leadership vacuum, but Sonoma can't help it's 3rd party and imminently replaceable status. I haven't implemented Sonoma yet as I waited to see what Garage Band's audio sharing capabilities were. Now that I know that Garage Band merely supports tethered iTunes and email I will move reluctantly forward with Sonoma.
2. Sonoma pasteboard audio representations are limited to 16-bit PCM. While I understand the need to keep the API simple, they chose a non-native lower resolution format. The iPad's audio interface is 24-bit PCM native. There are many audio applications were the extra resolution of 24-bit PCM is crucial. Some may argue that memory is a concern; the new iPad 2 has 512 mb of ram and the growth will continue in new device launches. But the Sonoma API will remain the same. I disagree with Sonoma's choice here.
3. Sonoma/Retronyms will not list an application as being API compliant unless the application implements extraneous features which are quite separate from the pasteboard mechanism. They make user interface demands upon applications to show other applications which support the SDK. One can argue that this is coercive advertising, but my main issue is the clutter and inelegance of the demand.
I view Sonoma copy and paste as a temporary solution. If Apple decides to implement an audio pasteboard standard of their own, which I am fairly confident will happen sooner rather than later, Sonoma copy/paste will remain available in my applications for a short grace period.
Another tip to those interested in receiving copy and paste in their applications. If you write reviews on the AppStore that say "this is worthless without copy/paste" and leave a 1 star review (even 4 star reviews that say "add copy and paste and it is a 5 star app" are annoying) you simply piss off the developer. Developers take on a lot of extra work to support all of the recording and exporting that goes on in audio apps, and you get the result for a ludicrously low price compared with conventional audio software. Displaying a little less obnoxious entitlement is key if you want developers to connect with you as a community.
1. It's not a standard by apple, it may be based on one but it's just not a standard. Once Apple comes along with a better solution your app is stuck with continueing to support Audiocopy because your users are used to it.
2. Some apps don't want to change their UI just to implement something like this.
3. It IS coercive advertising.
4. It's controlled by a third company other than apple and so there are additional licenses to adhere to.
5. It's hard to monetize the development effort.
as a dev i've hesitated implementing copy/paste for some simple reasons.
1. there isn't a standard.
2. i personally don't like Sonoma's solution for the same reasons as waffletower.
3. intua's solution (basically using UIPasteBoard) is promising but not many apps are doing it.
4. current solutions don't solve a big issue of file/data type conversions.
5. investing any large amounts of time for a feature must have some guarantee that it will not become obsolete.
for now, my current solution for saving recordings is to use file sharing, which is very easy to implement.
waffletower: wow, you are so right. that really needs to be hammered in to people as they think about the fact that they want everything to cost $5. The "Go For Volume" mentality means that you may end up dealing with a wider audience than is healthy for the project.
when i was working on mugician, I designed it as a real-time performance app and brushed aside all non-essentials such as audio-recording as a wait-and-see feature that hopefully eventually just works with common DAWs. But I got enough of that rude sort of prodding that I actively scare off people that would create more costs in maintenance headaches than they would actually pay for an app. (I love my userbase that stuck around, btw.)
as a related example, there are some MIDI apps I know of that could have been released months ago, but have not been released because of this phenomenon. You don't want to spend all of your margins on teaching people how to deal with integration problems, and dealing with people that will give you more than the cost of the app back in grief to you.
total self-containment is wonderful for killing off complexity and minimizing your potential bug surface area. it makes development FUN, and lets you focus on what matters. the moment you talk to anything outside of the very binary you tested, such as a DAW or a MIDI device, you may find that you under-priced your app due to support headaches.
if i'm going to implement copy/paste, midi, or any of this integration stuff, then it better make a huge difference in sales or not come with huge amounts of coding or support hassles. ;-)
Post a Comment