Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Sugested feature ... tree browsing.
16-04-2015, 10:15 (This post was last modified: 16-04-2015 10:20 by audio_elf.)
Post: #1
Sugested feature ... tree browsing.
I'm writing this thinking aloud slightly but here goes.

Currently as far as I'm aware there is no way to have tags in the browse tree appear only within certain other tags... for example "Movement" really has no meaning unless you have already browsed for "Composition".

Is there any possibility you could implement so that (for example) the top level / second level tree would look something like (in my own tree)
Code:
[n] albums; [n] items; [n] playlists
Artist
All Artists
Decade
   |-- Year
Genre
Composer
   |-- Conductor
   |-- Orchestra
Composition
   |-- Movement
Collection
   |-- Collection Album Name
AudioQuality
AudioData

So in my example the tags Year, Conductor, Orchestra, Movement and Collection Album would only appear within the higher selection. I would imagine that on the properties you could have an entry something like
Code:
Composer, {Composer}Conductor, {Composer}Orchestra
(exact syntax doesn't really matter).

As I say I'm just thinking out loud and its a minor inconvenience. It would also be good if there is flexibility in the ordering of the tags so when (for example) I choose Collection* in the tree then Collection Album Name would be towards the top - so ideally: [n] albums; [n] items; Artists; Collection Album Name; et al. I'm imagining the indexTags would look (for me) something like
Code:
{Composition}Movement, Artist, {Collection}CollectionAlbum:Collection Album Name, All Artists, Composer, {Composer}Conductor, {Composer}Orchestra, Decade, {Decade}Date:Year, Genre, Collection, #AudioQuality, #AudioData

Thanks for reading my ramblings...
Eloise

Note *: Collection is an additional tag I added for certain albums which form a collection - for example all the Society of Sound recordings have a Collection tag and then the CollectionAlbum tag is used as like an alternative sorting order with (in the Society of Sound case) the release number first so Album:"Undercurrents [Society of Sound:82]" becomes CollectionAlbum:"82: Undercurrents"
Find all posts by this user
Quote this message in a reply
16-04-2015, 16:27
Post: #2
RE: Sugested feature ... tree browsing.
(16-04-2015 10:15)audio_elf Wrote:  I'm writing this thinking aloud slightly but here goes.

Currently as far as I'm aware there is no way to have tags in the browse tree appear only within certain other tags... for example "Movement" really has no meaning unless you have already browsed for "Composition".

Is there any possibility you could implement so that (for example) the top level / second level tree would look something like (in my own tree)
Code:
[n] albums; [n] items; [n] playlists
Artist
All Artists
Decade
   |-- Year
Genre
Composer
   |-- Conductor
   |-- Orchestra
Composition
   |-- Movement
Collection
   |-- Collection Album Name
AudioQuality
AudioData

So in my example the tags Year, Conductor, Orchestra, Movement and Collection Album would only appear within the higher selection. I would imagine that on the properties you could have an entry something like
Code:
Composer, {Composer}Conductor, {Composer}Orchestra
(exact syntax doesn't really matter).

Thanks for this suggestion.

A key feature of MinimServer is that you can browse by any tags in any order at any time. This differs from other servers that provide a "browse tree" in which some tag choices need to be made before other tag choices become visible. This is an intentional difference of philosophy and design and I would need to think very carefully before making this change to MinimServer.

Quote:As I say I'm just thinking out loud and its a minor inconvenience. It would also be good if there is flexibility in the ordering of the tags so when (for example) I choose Collection* in the tree then Collection Album Name would be towards the top - so ideally: [n] albums; [n] items; Artists; Collection Album Name; et al. I'm imagining the indexTags would look (for me) something like
Code:
{Composition}Movement, Artist, {Collection}CollectionAlbum:Collection Album Name, All Artists, Composer, {Composer}Conductor, {Composer}Orchestra, Decade, {Decade}Date:Year, Genre, Collection, #AudioQuality, #AudioData

Thanks for reading my ramblings...
Eloise

Note *: Collection is an additional tag I added for certain albums which form a collection - for example all the Society of Sound recordings have a Collection tag and then the CollectionAlbum tag is used as like an alternative sorting order with (in the Society of Sound case) the release number first so Album:"Undercurrents [Society of Sound:82]" becomes CollectionAlbum:"82: Undercurrents"

I don't think revealing a "hidden" tag should change the position of this tag within the list. If you want the prevously hidden tag to appear near the top of the list when it is revealed, you could give it this position in the full indexTags list.

As well as the simple case you have described, there are other related cases that aren't quite so simple, such as:
  • revealing a tag only after one of a specified list of tags has been selected: {A or B}C
  • revealing a tag only after all of a specified list of tags have been selected: {A and B}C
  • some combination of the above: {A or {B and C}}D, {{A or B} and C}D, etc.
Supporting these cases would require a more complex syntax that probably wouldn't be appropriate for indexTags.
Find all posts by this user
Quote this message in a reply
16-04-2015, 20:22
Post: #3
RE: Sugested feature ... tree browsing.
(16-04-2015 16:27)simoncn Wrote:  As well as the simple case you have described, there are other related cases that aren't quite so simple, such as:
  • revealing a tag only after one of a specified list of tags has been selected: {A or B}C
  • revealing a tag only after all of a specified list of tags have been selected: {A and B}C
  • some combination of the above: {A or {B and C}}D, {{A or B} and C}D, etc.
Supporting these cases would require a more complex syntax that probably wouldn't be appropriate for indexTags.
Thanks for your reply Simon. I do love the flexibility that MinimServer offers with the tagging ... Become a bit of a labour of love (or is it OCD) on my part getting all my tagging sorted. None of this is vital to my use of MinimServer and I'm unsure if such a feature would be of any interest to other, so just thought I would put it forward as a suggestion.

I can see what you mean about the more complex extensions... The simple version would be all I need, but once you start that then it's a bit of a can of worms.
Find all posts by this user
Quote this message in a reply
16-04-2015, 22:42
Post: #4
RE: Sugested feature ... tree browsing.
(16-04-2015 20:22)audio_elf Wrote:  Thanks for your reply Simon. I do love the flexibility that MinimServer offers with the tagging ... Become a bit of a labour of love (or is it OCD) on my part getting all my tagging sorted. None of this is vital to my use of MinimServer and I'm unsure if such a feature would be of any interest to other, so just thought I would put it forward as a suggestion.

I can see what you mean about the more complex extensions... The simple version would be all I need, but once you start that then it's a bit of a can of worms.

Thanks! I will continue to think about whether there's a reasonable way to provide a simple version of this without leading on to opening the can of worms.

In your example, I can see that you might always want to select Decade before Year, Composition before Movement and Collection before Collection Album Name. I would be surprised if there's never any occasion when you might want to jump straight to a particular Conductor or Orchestra to look at everything they have performed by all composers.
Find all posts by this user
Quote this message in a reply
16-04-2015, 22:56
Post: #5
RE: Sugested feature ... tree browsing.
I expect your right about the conductor / orchestra part...
Find all posts by this user
Quote this message in a reply
19-01-2019, 19:43
Post: #6
RE: Sugested feature ... tree browsing.
Late request/question along similar lines to the OP. I invariably want to select an album, and I do this by choosing genre/artist/album. The default way of making this selection is 5 choices. (Choose genre, choose which genre, choose artist, choose which artist, choose album). Is there a way of configuring MinimServer so that this decision tree is reduced to only 3 choices (Choose which genre, choose which artist, choose which album)? Sorry if I haven't understood the tagging and intelligent browsing concepts. Still the best music server!
Marmite.

Server :: RaspberryPi3B+>Minimserver 2
Control : Android>BubbleUPnP / W10>Upplay / W10>Kazoo / iPhone>Kazoo
Renderer: BubbleUPnP Server>Cambridge Audio CXN V2
Find all posts by this user
Quote this message in a reply
19-01-2019, 22:21
Post: #7
RE: Sugested feature ... tree browsing.
Thanks for asking. It isn't possible to configure MinimServer to do this. The "tree" concept doesn't fit easily into MinimServer's Intelligent Browsing design.
Find all posts by this user
Quote this message in a reply
20-01-2019, 15:32
Post: #8
RE: Sugested feature ... tree browsing.
(19-01-2019 22:21)simoncn Wrote:  Thanks for asking. It isn't possible to configure MinimServer to do this. The "tree" concept doesn't fit easily into MinimServer's Intelligent Browsing design.
I understand. Thanks for a good product.
Marmite.

Server :: RaspberryPi3B+>Minimserver 2
Control : Android>BubbleUPnP / W10>Upplay / W10>Kazoo / iPhone>Kazoo
Renderer: BubbleUPnP Server>Cambridge Audio CXN V2
Find all posts by this user
Quote this message in a reply
21-01-2019, 11:42
Post: #9
RE: Sugested feature ... tree browsing.
What about instead of browse tree as such just a way to restrict what is shown under a tag. So by default any specified tag can be browsed under any other tag if data exists as it currently the case.

But allow the user to restrict in some way

i.e only show movement tag under work tag
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)