I think the Editor’s Choice is pretty hit and miss. Some are terrific, but they seem to prioritise recent recordings that are Dolby Atmos, Hi res etc. Some of the recordings have sounded pretty average. I think this could be remedied with a curve EQ with granular adjustments. The EQ presets hidden in Settings are a very crude tool.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Hands-On With Apple's New Classical Music App
- Thread starter MacRumors
- Start date
- Sort by reaction score
For anyone with access to a Wall Street Journal subscription there is an excellent article regarding the background of the new Classical service in today’s edition. Well worth reading.
https://www.wsj.com/articles/apple-music-classical-app-3325c6ba?mod=mhp
https://www.wsj.com/articles/apple-music-classical-app-3325c6ba?mod=mhp
Not really. The complexity of classical music and how the UI/UX is implemented for various devices and use cases fundamentally affects API design. There will be endless talks between all sorts of people for every new thing you add to the mix. Then why is it not just a generic API? Because this is exactly what doesn't work for classical.
I don't get this line of reasoning.
I agree that song/artist/album doesn't work for classical.
But why not just add composer/work/movement/performer to the classical section of Apple Music?
BINGO. I am sure this is how I discovered some mid 20c electronic classical composers.
Yes, a jazz version would be awesome. Or, rather, adding the meta data needed for jazz to Apple Music would be awesome, as would meta data for DJ recordings, and so on.
Because you need more machinery to search effectively. You've got lots of things named almost exactly the same, and that means free-form text search will fail more often than it doesn't.
It's a good start, but obviously needs platform support (Mac, iPad, Apple TV, CarPlay, Watch).
The thing I miss most is queue management: you cannot start something playing and then add something else (play last, play next). There's no queue as such as there is in the Music app.
But it is wonderful to finally be able to go from Composer to Works to Recordings of the works (or from Works if you know the name/catalog id of the Work). And to see the metadata for a given recording, linked to the appropriate performer, composer, orchestra etc.
I'd like to see more music personalities involved as there are for popular music. What do conductors listen to or like etc.
And some of the playlists are very long. How is one expected to consume them? It should be like an audiobook, where it resumes from where you left off, even if you listen to other stuff in between.
And why no videos?
The thing I miss most is queue management: you cannot start something playing and then add something else (play last, play next). There's no queue as such as there is in the Music app.
But it is wonderful to finally be able to go from Composer to Works to Recordings of the works (or from Works if you know the name/catalog id of the Work). And to see the metadata for a given recording, linked to the appropriate performer, composer, orchestra etc.
I'd like to see more music personalities involved as there are for popular music. What do conductors listen to or like etc.
And some of the playlists are very long. How is one expected to consume them? It should be like an audiobook, where it resumes from where you left off, even if you listen to other stuff in between.
And why no videos?
Add whatever track/album/playlist, and go to the Music app to download. This works for everything but Works, ironically. The Music app does not know what a 'work' is.
I would like to be able to Edit playlists at least, and you cannot do it in the Classical app. All you can do is add to them. You have to go to the Music app to Edit (remove or reorder tracks). And the Music app does not know what a Work is, so it's a pain to select tracks that comprise a Work and do something with it.Probably because it rarely (if ever) makes sense to listen to classical music in shuffle mode. I can't imagine listening to, say, Vivaldi's Four Seasons in completely random order. Or symphonies, concertos, sonatas, you name it - imagine listening to Eroica shuffled: first the funeral march, then the last movement, then the first, then the third. It would be quite awkward.
Hopefully this is something the Classical app will be able to do in the future.
Responding to a claim that having only one front-end to the Classical service (the IOS app) was better for rollout on the back-end, I said "Those aspects of the system are almost completely separate from each other."
But the back end of the front-end - the component of the user app that talks to the servers - is likely to be librarified and used in all the different versions of the app (IOS, MacOS, etc.). It would be quite surprising if the back end could even tell what OS app it was talking to just from the queries, if they don't self-identify. (...well. If they hold sessions open, IOS devices might ask for fewer results at a time, and you might be able to identify based on that. But that wouldn't change the code anywhere, it would just be a different number in a single API call.)
Limiting the release to one platform is not helpful to the operators of the service. Limiting rollout *volume* might, in which case you would expect them to roll out on Mac first, not IOS.
Your point, while a correct statement, is irrelevant to your argument. You're completely right about the app design- back-end fundamentals were undoubtedly a big part of the job, and I'm sure the API had many revisions, driving multiple coders to drink (red bull or booze, fifty-fifty).
But the back end of the front-end - the component of the user app that talks to the servers - is likely to be librarified and used in all the different versions of the app (IOS, MacOS, etc.). It would be quite surprising if the back end could even tell what OS app it was talking to just from the queries, if they don't self-identify. (...well. If they hold sessions open, IOS devices might ask for fewer results at a time, and you might be able to identify based on that. But that wouldn't change the code anywhere, it would just be a different number in a single API call.)
Limiting the release to one platform is not helpful to the operators of the service. Limiting rollout *volume* might, in which case you would expect them to roll out on Mac first, not IOS.
And that's exactly what increases the complexity and moves the timeline of a project for all frontends far into the future. MVPs are created for a reason. It will be "librarified" and complete once all clients are there. But before that point it makes no sense to already develop everything. The BFF pattern exists precicely to accommodate different frontends' needs.
Last edited:
if you think the difference between a desktop app and a phone app is the number of results, I would fire you immediately.
Don't be ridiculous. If I were doing it, I think I'd grab all results and process them locally, regardless of device. It would depend on doing analysis of user behavior and seeing if local device capacity and typical network speed is at least sufficient for the scale of the problem (size of returned data).
As I said, I think I'd wind up doing that, but I can imagine being wrong about such queries, and in that case, the obvious alternative would be keeping state and processing results on the back end.
(About putting all the calls to the music back-end into a library, which will be used by the various different OS versions of Apple Classical)
All frontends will be performing roughly the same tasks. The interface will be somewhat different (I hope - we won't know how lazy they are with the MacOS version until we see it). In your buzzwords, the "V" might be quite different. The "P" will vary from platform to platform, but how much is an open question. The "M" should be pretty much the same exact thing on all platforms. That's what's in the library. (Well, *a* library; P is likely to share at least some code across platforms as well, and maybe even V.)
I don't see any call for a BFF. The entire thing is managed by Apple. If they're using any external microservices (or external anything visible to the app!) I'd be quite surprised.
(Edit: BFFs are generally useful as a services aggregator, allowing you to keep your frontend small and front-y. That's definitely not what Apple Classical is.)
I think you know a lot of buzzwords.
All frontends will be performing roughly the same tasks. The interface will be somewhat different (I hope - we won't know how lazy they are with the MacOS version until we see it). In your buzzwords, the "V" might be quite different. The "P" will vary from platform to platform, but how much is an open question. The "M" should be pretty much the same exact thing on all platforms. That's what's in the library. (Well, *a* library; P is likely to share at least some code across platforms as well, and maybe even V.)
I don't see any call for a BFF. The entire thing is managed by Apple. If they're using any external microservices (or external anything visible to the app!) I'd be quite surprised.
(Edit: BFFs are generally useful as a services aggregator, allowing you to keep your frontend small and front-y. That's definitely not what Apple Classical is.)
MVP = minimum viable product. Not sure what you thought it meant.
I love the app! Two wishes for the next version:
Apple today officially launched the much anticipated Apple Music Classical app on the iPhone, allowing Apple Music subscribers to download and access an app dedicated just to classical music. We went hands-on with the new app to give MacRumors readers a closer look.
Subscribe to the MacRumors YouTube channel for more videos.
Design wise, the app is similar to Apple Music, but it is entirely dedicated to classical titles. The Browse section, for example, is broken down into Composers, Genres, Periods, Conductors, Orchestras, Soloists, Choirs, and Ensembles, making it easier to discover the specific classical content that you're looking for.
A Listen Now section offers up New Releases, Spatial Audio content, and other recommendations in various genres, plus there is a dedicated Library for aggregating saved content. A search function makes it simple to find something specific.
All in all, the app will be familiar to Apple Music subscribers, and it is in fact very simple. Unfortunately, it is limited to the iPhone at the current time, with no Mac or iPad version available. It's also not available on CarPlay.
Have you tried Apple Music Classical? Let us know what you think in the comments below.
Article Link: Hands-On With Apple's New Classical Music App
1) CarPlay, and
2) the ability to “shuffle all” via composer and period
I really would like the ability to tell Apple Music to just randomly play songs from its entire catalogue of music composed by Haydn, or music from the classical period, etc.
Ah. That does fit his text as well as the TLA I thought he was using (Model-View-Presenter, a coding pattern, a reasonable possibility given his use of "BFF" in the same paragraph). Just illustrates why you shouldn't use them so ambiguously.
In any case, that doesn't change my basic answer.
I like a lot the new apple classical music app. But, I would have preferred that app to be incorporated into the regular music app. With a specific button at the bottom for example. But, I have both and it's ok. I like the fact that in the classical app, the albums you already have into the regular music app have been 'imported' and incorporated. That simplifies the process. Other than that, I like the app itself.