Web audio #1002
Web audio #1002
Conversation
|
Cool! Thanks for taking the first step—this should be great to have. Yes, we should check how this interacts with native playback. It would be a shame to lose that when the platform supports it. I'm also somewhat wary about including these JavaScript components in the main beets distribution. I already regret including jQuery, for example, which seems to cause headaches for packagers. For example, in Debian, they need to unbundle these components and create dependencies on official JavaScript packages. They also can't accept minified/compiled JavaScript as it's not considered "source code". I'm not sure what the best way around this is, but two non-ideal paths come to mind:
|
|
Yes, eventually we should use Aurora.js only as a fallback. I wasn't aware of other efforts such you refer to. Perhaps a feasible road is along these lines:
I think this is a great route for a (local) web client, but it would require npm. |
|
Yeah, something like this would be good. We of course don't need to solve the whole problem right now just to get the Aurora.js feature, but I suppose it can't hurt! #736 discusses the CORS/swappable frontend issue a little bit. CORS is probably the way to go, but another fallback (aside from a little node.js server or what have you) is to let the server itself host frontends. You could say I am far from being a practiced front-end developer, but it seems like Bower could also be a good alternative for packaging these things. We could even provide "builds" that include snapshots of all the dependencies for easy npm-free installation. |
|
To make a long comment shorter: I think a separate |
|
Maybe it's useful to start with a migration of the existing web client (not the one in this PR) to a separate intermediate/legacy npm package, mostly to get a feel for how that would work and discussion. It would be served from the existing server with the example command you provided. That shouldn't be a lot of work. I think a well-featured player, in a new fancy UI with native |
|
Indeed—that would be a great experimental first step. I'll keep looking into it—and, meanwhile, I would be very interested to hear from more experienced frontend engineers about their favorite tools for doing stuff along these lines. |
|
More input is definitely welcome. Any insights on how lightweight it should be? What devices should it run on? Desktop, mobile, anything else? Btw, I do think that Bower isn't adding much over npm here (mostly because |
|
Good question! The web interface works right now on iOS, but not particularly well. (I don't know about other platforms.) It would certainly be nice to keep that as an option… mobile-first world and all. 😃 I'll be the first to admit that I don't know the relative merits here, so you're probably right about npm vs Bower. My impression was that bower was focused on frontend stuff—HTML and CSS components, and JavaScript intended to run in the browser—while npm is supposed to contain Node.js libraries. But it appears the lines have gotten somewhat blurred. |
|
Apologies for being a bit silent here. I'm willing to start building a frontend, but existing alternative frontends for Beets like Ampache (I didn't know of) look attractive at first sight (regardless of required integration efforts). I didn't really look around at all before, to be honest. Imho, any efforts here should have some "unique selling points" (e.g. UI-wise), or other benefits to have a "dedicated" Beets frontend. Before starting any development, I'd like to know more about existing efforts and (potential) alternatives :-) For starters:
Anything else? Reasons to not jump onto alternative frontends? |
|
I've actually collected several of these. Everybody and their dog seems to want to write a browser-based music streamer: The problem that I see with all of these efforts is that everyone invents their own protocol. This means that they have to solve two problems: the front-end interface and the back-end database. This coupling is problematic because both are hard problems! A developer who's excited about building a cool Web frontend (or even an iPhone streaming app?) should not get slowed down by needing to worry about the backend database. Hence the effort toward a polished API that can separate these. I know this has shades of xkcd, but I think this a real vacuum: there is no good API worth reusing. Fortunately, beets is in a good position to help solve this: we've done the hard work for the backend database; now we can use that to help expose the right API for frontend designers. Anyway, I totally agree that it might be worth starting with one of these frontends—which are probably far further along than our little prototype—and extend it to use the API we expose. Maybe it's worth doing a survey to see which projects look suitable for integration. |
|
Doesn't Ampache already have a beets catalog plugin? Couldn't that be used? Bearcat M. Şándor
|
Does it? A little googling hasn't turned that up… got a link? |
|
I was looking at this: On Tue, Oct 21, 2014 at 5:42 PM, Adrian Sampson [email protected]
Bearcat M. Şándor |
|
Yes it does :), in develop branch thanks to @Razrael and ampache/ampache#398 |
|
The thing that would make Beets integration awesome is all the tags that Beets can support. Just think of being able to filter a classical music collection by composer, or set up playlists based on bps or initial key. Being able to query our custom tags (i have one for who mastered the album and whether it's an original master recording). Starting a playlist based on a lead guitarist for all the songs she's been in regardless of band. I don't know of anything else but Beets integration that would do it easily. MPD doesn't track that stuff. |
|
As I developed the first beets integration in ampache (local and over the web-plugin), I would be interested in a (better) API for both ways. For the local library I just made a wrapper for the CLI command and get all data via 'beet ls -f [way to many fields with some seperator]'. A JSON API or the possibility to get all data in JSON format would be great. A solution for ampache to use all metadata for beets is on its way. I am developping the possibility to add custom metadata to ampache these days. When I am done with this, this will be of course also implemented to the beets catalogs. |
|
Very cool! I'm excited to learn about this—I'll definitely have to try it out on my server. 😃 Your advice is heard loud and clear about making the web API complete for uses cases like this. I'm very interested in the v2 API being as complete as possible. I also like the suggestion to provide a simple "local" version of the API that provides the same JSON responses on-demand through invocation. Hmm… About
This is actually because those are flexible attributes, which are not catalogued anywhere. They don't exist in the plugin, per se, they just exist on the albums and items they've been applied to. (This is different from computed fields, which plugins must explicitly declare, and which are shown in the That said, we could do a little better here by looking at the type declarations in the plugins, which do provide insight into the flexible attributes they "provide". |
|
One more thought for the awesome Ampache people: I 100% agree about focusing on a REST API paired with purely client-side players. That's exactly what we'd like to accomplish here—and, in the process, get beets itself out of the business of providing the UI. To that end, I'd be interested in collaborating with you (and perhaps also Sindre) on designing the right API to make life easy for clients. You obviously have lots of experience with emulating other APIs (Subsonic, Plex, UPnP, DACP), and I think we could learn a lot from that experience when designing an interoperable REST "standard". Let me know if you'd like to continue this conversation. |
|
I have some experience with several music/media api indeed. Each one have advantages/disadvantages, but there is no perfect one. My opinion would be to extend an existing api to have compatibility support with existing clients. I think you should first compare Ampache / Subsonic / UPnP / DACP api (Plex is not the best in your case because of all the myPlex stuff) on a feature level from a beets point of view. I'm willing to discuss this with you :) |
|
@Afterster Thanks for the thoughts. I'll do a survey of the various APIs' features, and I will definitely be in touch again. As we put together a reasonable API, it would be awesome to have input from people with real experience building interfaces like Ampache. |
|
To anyone who's interested: I've started putting together some ideas for a new API spec for this project. It's located in a different repository, and provisionally called AURA: https://github.com/sampsyo/aura I'd be very interested to hear feedback on the direction from other project maintainers and anyone with experience in API design. You can see my notes on other projects' APIs on the wiki here: https://github.com/sampsyo/aura/wiki/Related-Work |
|
As a side note here, you mentioned the decoupling of beets and a web player which I think is the right way to go around doing it. In this instance, will beets also be providing the live transcoding of media file. I feel that if beets can query and serve media files, whilst transcoding to a web playable format or lower bit rate, will be a great feqature and a welcome addition. |
|
Hi, I'm working on a web player (festival) for several years now, and I would like to be able to use beets as the library. |
|
Very nice! This player looks great. Maybe we should chat about the upcoming AURA API? |
|
@sampsyo You can find me as Magne` on Freenode |
|
Made a PR #2321 |
|
Sorry guys, no more activity (from my end), so I'm closing this issue. |
See #986. This is the generic idea. Plenty of improvements possible, but I've just tried to stick with the current setup for the client-side application as much as possible.
Note that I've not considered any performance and (cross-browser) compatibility issues, so this should not be merged right away. I can do this later on, but wanted you/others to have a look at what I have now.
Let's discuss the idea, issues, and directions.