I have been pondering now for a few weeks, does the IOS 11 files support allow an app to declare the name of the folder it uses for its files ?
If so, why dont we define a standard and demand Audio developers use.
So a unified standard folder would be created, say "Audio Apps"
Each app would create its own subfolder within that folder.
Now all your audio files would be available in every app, no move, no import nothing, same for MIDI.
Again this is a ponder, @mathieugarcia@brambos any insight on this being technically possible ?
If I don't recall wrong any app can 'reference' a location on 'iCloud' or a location provided by an 'iOS FileProvider' but for 'Files'(Ie. iTunes 'Documents' folders of the respective apps) this could be a bit tricky since the files are stored inside each apps 'sandbox' and can not directly be accessed by other apps.
Most apps do not reference files but rather fetch a copy and store in their own area when using the DocumentPicker/Files.app interface and this is quite understandable since streaming from for example DropBox could be quite un-reliable for realtime usage.
Don't know how much 'overhead' the referencing (from Local Storage) access would cause compared to a file that is 'already in place'.
Most apps would likely need to be re-written to adopt proper referencing that's why it's easier to 'fetch a copy'.
Don't know if iOS even supports 'Aliases', 'Shadow Copies' or 'Hard Links' across multiple apps considering the anal app permission mayhem that iOS is burdened by...
(A permanent jailbreak would solve lots of these issues but cause severe paranoia among paranoid people).
It's the classic 'Security vs Freedom' that is the root to many of these 'problems'...
I have to investigate again, but iCloud containers can be shared from app groups from the same developer.
It is tied to certificates, App ID's and groups so I don't think this is possible as of now.
However this could be done by other means, maybe via Firebase, AWS or something equivalent but that would require sharing of fees / accounts between developers, etc.
Back on iOS 2 or 3, it was possible to create a shared folder in the picture directory, that's how BM1 was able to share samples with other apps but that was quickly fixed by Apple. Nostalgia !
So Woodpressor can do sidechain compression in any host by opening two instances, one you set as send, the other you set as recieve, is this true plugin to plugin audio that could be defined as a standard, or just some shared resource instancing trick ? @mathieugarcia@brambos
The reason is ask is because for me the ultimate long term aim of B3 itself has to be modular components like Oscillators/LFOs/Filters being loaded to individual pads within a bank, and audio/modulation data freely being passed between, so that it is pretty much the ultimate modular synth/sampler/grooveDAW ala VCV buult in to Ableton Live, and open up the modules to 3rd party developers via IAP
@5pinlink said:
is this true plugin to plugin audio that could be defined as a standard, or just some shared resource instancing trick ?
The latter, unless there's a huge AUv3 feature that has slipped my attention all this time. And the shared resources hack may be in grave danger of being disabled by Apple. We're currently discussing lifting the 350Mb memory limit for AU plugins, and they're considering giving each plugin instance its own 350Mb sandbox instead (a major improvement!). But it would make sharing resources between multiple instances impossible
Comments
I have been pondering now for a few weeks, does the IOS 11 files support allow an app to declare the name of the folder it uses for its files ?
If so, why dont we define a standard and demand Audio developers use.
So a unified standard folder would be created, say "Audio Apps"
Each app would create its own subfolder within that folder.
Now all your audio files would be available in every app, no move, no import nothing, same for MIDI.
Again this is a ponder, @mathieugarcia @brambos any insight on this being technically possible ?
If I don't recall wrong any app can 'reference' a location on 'iCloud' or a location provided by an 'iOS FileProvider' but for 'Files'(Ie. iTunes 'Documents' folders of the respective apps) this could be a bit tricky since the files are stored inside each apps 'sandbox' and can not directly be accessed by other apps.
Most apps do not reference files but rather fetch a copy and store in their own area when using the DocumentPicker/Files.app interface and this is quite understandable since streaming from for example DropBox could be quite un-reliable for realtime usage.
Don't know how much 'overhead' the referencing (from Local Storage) access would cause compared to a file that is 'already in place'.
Most apps would likely need to be re-written to adopt proper referencing that's why it's easier to 'fetch a copy'.
Don't know if iOS even supports 'Aliases', 'Shadow Copies' or 'Hard Links' across multiple apps considering the anal app permission mayhem that iOS is burdened by...
(A permanent jailbreak would solve lots of these issues but cause severe paranoia among paranoid people).
It's the classic 'Security vs Freedom' that is the root to many of these 'problems'...
Hey guys, interesting topic.
I have to investigate again, but iCloud containers can be shared from app groups from the same developer.
It is tied to certificates, App ID's and groups so I don't think this is possible as of now.
However this could be done by other means, maybe via Firebase, AWS or something equivalent but that would require sharing of fees / accounts between developers, etc.
Back on iOS 2 or 3, it was possible to create a shared folder in the picture directory, that's how BM1 was able to share samples with other apps but that was quickly fixed by Apple. Nostalgia !
Cheers !
Mathieu.
Ok so that was a dead duck....
So Woodpressor can do sidechain compression in any host by opening two instances, one you set as send, the other you set as recieve, is this true plugin to plugin audio that could be defined as a standard, or just some shared resource instancing trick ?
@mathieugarcia @brambos
The reason is ask is because for me the ultimate long term aim of B3 itself has to be modular components like Oscillators/LFOs/Filters being loaded to individual pads within a bank, and audio/modulation data freely being passed between, so that it is pretty much the ultimate modular synth/sampler/grooveDAW ala VCV buult in to Ableton Live, and open up the modules to 3rd party developers via IAP
The latter, unless there's a huge AUv3 feature that has slipped my attention all this time. And the shared resources hack may be in grave danger of being disabled by Apple. We're currently discussing lifting the 350Mb memory limit for AU plugins, and they're considering giving each plugin instance its own 350Mb sandbox instead (a major improvement!). But it would make sharing resources between multiple instances impossible
Aaaah, I remember similar resource sharing hacks causing non stop issues on the desktop too years ago.