LiveCode Forums.

I’ve been building an app for my own personal use to select and play albums digitized as .mp3 files from my old vinyl collection. These have been organized on disk into subfolders by genre, artist, and actual album. Any one of these files can be located/selected/assigned to the player object via a set of corresponding option menus. This all works works just fine.

However, I’ve hit a brick wall in trying to employ the callback feature of the player to display a graphic that updates periodically as the audiofile plays. Tried first using this feature to update the thumbPosition of a progress scrollbar object. No luck.

Then tried employing a more rudimentary version to update a text field like the examples I’ve found online.

So, for example, the text associated with the first callback might be “>| <”, the second “>|| <”, the third “>||| <”, et cetera. Still no luck.

Here’s the thing: Unlike the examples found online – which were crafted knowing in advance the time at which each callback should be triggered – the duration of each of my album audiofiles is different.

So my strategy has been to identify the duration of the audiofile (the total number of samples, aka intervals), divide that duration by 50 (rounded) to obtain an increment value, then construct a callback list with the first item of each line being a successive multiple of that increment. So no matter the length of the actual audiofile, the handler specified in item 2 of the callback list should be triggered (and the display updated) at each 1/50th of the total duration of the audiofile.

Nope, doesn’t work. (BTW, the timescale of all audiofiles is 44100 samples per second, so it seems unnecessary to employ the adjustments employed in the examples available online. And when I’ve checked the “dontUseQT” property is set to true.)

Frankly, because this app is just for myself, I can live without the graphical update. I just hate to be defeated when trying to master a new LiveCode feature.

Any suggestions would be most welcomed. Thanks!

jeff k

Jeff.

I have never used a player, but looking through the many properties it has, I noticed one called the "currentTime". Check that out. It would be nice to have a built in property that you might exploit.

Craig

Hi Jeff,

Callbacks of players work for me on a Mac. I am not sure but there were problems with the player on Windows.

This is the stack I used for testing using LC 9.6.9 rc2 MacOs 12.6.3

Kind regards
Bernd

Hi Bernd –

Thanks so much for the example stack you posted. It has proved especially helpful both in its simplicity and because – as my app must do – it generates a callback list “on the fly” by specifying callback intervals based upon some division of the duration of the current audiofile, rather than (as in other examples I’ve found) employing a callback list specific to the length of a particular audiofile.

One surprising discovery while running your stack is that I may have been chasing a solution to a non-problem: Irrespective of the callback feature, the progress bar in your visible player controller *does* advance as expected as the audiofile plays.

This was not the case in previous versions of my app: The player thumb was not advancing as the audiofile played, yet jumped to the endpoint once it reached the end.

This is what first prompted me to consider using the callbacks to display an alternative to the player controller progress bar.

I’m still far from figuring this all out. The LiveCode documentation of the player object is less than ideal – e.g., how to program the pair of buttons on the right side of the controller, as well as how to script a resume playback after a pause.

Nevertheless, your contribution has been truly invaluable, and I will post an update here once I’ve found a reliable solution.

jeff k

P.S. Thanks also to Craig for his comment. I may indeed need to dig into the player properties to handle pausing/resuming playback.

Hi Jeff,

One surprising discovery while running your stack is that I may have been chasing a solution to a non-problem: Irrespective of the callback feature, the progress bar in your visible player controller *does* advance as expected as the audiofile plays.

I noticed when you overload the callbacks (too many of them) the progress indicator of the player does not move.

how to script a resume playback after a pause

to play only a selection:
Unfortunately as you noticed the new player object is not well documented. Too bad that the Quicktime version of the player is not longer available since Quicktime has been deprecated.

So it is a bit of experimenting and dictionary searching to get to what you want (or to find out it is not possible)

Kind regards
Bernd

Hi Bernd –

Thanks again for your example and suggestions.

I have indeed gotten the code to work as intended: With the player control hidden, the callback list does update a progress bar as an audiofile plays. (Using 50 callbacks does not choke the player and seems a reasonable number to accommodate audiofiles of widely varying lengths.)

As you’d advised, the dictionary entries for the player object were sufficient to work out pausing/resuming an audiofile without messing up the progress bar, as well as enabling one to skip over an audiofile and/or terminate the entire playlist.

This callback/progress issue actually was the last stumbling-block in completing the full app, which scans an archive of audiofiles (organized in subfolders by genre, artist, and album) so albums can be selected using a corresponding set of option menus. (Lots more convenient than using the answer file dialog.)

Still, just in case anyone ever wants/needs the employ a visible progress bar for a hidden player object, I’m posting a stack for that portion of the code that might help. (A similar issue actually was raised in this forum way back in Nov 2016.)

In case you need a few very short (< 1min) audiofiles to try out this stack, a .zip archive with four snippets of classical pieces (total 3.5MB) can be found here:

https://newpsyc.com/AlbumPlayer_Audioclips.zip

Now I’ve just got to tackle building standalones that run on very old Macs employing the old QuickTime player, so – in lieu of streaming wireless – I can set these up in different rooms to play my archived audiofiles.

Best wishes,

jeff k

Hi Jeff,

That looks very nice and works as advertised. Congratulations.

It should not be too hard to use the old QuickTime player since the syntax is similar/the same.

Kind regards
Bernd