If they could work, we should scope out a solution, set a goal on our OpenCollective, and sprint! https://twitter.com/gusaus/status/1017156624023052288
Referencing this comment as it’s related to this discussion -
Yes, but the problem today with audio players and web content management systems is navigation interrupts the stream. A player must be sticky to the footer or the header (or top bar) of a site to have any chance of wide adoption. There are far too many players out there already that work and people stick them in, but the experience is poor. So, if jPlayer is open source, it must be wrapped in a sticky footer or header option for both Drupal and WordPress. Sure, jPlayer is far and away leading the open source player movement, but until they adopt some type of sticky functionality, for me it’s not a solution to a long term problem. It’s not so much the player - that’s there. It’s how the player is implemented on a site that gives it more value.
If you’re brief message suggests just using jPlayer but building it into some useful sticky function, then I certainly agree and my comments are already in line with your point of view.
Yeah, that is the big challenge. We have a volunteer working on a solution, the challenge is whether even a sticky footer or header would work and stay consistent without wrapping the whole site in an AJAX framework and avoiding explicit pageloads. Kexp.org basically maintains their player through this but I don’t know of any Drupal module that does this, or wordpress configuration. It’d certainly be worth figuring out and it indeed is the next step for our site overhaul because maintaining the ability to browse and surf the page while keeping the single audio player is important.
Here’s one on Code Canyon for WordPress:
Could this plugin be the basis for what we’re looking for?
As mentioned in this discussion, possibly we could include the required functionality in the following?
- Radio Station (WordPress)
- Station (Drupal)
We’re looking for something like the fixed position player in your published example: http://zirafa.github.io/pushtape-player.js/demo/fixed-position.html
But, I did find this player, which is similar: https://github.com/lucasato/Sticky-Responsive-Audio-Player-Jquery
We’re working on building something in as a premium option - but want to make sure it works natively with LibreTime.
Let us know what solutions you’re thinking about and how we can collab on this.
I’ve created a webcomponent audio player for that : https://dascritch.github.io/cpu-audio/
Licenced in GPL
You can see it in action at http://cpu.pm . The sticky player may be seen when you scroll out the in-content player out of view.
We are working to adapt it for streamed content
Have you looked at the webcomponent audio player referenced above? Curious if there’s something already built that could be extended.
@djtonyz Is the player you’re building going to be part of Radio Station plugin or could it be a stand alone project?
Think that ideal would be to collaborate and funnel resources into a player all projects could use. Extending one of the webcomponent players might be a good way to go?
Would be part of the plugin - an “add-on” that needs to be a plugin for WordPress. Regardless of whether it’s built inside or outside of Radio Station, it still has to be built for multiple CMS’s. There are already competing players in the market that are being used, so I don’t see the value of trying to compete with the player. And, our users want to take the LibreTime stream and port it into WordPress as well as utilize an API going in/out of LibreTime to add/publish show schedule, playlists, and DJs/Hosts or the reverse if it’s being done in LibreTime. We want someone to use Radio Station as the defacto WordPress plugin that brings LibreTime content into WordPress. So, if someone were to install it and set the API key, once they published their Shows in LibreTime, it would automatically publish the Show in Radio Station. Same for Playlists, but we’d have to figure out how and when to pass and publish playlist meta data based on the air date or whatever.
I think there’s agreement to collaborate around a player that could plug into multiple OSS projects and platforms. Could we build on any of the ones referenced in this discussion?
https://radio.co/ provides good inspiration for customizable radio players. Wonder if there’s good source material to replicate.
Do you think it could be extended to incorporate some of the functionality referenced here?
We must see what is missing and can be asked.
Today, it can be personnalized (color, font, mode) https://dascritch.github.io/cpu-audio/LIVE#configurator_html , there is chapters and playlist features, an i10n minimalistic service, and mostly, trying to keep using standard HTML5 API features.
This looks very promising! So will this play LibreTime streams or is there still work to be done on that end? Possibly other folks building or needing this type of player could collaborate or contribute?
I was able to play inside an icecast stream.
But it will indefinitively keep in ram the downloaded stream…
May be problematic for smartphones ?
Le mar. 4 févr. 2020 à 20:18, Gus Austin via LibreTime email@example.com a écrit :
Circling back to this as some of the folks/projects talking here have overlapping goals.
LibreTime has a couple issues in the queue -
Radio Station plugin for WordPress has a few related to audio players -
OpenProducer platform for radio stations and podcasters would like to bridge these together -
Assuming all these features could be provided by Radio Station + LibreTime (once there’s an API), we can direct resources towards development with a bounty, paid beta and/or series of hackathons directed towards radio stations and podcasters.
Would be great if we could bring all involved contributors together in the #openproducer channel in https://slack.opencollective.com/
So ultimately there are a bunch of different issues here.
The primary one is LibreTime provides widgets that use libraries that seem to not work reliably on all systems. The widgets and radio page are the most obvious way for people to stream but in reality they could use any of these players with LibreTime because most of them should be able to stream the Icecast stream LibreTime provides. Most modern browsers can stream a mp3 stream just by opening up the file.
The Sticky Audio Player is something that would need to be implemented on the front-end website and our widget will never support that out of the box as per the reasons above.
What we need at this point is for someone to deep dive into the Widget/built-in audio player and test it on a whole slew of platforms and identify where it fails and then suggest a solution that works for all of them that we can resolve it with.
So the sticky audio player would be a separate project (from the web player that ships with LibreTime)?
Would this be a LibreTime feature/project? Part of the Radio station plugin project? Something else?
As noted in this discussion there are several existing solutions or projects with similar goals. How can we reduce duplication and focus resources on something that can be shared across all projects?
I think that Radio station plugin is a separate project in and of itself but the web player plugin they are developing should be stand-alone and at the same time compatible with LibreTime and other radio streams.
Really the widget is kind of a hack for people who don’t have their own solution built into their website like what hopefully the radio station plugin will provide or whatever other custom player.
At this point we just need someone to do full testing on the widget we provide with every imaginable browser and operating system combination, report their findings and then make a decision if there is something better we can plugin that will replace what we have. It could be a rather involved process.
I don’t see the widget being an essential part of LibreTime because the functionality can be easily duplicated elsewhere but in reality a lot of people using LibreTime depend on it I think because they don’t have other solutions in place already. So it is a useful component and it’d be good to provide the best option that we can out of the box.