More > JRiver Media Center 27 for Windows
Feature Request: Better Support for Classical Music
henning65:
+1
sorry for being late!
I like to support the feature request for composition - support
Hendrik:
One note on any plans you make, not to dampen any excitement, but we have to work within the confines of what the MC database functionality offers, and the main concern with reading the suggestions is that the database is not a relational database, its basically just a list of files with properties. As such, we don't store any abstract "entities" like an Album, a Series, or a future Composition. They are all virtual concepts created on the fly, based on the files it's currently looking at.
This means that for example a Composition, or an Album, are not "things" in the database, as such they can't have metadata attached directly. Any information about a Composition, an Album, or any such metadata-based grouping concept, would need to be attached to the files within. For the same reason Albums don't have ratings, for example. You could make an argument for a relational Composition field that's their rating, or just form an average rating based on the files ratings, but either are of course more clunky solutions.
We're happy to work within the confines of how the MC database works to support Compositions, similar to eg. Albums, but re-designing the internal database structure to support such abstract entities is out of scope currently, I'm afraid.
wer:
Understood about the underlying nature of the database.
However, JRiver already chose to apply the term "relational" to fields. So Composition can and should have "relational" fields in exactly the same way that Album and Artist currently do.
I have in fact frequently told people who are confused that the Album doesn't really exist as an entity in MC: it's just a bunch of tracks that happen to share field values. Composition would be exactly the same.
The [Composition Rating] field, if that's what JRiver chooses to call it, could be the calculated average of the ratings of the constituent tracks, if that's how you choose to implement it.
The most important point is that it, like other stats like [Composition Duration] (which would just be the total duration of constituent tracks) should be easily, and quickly, accessible through the search language. Currently users would have to use complicated GroupSummaryQuery expressions which are so slow as to be unusable. But MC already calculates stats like this in Category views instantly.
So I was mindful of the limitation you mentioned when I crafted the proposal. I'm talking about things that can be done within the current db framework.
Hendrik:
Thats fine. Some of the suggestions, like the Rating, sounded like there were expectations to have a Composition "entity", with the ability to independently rate a Composition like a track, and I just wanted to make sure.
We can definitely give it handling similar to an Album with additional considerations, once the rules are clearly understood.
sarcanon:
+1 on the proposal here. Also, I would have like wer's automation to be included as well, but I support anything that promotes musical work/composition to be a first-class citizen.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version