What would you wish for for our widget?

[dpreussler]

Many of you are writing custom players. Tell us what is missing in our widget so you would not do that!
https://developers.soundcloud.com/docs/api/html5-widget

[amrutadotorg]

Many of you are writing custom players. Tell us what is missing in our widget so you would not do that!

https://developers.soundcloud.com/docs/api/html5-widget

Hi. The Dark mode would be great!

[ymeskini]

It's HTML only and not usable on other platforms

[dpreussler]

It's HTML only and not usable on other platforms

@ymeskini what would you like to see?

[ymeskini]

For example, for a react-native project, I couldn't use it properly

[DerpcatMusic]

Custom CSS would be great, to build a player that actually fits with the websites style!

[vincerubinetti]

I'm a music composer. For a decade, my personal portfolio website music player has been based on SoundCloud. I already have my most popular tracks on SC, and it's a convenient way to manage song stats/playlists/thumbnails/etc. and stream track audio. It would be a huge effort to reimplement these things myself. Also, for better or worse, SoundCloud is the standard for embedding sharable audio on websites (look at any sample library demo page). Bandcamp has a widget, but it can't do playlists and doesn't show play stats.

For a while I just used the official SC widget, until it really just became a huge eye sore by modern standards. I wanted to make it consistent with the rest of the site's design, and have my own custom UI that controlled the raw widget (which I'd make invisible). I tried using the official Widget API, but I've found it to be very limited, archaic, and buggy. See below.

However, now it seems like maybe API signup has returned? I submitted an API key request with the AI chat bot, and a human eventually granted me one within a few days. Hopefully I can at least use the API to look up my own playlist tracks and track metadata, then still use the widget to play each track.

Regardless, the problems with the widget still should be fixed.

---

In general, I think the widget needs a complete overhaul.

Here's a taste of the hacks I had to do to make the widget work as expected. And here's the full code for my website (if link broken, check Software Heritage).

Specifically, here are some of the issues I ran into that I can remember:

• The callback pattern is very antiquated. Instead of widget.getSounds((sounds) => sounds), it should simply be await widget.getSounds(). Promises have been widely supported for an extremely long time, except in Internet Explorer which is long deprecated.
• Widget is not always truly "ready" to play tracks or interact with after the READY event. I've found that e.g. getSounds has to return some value before playing/seeking/etc. will work reliably.
• widget.getSounds only returns full track details for the first 5 tracks of a playlist. As a result, I need a really ugly hack of cycling through all the tracks.
• widget.getSound returns just empty or incomplete details sometimes. As a result, I have to try several times with timeouts.
• widget.bind fails sometimes if I don't wait for widget.getSounds to return something after initializing the widget. That is, the widget isn't actually ready when the READY event is emitted, getSounds must also be there.
• widget.next (and presumably other track change methods) seem to be async. If I synchronously call getCurrentSound after next, it sometimes will still reflect the previous track. As a result, I need to wait for the sound index to change with timeouts.
• PLAY_PROGRESS events continue to trickle in after a PAUSE command/event.
• PLAY event is triggered when a seek command is issued, even if the player is paused.
• When trying to visually hide the widget so that I could show my own, I found that if it was out of bounds of the viewport e.g. left: -9999px, various calls e.g. widget.play would fail on certain browsers (can't remember which). This could conceivably be a browser optimization of some sort, not loading the <iframe> fully.
• Not confident that memory is being properly garbage collected when a Widget instance is replaced. A dispose method would be nice.
• tags are returned in the format tag "tag 2" tag-3 which is a pain to parse into an array.

As you can see, there's a host of issues. The code I needed to write could've been reduced by 25% if these issues were fixed. Please understand that this has all been very frustrating and disappointing, but I definitely don't blame the developers. I very much appreciate the noticeable increase in dev response and openness to feedback on this repo.

I'm not sure how many of these issues are rooted in the relatively thin api.js wrapper script vs. the backend of the API... If you were willing to open source the unminifed version of api.js, I'd be happy to take a look and make suggestions.

[dpreussler]

Thanks for the detailled feedback @vincerubinetti and yes these are thoughts for an "overhaul". So we'd look for what a new widget would supposed to look like

[vincerubinetti]

Okay, I realize now that this discussion is supposed to be about the design of the Widget UI such that the Widget API is not needed.

If you are focusing on that, I would say, as others have said, much much much more customizability with the styles and layout: background color, button color, track list item height, waveform style, thumbnail height, etc.

Ideally it wouldn't even be an iframe at all, but some kind of declarative component that could be easily integrated with React or Vue, where you get all the time/track/art/etc info as raw data and functions to play/pause/next/etc, then you can make your UI however you want.

[nigeljohnwade]

I was directed here from a request to get an API key for app development. My main reason for wanting to use the API was that I didn't think there were enough customisation options. I had also built things with the API years ago but the account I used has lapsed so I wanted to pick up where I left off developing my reactjs components.
I have only been copying the embed code that is revealed when you hit the share button on a track so I was not aware there were more options when you use the widget API referenced in the blog post at the top of the post. It is possible that I may be able to achieve what I want with the widget API, however as a I have not tried using it yet I cannot confirm.
I was pleased that I was able to get a key quite quickly (<1 hour) after many years of thinking it was not possible any more, which was a huge bonus.
As a professional JS developer and a music maker I much more interested in having the API access to data than a very customisable widget.