AKAudioPlayer can now trig a callBack when it finished to play !

[laurent veliscek]

Hi !

I found a way to attach a some CallBacks that can be triggered when an AKAudioPlayer is playing and reach the end of the file.

I added a "addCallBack" that add any function to an array of functions that will be triggered if the player is stopped or if it has finished to play the file.

And... it works !

But I still couldn't find a safe way to get a boolean that tells if the player is really playing or not.
player.isStarted always answer true even if the player reached the end of the file.

So I used this addCallBack method to set a custom  "isRunning" public property.

And now, we can safely know if the player is running or not.

\o/

May be could these functionalities be added to a next release of AudioKit ?

I think they could be really useful...

I attached my tweaked AKAudioPlayer.swift to this message.

:-)

Laurent Veliscek

[Aurelius Prochazka Ph.D.]

Hi Laurent, 

Don't you want to make this a pull request onto the AudioKit repo so you can get some credit for this awesome work you're doing?  I think for this one my only change will be to make completionCallbacks a public var and do away with the addCallback function, allowing the user to manage the array elements themselves.  I'm also wondering if there needs to be an array at all.  Probably would be fine with just one callback per audio file playback.

Aure

[Aurelius Prochazka Ph.D.]

So, I just posted a version of AKAudioPlayer into AudioKit's develop branch that implement a completionHandler.  I did it a bit differently than you did and I'll explain why here.

* I didn't use an array of callbacks, but rather just one.  I see why an array might be useful in that you could do some internal bookkeeping with the handlers as well as giving the user access to add their own.  But, your example using it for _isPlaying kind of conflicted with the default isStarted / isPlaying already in place.  If your version is better, I could see replacing the current way of doing things with yours, but having them side by side was too confusing.

* I also don't like adding another method that a user would have to guess the name of, in the case I am  talking about "addCallback".   Instead, the completion handler is an optional last argument in the init.  This has the added benefit that a block can be sent in as a completion handler just very neatly as follows: 

var player = AKAudioPlayer(file) {
    print("I was just played")
}

or explicitly too:

var player = AKAudioPlayer(file!, completionHandler: someFunction)

Anyway, thanks for pushing the toolkit forward!

Aure

[laurent veliscek]

Hi Aure,

I didn't played with the new cooked AKAudioPlayer yet, but after I made some experiments, I think we miss an "isPlaying" property for AKPlayer.

I tried to expose the internalPlayer.playing property with no success, it is not reliable, as it is always true even if the player reached the end of the file.

According AKAudioPlayer documention,

public var isStarted: Bool

should tell whether or not the audio player is currently playing.

But even if the player doesn't play anymore, this property is still set to true.

That's why I implemented my custom isPlaying property, automatically set to false when completionHandler is triggered.

I'm not very proud of how I did it, and I'm sure it can be done in a cleaner way.
But It would be handy to have a public reliable "isPlaying" property.


Another thought about AKMIDICallback and AKAudioPlayer completion handler :

I got a "This application is modifying the autolayout engine from a background thread,...." Error when I attach a function that try to update the UI.

It can be fixed using dispatch_async(dispatch_get_main_queue()...

But I'm questioning myself if it may corrupt the sequencer accuracy and internal AudioKit behavior.
Could a foreground function call from a background thread affect the background thread in a undesirable way ?

May be this point and the "dispatch_async" trick should be mentioned this in AKMIDICallback and AKAudioPlayer documentation... (?)

I'm very busy until next tuesday but I'll do some more tests using the new AKMIDICallback as soon as I can.

:-)

Laurent.

[Ryan Francesconi]

This is working well. Thank you,

Ryan