Indeed this is shocking news, but we had to remove the ioLibrary functionality from all our apps. (Intua will remove it from Beatmaker as well.)
This has been carried out due to Apple's request ("apps are not allowed to look out of their container").
ioLibrary has been functioning for over a year and suddenly some people decided that it is against Apple's policies.
So currently you can use the wi-fi server, etc. but only for each app on it's own.
We are really eager to find another file sharing solution but it currently seems to be impossible (DCIM was the only way and buffercopying isn't good enough for our purposes).
We will keep you posted. Meanwhile, soon we'l release the long-awaited Touch DJ update, as well as a new groundbreaking music instrument app. Future plans include Star Guitar 2 & Star Piano 2 (completely reworked).
I guess we all thought it would come at some point, but now we know it is for real.
ioLibrary is coming to an end!
11 comments:
It really bugs me how Amidio can be so innovative and develop such a helpful feature like ioLibrary, that I use all the time, and then Apple plays a game like this... :(
Lets not be negative now. Let us look forward to audio copy/paste, which is hopefully going to be implemented but better still, approved. Apple have their reasons for taking this action (I seem to remember that it was something to do with protecting privacy of others when making phone calls). We need to respect their decision.
This is awful news. It's things like this that make me think Android is the mobile OS to be supporting.
Apple acts like a dictator toward third party developers, allowing them to pay for the privilege to develop applications for iPhone OS -- applications that Apple benefits from. It's ridiculous and predatory.
By contrast, Android is far more open, and something like this would never be an issue with Android. Google doesn't give Android developers a box and say "don't go outside of this box or we'll spank you."
I know Android needs some polishing up, especially in the area of high quality audio support, but Google's working on it, and there are a bunch of new Android devices coming out this year.
I hope Android grows and improves this year, because I can't continue to support Apple, considering the way it treats developers and users.
What really needs to happen is for Apple to allow us developers unrestricted access to the users iTunes library. That would solve all problems, eliminate the need for the dreaded Wifi server nonsense, allow all music apps to share a common library, etc.
A petition similar to the one that helped Amidio get Touch DJ temporarily approved would probably help Apple wake up.
--pwnified (developer of MultiTrack)
This is sad news for all users and developers. I agree with pwnified. We should all try to sign a petition! I hope you can help us palm sounds
Perhaps Apple is afraid of making music piracy easier if the iTunes access is opened on the phone. Or maybe they even have a contractual limitations with music rights holders? Anyway, it should be made known to Apple that some kind of folder for sharing music between apps is really required, like there already is for Photos.
Perhaps Apple wants to have this functionality limited to the new Apple Tablet they are announcing next week. Just a thought...
I don't think iTunes library access will happen (due to DRM issues). What would solve the problem without causing too many issues for apple, would probably be to just provide a single 'public' folder that all apps can access safely. Ideally this folder would be accessble from people's computers too (for storing documents, etc).
I want to chime in that I am really sad to hear this too. I have been really loving the Amidio apps that have this feature.
Anonymous mentions audio copy/paste. This is already implemented by at least one company I know of, Sonoma Wireworks. Of course it only seems to work between their own apps right now. But it does work. For how long I wonder?
We need to make our voices heard by Apple. Lets start writing them!
I can't think of a reason why Apple doesn't allow iTunes library readonly access to unencrypted media (m4a files). The same way you have access to them on your computer, or an application on your computer has access to them. DRM is not an issue because m4p files are still encrypted.
As far as write-access, well that capability might allow an app to become something that competes with iTunes (download song from URL, store it in library). But Apple could just fail an app that does that.
Apple themselves do not modify the iTunes library on the device itself, the built-in voice memos app has a custom syncing mechanism just for it. Developers should at least be able to write to the voice memos folder, to allow syncing tracks back to the computer with USB.
The shared folder thing has been tried before (this is what ioLibrary actually is, it uses the DCIM directory used for images). But I agree, a shared, syncable folder for audio media is a good idea, and I'd love to hear the real reason why it's off limits.
There are a lot of misunderstandings surrounding the issue of inter-app audio data sharing on the iPhone. I will, however, only focus on the issues relevant to moving forward.
First of all from the perspective of the iPhone user experience as Apple has designed it there are NO FILES on the iPhone. In Apple's iPhone apps you never see files. (The two exceptions I'm aware of are email attachments and Apple's iDisk app.) Apple considers files as a fiddly detail that should not be exposed to users in the interface. I would not expect Apple to backtrack on this issue.
Apple does have technology in the iPhone OS called UIPasteboard that is a general method to allow different applications to share data. The copy and paste mechanism on the iPhone uses UIPasteboard. UIPasteboard supports named collections of data. It supports persistent data that will stick around between application launches and even between reboots of your device. UIPasteboard provides, for all intents and purposes, a shared file system, but it doesn't expose it to apps as a file system. It exposes it as a simple database.
One common misconception about UIPasteboard is that like command-C copy and command-V paste on the Mac OS it only supports a single piece of data. And the next time you copy something the previous piece of data is replaced. UIPasteboard is much more versatile and has the ability to support multiple pieces and collections of different kinds of data simultaneously.
If you want to see a good example of the versatility of UIPasteboard check out the app Pastebot and its corresponding Mac software Pastebot Sync. Pastebot is a pasteboard management app that also allows you to share text and image pasteboard data between the Mac and iPhone over Wifi.
Another example of the use of UIPasteboard to transfer data between apps is Sonoma Wireworks Audio Copy Paste system.
Now there are currently some problems with the implementation of UIPasteboard in iPhone OS 3.1.2. First is a lack of standardization of data formats. Text and image formats are well defined. That's how Pastebot works. But when it came to defining audio data formats Apple didn't finish the job. Apple declares the names of a handful of audio data formats including basic audio (presumably 16-bit PCM data like a WAV), MP3 and AAC. But the specific details of these data formats as they would exist on the pasteboard are not defined. Secondly, there are reports of problems supporting very large audio samples on some older devices.
But the first problem can be solved by a mutually agreed on definition of an audio sample collection data format and definitions of the actual audio data. Mutual agreement or standardization is key. There's little point in putting audio data in a pasteboard if other apps don't know how to read it.
The second issue is a bug and will hopefully be addressed by Apple in an OS update. (It's been a long time since we've seen any iPhone OS updates.)
Post a Comment