iOS SDK for Ableton Link, a new technology that synchronizes musical beat, tempo, and phase across multiple applications running on one or more devices.
I've been attempting to implement the bold sections of this guideline:
When an app moves to the background and it is known that no audio will be generated by the app while in the background, Link should be deactivated by calling ABLLinkSetActive(false) - even if background audio has been enabled for the app.
However, my app supports fairly complex audio/MIDI input configurations and a sequencer which could potentially be triggered externally (eg. via MIDI or Audiobus) and I'm finding that the logic to do this is fairly complex and possibly fragile. I'm starting to feel like it's a potential source of difficult-to-solve end user problems in future.
My app provides users with a checkbox option to 'enable background play'. If disabled, the app will not play audio in the background provided that Audiobus is not connected (as recommended in the Audiobus guidelines).
Is is acceptable to simply link ABL's background active behavior to this user option, rather than the complex play logic I mentioned above? I feel this would be a lot simpler for users (and me) to understand. The app's behavior when it goes to the background would then be something like this:
I've been attempting to implement the bold sections of this guideline:
However, my app supports fairly complex audio/MIDI input configurations and a sequencer which could potentially be triggered externally (eg. via MIDI or Audiobus) and I'm finding that the logic to do this is fairly complex and possibly fragile. I'm starting to feel like it's a potential source of difficult-to-solve end user problems in future.
My app provides users with a checkbox option to 'enable background play'. If disabled, the app will not play audio in the background provided that Audiobus is not connected (as recommended in the Audiobus guidelines).
Is is acceptable to simply link ABL's background active behavior to this user option, rather than the complex play logic I mentioned above? I feel this would be a lot simpler for users (and me) to understand. The app's behavior when it goes to the background would then be something like this: