Audiobus: Use your music apps together.
What is Audiobus? — Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.
Download on the App StoreAudiobus is the app that makes the rest of your setup better.
Managing sample folders between apps is a complete mess.
I have a nice sample library on cubasis 3, another in drambo, and another in audioshare (not completed but looking forward to it).
The results? A complete mess. when I'm in one of those apps and want to use a sample of another app library I cannot pre listen on an easy way all of the different samples and see which one is best if happens that the folder is in another app. Using finder as a side window is less than ok and duplicate the workflow..
So at the end I have to duplicate folders on different apps. Total mess and waste of hard drive space.
The question is: why not all of the apps can fish from the same pool library? Only one sample folder. Why?
It would be simple, effective... like on a desktop system.
Comments
The file system doesn’t duplicate the actual data so there is no waste of hard drive space.
Security.
Because we are not allowed to have nice things without some bastard trying to exploit it.
If apps are allowed to access other apps’ data (or a shared pool) then it will be exploited by malicious code.
If a desktop system was released as new today it would be even more locked down than iOS.
Desktop systems will get more and more sandboxed in the future too.
Because people.
In the meantime the workarounds are to make your own main sample folder in iCloud Drive Or AudioShare and organise it as if it were on desktop and make sure that everything Is there, and treat the samples in apps’ sandboxes as subsets.
Most apps have good files access now. Just don’t worry about duplicates.
Sand boxing and security is here to stay.
I have an iPad Mini 2, so on iOS 12. Samples are kept in AudioShare and I use slide over for previewing.
On iOS 13 I believe Auditor can both preview in slide over and drag and drop.
Yes, you could ask the other developers and if they can’t figure it out maybe Andy, the developer of Auditor could share how he extended the file browser to have audio preview.
How come? You mean that having same folders on cubasis and on audioshare is not duplicated folders? Different libraries... they are in different places...
If theres a better way to manage them... I'd love to know. How can I manage the cubasis library if it is on audioshare?
Thanks in advance
When you duplicate a file in an APFS volume, the new file points to the storage of the original file. APFS can store the delta changes of a file to the new location so if you edit a sample, only the changes to the original need to be saved.
So you can use a drum loop sample originally stored in a folder in the “on your idevice” folder in multiple apps at the same time with the actual sample data only stored once. If you delete the original the file system automatically ensures that data integrity is maintained.
Maybe iOS 14 will shed a bit favor for sample users and file managing fans?
I think the parts are all there already. It's the app developers that need to use the built-in tools.
All apps that use samples should accept them via drag and drop. Even Drambo doesn't do this. And all apps that organize samples should let you drag those files out. AudioShare, for instance. Between that and APFS, we should probably be covered.
If you sold an app on Mac or Windows that didn't let you drag and drop from the Finder/Explorer, nobody would ever buy it.
I'm not sure that it worked. Now I have 16 GB of samplles on audioshare and 32 GB on cubasis. That's what iOs shows me.
I have to say that I copied the main folder on cubasis and translated to audioshare. Then (don't ask me why I did this) I duplicated it again on cubasis and erased the original.
On kymatica ab says that there is some shared data between 2 apps. But it shows 16 GB. ..? 🤨
This audio preview feature in Auditor is BRILLIANT! Yes, definitely hope other devs could introduce this kind of thing.
This is so confusing and frustrating.
I had my samples in a “samples” folder in my local drive under Files app.
Audio preview is not that fast with the files app so I imported that folder in AudioShare.
Now I have 2 “samples” folders one under local drive and one in AudioShare. According to you these are not physical duplicates?. They’re not taking twice the space?. (Symlinks?). They by lo means seem like completely independent instances.
I deleted the original “samples” folder and the one in Audioshre is intact. Is it now “the original”?. It’s hard to believe data is not duplicated. And I can’t stand duplicated data. I’m gonna stick to using AudioShare... I can access AudioShare from Files.app . I can’t access other folders from AudioShare unless I import them.
Maybe this would help...
iOS reports the storage each app uses. But, this is a virtual number, not necessarily an actual number. For instance, if you have the same 2gb of files in one app and another, the overall storage is 2gb. But when you look at the storage for each app it will say 2gb ... basically reporting the same storage twice.
The only way to test that out for sure is to look at the overall storage difference if you duplicate a large amount of storage, before and after, then also if you look at the overall before and after when you delete it. Somebody here did just that some time back and the numbers checked out. But I wouldn't say that was a comprehensive test.
The bottom line is 1) duplicated files don't generally mean duplicated physical storage, 2) you have no control over that allocation. and 3) there's nothing you can do about it. iOS isn't likely to ever change in this regard.
Frustrating. Confusing. Inefficient. Untidy. But that's just the way it is.
This isn’t true as far as icloud storage is concerned though right? I mean I get what you mean by duplicate files not actually duplicating the amount of data being stored on the ipad, but say you do this with files within the icloud folder—while I assume now that anything duplicated there isn’t using up more storage locally, is it making an extra copy on the icloud servers and using up more of the storage you are allocated on there?
Btw, in case I’m not clear, I mean duplicated files in the icloud folder that originated in the icloud folder in the first place.
I don't actually know. I would expect files in iCloud Drive to be duplicates. Good point.
It's possible that iCloud backup has the smarts to not duplicate files stored in more than one place though. All the information is there. I mean, even on Linux it's quite easy to back up file systems that have sim-linked files without making duplicate physical copies, and under the hood iOS is very Unix-like. Honestly I don't know what approach Apple takes.
Ok, I guess I can always check the overall icloud storage number from time to time. I’m actually happy just to hear about the local storage not using up extra space for each copy. Was pretty inconvenient going back and deleting copies of stuff to free up storage when I didn’t really need to.
@Vlad11
I completely agree, it is utter shite.
I can share an iCloud Drive folder with a friend so I should be able to do the same with an app..
...it should be that simple.
The problem here is that AudioShare dates from a time before Files and hasn’t been updated to support a public folder in the sense of Files. I’m stuck on iOS 12, if I weren’t I would try to replace AudioShare with Auditor which slide over file preview functionality on iOS 13+.
Common use scenario...
In the past I’ve tried to reorganize such libraries and copy all snares to a samples/snare folder, bd to samples/bd folder, all loops to a loop folder... just doesn’t work. It’s a lot of work and you end up with mismatching samples that are out of context....
It makes more sense to categorize using labels. So you can either browse to the said “sp1200” folder and build your kit, or search for labels “snare, distorted” and get results from multiple libraries. So you can look for a kit or a single instrument.
Files app has labels, although limited and sort of cumbersome.
AudioShare has no labels.
Files app is really slow to preview sounds, AudioShare is fast and you can do edits on the go.
I think a label-efficient approach would be really helpful. An app where you could easily manage labels, filter by multiple labels, apply labels to multiple samples at once, batch rename... ideally it should be Files app as it’s a system, universal and common place for other apps. But maybe another app could filter and manage labels (if Files had an api of sorts). Documents Readdle app can access Files, but no labels...
Using labels (taxonomy) efficiently it’d be a lot easier to organize samples without having to move or duplicate files and folders. Look at Logic X’s channel strip and instrument presets. It’s a great use of taxonomy (labels).
Ok, I just made a discovery that sucks...
1) Filtering by labels in Files.app does not seem to search in AudioShare folder. The labels are there In the actual file but strangely you get no results when searching or filtering.
2) so I copied the AudioShare/samples folder to my-iPad/samples , label filtering works for the local drive. BUT files are duplicated, they are taking up twice the space, as you can see by the “global space left in the files app”. @wim at least in this case ( from AudioShare to Files) copying the files actually produces 2 instances taking up space. I don’t know if that’s the case when copying in AudioShare but it should be the same.
Seems like if you want labels you can’t use AudioShare storage. Please correct me for I find this to be utter nonsense.
A very simplified, slightly broken analogy:
In a fictional library, all the books are on random shelves. You browse books by looking through filing cabinets that contain index cards which tell you the book title and where on the shelves to find the book. There are lots of filing cabinets, with different categories such as "Fiction" and "Autobiographies".
Say a Donald Trum autobiography is put on shelf 1, row 3, space 5. When you first put the book on the shelf the librarian writes out an index card with the title and location and puts it in the "Autobiographies" cabinet. They can also make another index card with the same title and location but put it into the "Fiction" cabinet as well. There is only 1 book but you can find it by browsing both the "Fiction" and "Autobiographies" cabinets.
So you give the librarian the card for the book you want and the librarian goes to shelf 1, etc. and lo and behold, there's the book.
If you throw away the card that was in the "Autobiographies" filing cabinet, the card in the "Fiction" box is still there and the book is still in the same place on the shelf.
Throw both cards away and the book is still on the shelf, but there is now a sticker on the book letting the librarian know that they can throw it away when they need space for a new book.
Obviously this analogy breaks down very quickly but the main concept is there; The book was never inside the "Autobiographies" filing cabinet, just an index card that tells the librarian where the original book was stored. You can have as many index cards with the location and title of the same book as you like. There is still just the one book.
That's what happens when you made the "samples" folder. The actual samples themselves were never actually in that folder, just data telling the file system exactly where to find the samples on the physical storage device. So when you duplicate it, the data doesn't need to be duplicated, the file system just makes new pointers in the new location telling the file system where the data is.
I think it's time for AudioShare to move away from using it's own storage provider extension at least when running on iOS13+
Currently I'm keeping all my samples and other files accessible thru Files.app without locking them in to a 3rd party storage providers. Sure some files are managed with other apps but they are still 'On My iPad' and not duplicated and stored in another storage provider on the same device.
AUM could for example export/record it's audio directly to it's own folder under Files.app and not rely too heavily on AudioShare. I mean AUM 'session files' are accessible thru Files.app so why not give it an option to save recordings there as well? (Same with it's FilePlayer, it could just use the Document Picker to pick a file...).
I'm not on beta for AUM nor AudioShare so I don't know what's cooking at all...
@klownshed yes, I know symlinks. Good analogy with the Trump library, although personally I would have put his card under “horror”.
I just upgraded to iOS 14, question remains. Why can you label a file under AudioShare storage but are not able to search by that label?.
think its filesystem restrictions / low level access denied for 3d party apps .. thats why we have workarounds like web transfer, ftp, and symlink apps like Audioshare, a wild guess is that indexing only covers native ipad storage and not 3d party apps
We give apps access to our camera, photo library and microphone so I don’t think apps having access to my sample library would be an issue....I think it’s something that will come in the future and will probably be implementable now should Apple devote the resources
Damn. I always assumed that AudioShare files did not take up duplicate space because it is a "file provider" but was assured by a forum member that they had tested and verified that they were not. It looks like it may be true that AudioShare files don't participate in the APFS file efficiency.
I wanted to put some caveats about that in my previous posts, but didn't want to overcomplicate them. There can be other instances where files storage is duplicated, such as when apps alter the files by adding tags to them, or when they copy them as "blobs" into an internal database.
How about this use case: I have an audio file in a certain folder. In my DAW, I use its “import audio file” function, which results in the original audio file being copied to a folder in the DAW’s folders.
The amount of data still hasn’t been doubled, correct? (Assuming the DAW didn’t add anything else to the file in the import process, though I guess maybe that’s not the best assumption to always make)
In theory.
But, if you imported it from AudioShare then it might be doubled. At this point I'm not sure.
Ok, got it. Don’t have AudioShare anyway, but hopefully the apps I do use aren’t doubling, as I’m happy that I (hopefully) don’t have to delete copies anymore, which I hated doing but had felt necessary to keep storage manageable. Glad this thread exists, as I wouldn’t have known otherwise and would’ve kept wasting time being as anal as I am.
@wim, I’m not sure either ☹️
I did notice a decrease in available space. But on a second test it didn’t seem like the amount added up. If the copied sample folder was 500mb the decrease in available space wasn’t 0.5gb. It was significantly less, I don’t know if symlinks take up space, but I’d say it’d think it’d be “anecdotical”. The “available space” reading doesn’t seem too reliable either. Files.app won’t tell you the size of a folder, either. I just gave up.
I’m copying GB’s of samples to the iPad drive. I’ll do the same test (copy to AudioShare ) and post the results here, see if we can make some sense out of it.
Ok. So it seems like you were right. AudioShare symlinks. Here’s what I did...
Had 88.41gb left of storage.
Opened AudioShare and imported a LOOP folder from my drive.
AudioShare DOES read size, it says the folder is 8GB which seems right.
Back in files there’s 88.35gb left of storage. That’s 50mb right?. Must be the symlinks (pointers) taking up bites tiny bit by tiny.
Actually now it’s saying 88.1gb of storage left... that’s why I was confused when testing with smaller folders, the storage reading is fiddly. Anyways it’s not 8GB.
@wim I believe that proves your initial (and logical) thought.