Multiple tabs would allow user to have multiple simultanious differing view and nodes/filters/tracklists active at the same time, ideally allowing easy drag/drop exchange between tabs.
But why not then just incorporate the view functionality into the playlist node itself? If the answer is that you may want a different view of the same playlist, then MM could decouple the 'view' option and then put it into a separate dropdown selector or maybe a list of nodes which look like nodes, but actually change view. Tabs aren't needed?
By the way, when I talk about 'view', I mean stuff like position of GUI buttons/icons, and different tag columns displayed (Artist, Album...), or different widths for these. I don't necessarily mean how far down the tracklist slider is - which can easily be made part of the playlist node.
Independent work done in one tab would not affect the other tabs, but any updates of same data should of course be propogated and reflected in other tabs.
A practical example:
Tab 1, viewing several thousand tracks (possibly a randomly generated auto-playlist)
Tab 2, building a static playlist for future burn to cd/dvd
In current MM, switching views will regenerate the auto-playlist, potentially giving an entirely different tracklist.
One could easily add an option to 'freeze' the list... (either via MM or inside the auto-playlist script itself).
With multiple tabs, each tabs view is preserved while still being able to exchange and update tracks from one tab to another.
You could also have multiple tabs with differing playlists to add to now playing list (think dj setup) without having to constantly refresh tracklist from switching playlist in tree.
Not sure I understand fully there, but a good alternative (maybe) is to multiple select playlist nodes, and select add to Now Playling. Some of those could have frozen lists, and others could have dynamically generated ones.
Just to reiterate, I can't see why each playlist node can't be its own 'tab', and where the slider scroll position is kept when you change node. It seems better to unify what we already have, than to branch off further.
[quote]Multiple tabs would allow user to have multiple simultanious differing view and nodes/filters/tracklists active at the same time, ideally allowing easy drag/drop exchange between tabs.[/quote]
But why not then just incorporate the view functionality into the playlist node itself? If the answer is that you may want a different view of the same playlist, then MM could decouple the 'view' option and then put it into a separate dropdown selector or maybe a list of nodes which look like nodes, but actually change view. Tabs aren't needed?
By the way, when I talk about 'view', I mean stuff like position of GUI buttons/icons, and different tag columns displayed (Artist, Album...), or different widths for these. I don't necessarily mean how far down the tracklist slider is - which can easily be made part of the playlist node.
[quote]Independent work done in one tab would not affect the other tabs, but any updates of same data should of course be propogated and reflected in other tabs.
A practical example:
Tab 1, viewing several thousand tracks (possibly a randomly generated auto-playlist)
Tab 2, building a static playlist for future burn to cd/dvd
In current MM, switching views will regenerate the auto-playlist, potentially giving an entirely different tracklist.[/quote]
One could easily add an option to 'freeze' the list... (either via MM or inside the auto-playlist script itself).
[quote]With multiple tabs, each tabs view is preserved while still being able to exchange and update tracks from one tab to another.
You could also have multiple tabs with differing playlists to add to now playing list (think dj setup) without having to constantly refresh tracklist from switching playlist in tree.[/quote]
Not sure I understand fully there, but a good alternative (maybe) is to multiple select playlist nodes, and select add to Now Playling. Some of those could have frozen lists, and others could have dynamically generated ones.
Just to reiterate, I can't see why each playlist node can't be its own 'tab', and where the slider scroll position is kept when you change node. It seems better to unify what we already have, than to branch off further.