Local / Shared Playlists

[syntholly]

I'd love a way to create local or shared playlists. I recognise #12 was mentioned, discussed and closed, but would love to open this idea up again.

Perhaps that data can be conflated into query-params (for easy sharing) or something more stable like cookies (if you want to go down the perms route). Otherwise saving the playlists (that contain no real secure data) to a free OSS JSON-blob storage app might be a fun and useful way of fixing that storage issue.

My primary use is I want to create 'relaxing MapleStory playlists' for work - but the Youtube videos I typically listen to have become so ingrained in my brain that the order of them drives me a little crazy. I want to randomise my playlist throughout the day.

Would be happy to discuss the idea and plan more if required.

[nanochromatic]

Appreciate the enthusiasm for this. Query params can be a solution for lightweight playlists, but will be hard to scale to lengthy ones. Cookies and localStorage suffer from the persistence issue mentioned in #12, so while it's a solution, the user experience can be janky. Importing/exporting JSON is a good serialization mechanism, but suffers from the same data loss potential if a user doesn't backup their playlists. As this is a static site, one goal is to minimize the amount of (complex) data that needs to be stored. User created playlists would fall under this umbrella. If in the future the site model changes and a backend/database were to be established, this would be more practical to implement.

Can you create YouTube playlists for your use-case? YouTube playlists can be shared and also allow shuffling of the tracks during playback.

[syntholly]

Thanks for the reply, and so soon!

I have to argue your point here:

Query params can be a solution for lightweight playlists, but will be hard to scale to lengthy ones.

I don't foresee this being a problem at all. My probable use-case is that I'd actually never even see the URL in a lengthy manner or unwieldy fashion. That URL will be bookmarked immediately and converted on the fly by the application on-load, right?

?tracks=10013,10049,10039,10095 - it's iterated through and pulled from the database. Does that sound appropriate?

I think if persistence is the issue with other solutions, I'd rather have it for some time than not at all, but I would also argue params would be the most persistent in this circumstance providing nothing internally changes.

I recognise the extra work here, I'm happy to contribute as a PR if you're accepting them. It's just a feature that's stopping me from getting the absolute last-drop from the site that I can, haha.

Can you create YouTube playlists for your use-case? YouTube playlists can be shared and also allow shuffling of the tracks during playback.

Yes, but this is a much more manual, tedious process than I'd like. I can foresee a little orange button with [+] on each item I search within the site that throws the ID of the track into the URL. From there I can just share/alter/update that as I need. With the YouTube playlist I'm back-and-forth.

Thank you again for the reply! I appreciate the honesty.

[nanochromatic]

I don't foresee this being a problem at all. My probable use-case is that I'd actually never even see the URL in a lengthy manner or unwieldy fashion. That URL will be bookmarked immediately and converted on the fly by the application on-load, right?

The unique identifier for each track consists of a folder path and filename. The filename is at Nexon's discretion and can be arbitrarily long with special characters (eg. Bgm60/The saddest sanctuary, Sephiroth). Ideally, this identifier would be used in the playlists instead of numeric identifiers, as that would create a new layer of indirection. The example earlier is at 38 characters without any encoding (which will need to occur to handle special characters), meaning this model can blow up pretty quickly with a few hundred tracks in a playlist. While the URL may not be visible in your bookmarking use-case, it's not practical to share a playlist this way.

If custom playlists are to be implemented, I'd lean towards JSON serialization to/from localStorage. There's already an established format for non-custom playlists (see here), so it's just a matter of following that spec. Easier to read, edit and send around. The big caveat here is that data loss will occur on a wipe with no backup.

Let me think about this some more and I'll take a stab at a first pass.

[nanochromatic]

This has been implemented: there's a new Playlist Builder page for JSON playlist imports/exports. A copy track ID feature has also been added to the Playlist page. To keep things simple, the workflow is primarily text based. Split screen with the site on one side and a text editor on the other should allow for a relatively streamlined workflow. The text editor maximizes versatility and minimizes complexity required on the site.

[nanochromatic]

I've also added the Export Set, which is a collection of tracks that can be added to and removed from on the Playlist page. Under the Playlist Settings dropdown, there are options to copy and clear the Export Set. Copying the set will generate a JSON compatible list of all the tracks and save it to the clipboard. This should simplify the multi-track workflow when creating playlists.

[syntholly]

This is an amazing effort! I haven't tried it yet but I will in a few hours. I can't wait, thank you so much.

[nanochromatic]

One small change to the track ID copy feature: the default copy behavior no longer includes JSON syntax, it'll just be the unformatted string. You can turn JSON optimization back on through the app settings.