Intro
This thread is for feedback, bug-reports or just chatting about "Navigator", a playlist design for Columns UI.

The layout is very modular and can easily be adapted to suit your needs - here is a screenshot which shows a few possibilities of what you can do with it:
Click to view attachment

Description

• usually just works, no matter what you throw at it
• (optional) advanced tag-guess-code
• modular layout: you can enable/disable most columns without screwing up the design
• Singlemode and Albummode (with configurable priority). No last-track tags necessary for albummode(with an obvious naming-scheme Albummode even works with no tags at all!).
• supports the following non-id3v1-tags: discnumber, album artist, conductor, performer, publisher, style, play_counter, first_played, last_played, rating, album rating, encodedby
• multiline display of comment-tags in albummode
• efficient and flexible use of available space in albummode - no line gets wasted.
• advanced playback-stats(requires a standards-compliant play_count-plugin (not the one available from the fb2k-site))
• basic inline-metadata editing capabilities (edit your tags right in the playlist)
• "Metadata-Matrix"-column for a better overview of which files in your collection have which tags
• intelligent column-based sorting of files: sort by completeness of tags, sort by rating+genres, etc.
• very easy to configure
• comes with multiple premade color-schemes and the ability to easily create your own ones
• includes an advanced copystring which makes use of the same tag-guess-code. Amount of copied data easily configurable.
• can be made to occupy less than 25% screenspace on 1024x768

Download
Current version for foobar 0.9.x:
Click to view attachment
Old version for foobar 0.8.3:
Click to view attachment

Important!: You need columns_ui for this to work.


About feature-proposals
I currently have no interest in feature-proposals. This is because i consider the 1.x.x line of Navigator finished. Bug-reports however are welcome.


_______________________________________________________________

Changelog:

1.4.3 (foobar 0.9.x compatible)
- fixed display of singles in albummode for tracks with no ARTIST
- the "artist & album"-column now uses ARTIST instead of ALBUM for inline-metadata editing
- added new colorscheme by 4nt1

1.4.2
- moved albummode STYLE-display into a seperate line
- Tracks which have TOTALTRACKS=1 are now also considered singles
- fixed inverted colors in albummode when displaying: performer, conductor, publisher

1.4.1
- fixed wrong upload (STYLE didn't work)

1.4.0
- compatible with foobar 0.9 and the coresponding ui-columns (no need for legacy mode)
- improved performance by making use of new ui-columns style-features to reduce codesize
- sorting by all kinds of playback-stats works correct now
- added full support for the recently standardized STYLE-tag
- added basic support for inline-metadata editing
- redesigned hybrid-mode
- fixed statusbar display-errors when using RTL-languages
- when enqueueing audio-cds, albummode is now automatically activated
- properly honors the new field-remappings
- many bugfixes and code cleanup
- misc changes to the how-to docs
- probably some other stuff which i forgot


1.3.2 (foobar 0.8.3 compatible)
- bugfix: "daily plays"-column did show wrong values.
- last version for fb2k 0.8.3


1.3.1
- bugfix: in the "daily plays"-column, tracks which were played today the first time would show strange ratios
- finally replaced the ancient screenshot with an up-to-date one


1.3.0 - full support for the new playcount-plugin
- added "plays per day"-stats (new playcounter-plugin required for it to show up). You cannot sort by it yet.
- added first_played-column (new playcounter-plugin required for it to work).
- moved replaygain-indicators from the metadata-matrix into a seperate column
- dropped configurability of the seperator-char, since almost nobody used it anyways
- sorting-code polishing: you can now correctly sort by multiple columns (like for example first sorting by the album-column, and then sorting by rating)

That looks awesome Lyx, will definetly give this a shot and thanks too.

Looks pretty (very) nice, probably first time ive said that at someone elses config as well. Slow as hell though, I dont know what you consider a low-end PC..

Hmm, someone else who did lots of test-runs of it for me has a 700mhz box, and he says it runs acceptable - but i guess your bars are higher because you're a coder :-)

Large parts of the code is non-trackspecific stuff *hinthint*

To be more specific....... the "culprits" for the resource-hog are two:
1. non-trackspecific code - like calculation of secondary colors
2. the tag-guess code eats resources even though its inside a large if-loop which only gets executed when not all standard tags are there - but the parsing alone seems to be heavy already.

Number 2 i will "fix" with a "light-version" (minus the tag-guess code) myself. Number one is out of my hands :-)

Theoretically, given the truckload of code, this should run much slower than it actually does run. I doubt i can do any more except the above two things about it, because i've already tried to save execution-speed whereever i can by putting conditional stuff into if-blocks etc.

---

Oh, btw: reports about scrolling-speed/responsiveness on a variety of systems are very welcome. Please also mention your CPU and OS when doing so.

- Lyx

Updated final 1.00 version. The only change is that it now also includes a "Lite Version" without the tag-guess code, which runs a bit faster.

Lyx you can also ask Neksus for an account or use the upload for unregistered users.

thumbs up!

great work lyx, i like how easy it is to set it up and / or set custom colors (as you compute the rest; there are some limitations because of that's the pay-off for the ease of it).

and i can see that it would greatly benefit from possibility of new non-track specific section in columns ui. btw, have you done any test with that color calculations disabled to see what impact it would have on speed of the string?

because of your tag guessing it's one of few strings i can actually use (the other ones being old plisk's one with custom changes or mine, which is not actually available for columns ui).

so once again, nice work!

edit:
dano - lyx is waiting for his account on that strings' site ...
lyx - i'm with you on that issue with play_date. it would be better (for general configs) to have only one standard form

congrats on the release

may it bring enlightenment to many

lyx: it seems the string doesn't recognize my va albums.

most of them start with 'VA-', like this one: 'G:\Sorted\Samba, Bossa Nova, Brazil & Latin\VA-Bossa_Nova_For_Lovers-2003-ego\'. i'm using your string with album mode as default and tag guessing.

i've quickly checked your string and it seems to me you do look for '\va-' in the path (after stripping off whitespace and separators), so it should work i guess ... any idea?

it's this line:

it seems to me it's somehow broken (not that line, the rest of string in regards to va mode) ...

btw nice way of doing it, i'm mean the way you strip off separators to make it more bullet-proof.

also, i have a feature request: could you add switch like 'treat_ost_like_va', which would cause ost albums to be treated like va albums. ost album would be one with soundtrack genre or '\ost-' (after your stripping) or '(ost)' in its path. '(ost)' is what i use in folder's name for soundtracks, '\ost-' is being used by some scene groups instead of 'va-...(ost)...', 'v.a.-...(ost)...', 'va_-_...(ost)...' etc., you know what i mean, don't you?

mazy, i will look into the va-issue later today to check if its intentional, or a bug (i intentionally don't support some va-patterns because searching for them would trigger too many false-alarms)

The OST-thingie is a nice idea - i'll probably implement it someway.

- Lyx

great, thanks ...

Hmm, i just had an idea how to speedup the code a bit more. Currently, the V.A. check is done for every track, even when albummode is not active. I could change this - but this would make the detection core not redundant anymore, because it would then check for a variable which is not inside of it. Hmm, or i could make it so that it only disables the va-check when albummode is explicitely marked disabled. That way, it would still work when copy'n pasted into another string - the cost would just be wasting one if+strcmp for checking against something which doesn't exist.

I'll probably do that, because extending the VA-code to include stuff like OSTs is just not viable when its done for every track even in singlemode.

So, unless some big sideeffect arises, 1.01 will probably contain a slight speedup in singlemode, support for OSTs and (if its a bug, but i guess it is) a fix for the VA-problem mentioned by mazy.

- Lyx

Does the OST thing stay optional? Not all my OST's are by various artists.

Yes, i'll make an option in the config "Treat OSTs like Various Artists albums?"

- Lyx

edit: mazy, there is a brackets-typo in the code-line you mentioned which causes the va-bug.

Codeline in 1.00:


Fixed Codeline in upcoming 1.01:



Late answer about possible speedup via non-trackspecific global string support in columns ui:
Well, it's difficult to test it, but let me put it this way: With the light-version (no tag-guessing) singlemode is still laggy on my 400mhz box. The thing is, the columns which i had enabled to test it didn't contain much code - so it has to be the global-string. With the tag-guessing removed, 50% of the global string is non-trackspecific code and 15% is exporting vars. So, i'd say its _very_ probable that the two resource-hogs are tag-guessing (fixed via the lite-version) and non-trackspecific code.

Maybe we should start a thread to discuss and agree upon, some "standard" tags for different purposes? E.g. the format of a time/date tag itself, doesn't really make any difference, as its contents can be easily customized for display. If we agree on one format, we could just provide the code needed to display it in different ways.

I think this community could benefit from it in the long run, as changing from one formatting to another would be less confusing to new users.

1.01 uploaded - changelog is in the first post of this thread.


@upnorth:
Agreed. Although imho a balance between "popularity" and "reasonable to support for devs" has to be found. Requiring users to set unpopular weird non-standard tags isn't newbie-friendly as well :-) But thats just details, in general, i completely agree with you.

Yeah, just something that could be used as a guideline.

I've created an "Accepted Tag Standards" section in the wiki, so please add any standards for which you come to a conclusion. I've already included what I expect will be the PLAY_DATE standard (YYYYMMDD), but please correct me if I'm wrong in that.

http://wiki.hydrogenaudio.org/index.php?ti...d_Tag_Standards

In general, i'm all for the ISO-version (YYYYMMDD). But my proposal would be to make it "YYYY-MM-DD", because that way, it can be verified with TAGZ (by checking the position of the seperators). As a bonus, it also makes it easily readable even without processing.

- Lyx

I don't remember the contents of the default PLAY_DATE tag, but wouldn't it be nice to append time info to it ($H$M$S or something)? No need to add (waste) another tag just for info that can be stored in the first. I don't really use time info myself, but I'm considering adding it when I change format (something I'm about to do).

Maybe there isn't enough people that cares about this, but at least I want to think it through before I abandon my current format.

the default content is DDMMYY if i remember right. The european-version... just to make absolutely sure that the majority of users will change it to something else anyways(thats the main cause for the problem - if it would have been ISO by default, then it would be easy to say "i only support the default" - but since the default is geared only towards europeans, its understandable that users will change it to an unknown format).

(this is not to say anything against europeans - i'm from germany - but picking this dateformat for an international app which supports other "plugins" which make use of it, is just..... weird)

- Lyx

Can quantitative comparisons be made on strings containing hyphens? I'm at work, so can't test :/

upNorth, if the time were to be included in the PLAY_DATE field, how do you suggest the entire field be formatted? I think this would be best because then if someone enjoys having a timestamp but wants to make their second playcount field available for some custom tag, they won't be forced to violate the standard (by appending $H$M$S to the standard YYYY-MM-DD or whatever).

...and because the field would then contain both date and time, would PLAY_DATE still be an appropriate field name? Perhaps with a new standard a new field name is in order (e.g. LAST_PLAYED).

Sidenote: When deciding about a standard, it should also be considered how easy it is for users to switch to it. Thus, the more easy, less disruptive and more attractive the transition, the better the chances of widespread use.

Creating a completely new tag-field may be a bit hefty to enforce. Thats what i meant with "a balance between popularity and reasonable-to-support for devs".

BTW: i just created a thread to discuss this topic.

i'm too for YYYY-MM-DD, it's better to have more significant part first for sorting and other stuff. and with separators you could do some safe-check, as Lyx said.

as for appending time - it's probably a good idea, but i'm not sure other users would agree on that.

edit: Lyx, thanx for implementing that ost feature i've requested. there's a typo in your code though:

' OST ' should be in lowercase. thank you for your work!

Thats not a typo, thats intentional. :-)

Otherwise, it could cause all kinds of false-alarms, because contrary to VA, it can be written anywhere in the foldername or albumname - its not usually positioned at the beginning.

"ost" for example means "east" in german - so, a string like "ost-something" would trigger it. But when its all in caps, then its quite probably that it indeed means "soundtrack".

- Lyx

ah, i see ... but you do $lower on it, so it wouldn't work ... (going to change ' ost ' to back uppercase and remove $lover )

good call - that was quite stupid of me - i just copy'n pasted the line from the VA-checking and forgot to remove that unnecessary function. Will be fixed in next version. Thanks for pointing that out.

- Lyx

Lyx, as for speed-ups, i think we should bug musicmusic about that non-track specific globalstring. it could get distinct tab called like 'non-track specific variables' or something like that. now how should it interact with global string? would we need variables from it to be accessible in global string ('variables'), or just apped its list of exported vars to list from global string for use in columns?

also, it would be nice to have this accessible in other places. i think that atm it would be enough for musicmusic to provide service which would return list of these exported variables from non-track specific global string. 3rd party components could look for this service, and if available, get that list and then use it as extra parameter in their calls to formatting routines (that's possible and easy to do with current sdk). or - musicmusic could provide custom / modified formatting routine for others to use, but that wouldn't be that 'clear' way to do it.

this could be helpful for (until we could have foobar-wide custom vars or even functions) synchronizing color themes amongs components like track info etc.

we could go even further and have similar service for track-specific (maybe a new one, not columns ui oriented as 'variables' global string is) global string, which could contain tag guessing and other stuff, which you would like to easily use at other places too ...

and - extra nice feature for speed-ups, though it would require quite a lot of work to implement, would be to disable parts of 'variables' global string based on changes to previous track.

that would require something like '$changed(<string to evaluate>,<true-branch>,<false-branch>)', for example '$changed($left(%_path%,$sub($len2(%_path%),$len2(%_filename_ext%)))|%album%,<album-wide code>,$reuse(album_mode))'.

columns ui would have to parse string and find those $changed parts and its params. then it would evaluate <string to evaluate> for current track and last displayed track. in case they are not same or that there wasn't any previously displayed track, it would execute <true-branch> using foobar's routines, <false-branch> otherwise.

in my proposal, <false-branch> could contain list of names of previously exported variables, which would get reused, so they would get exported in current pass using value from the last one. that's just first idea, there are many things to work out / discuss about ...

that's just one idea i had, it's probably way to complicated or of minor use, but it could help ...

Tagz is a coding language

Its probably my different habits - I like to use page up/down keys to navigate, with will load more tracks at once, and maybe my laptop's processor is melted also.

Lets not turn this into a columns ui thread Developments in that area will come in due time (yes i know its been long enough as it is)

Well probably the general overhead of parsing the script, or something, I dont know. But you're not going to make a "do-everything" script that is fast without rewriting the tagz engine or something. Of course a non-track specific string will help significantly, though.

@mazy
Mmh, i'll try to make the situation and my point of view simple:

Preferable, there should be a centralized config-manager which provides this service.

Well, thats the idea since months, musicmusic said that he doesn't have time to create and maintain such a plugin, and no one else is able and willing to do it. So lets be realistic: we won't get the "preferable" solution anytime soon.

Because of this, i agree with you that it should be implemented into ui_columns instead. Because thats still much better than having no global control-service via global-vars at all - and its desperatelly needed, not just for formatting strings but perhaps even more for controling stuff like colors from a central place. The panel-hell won't become better, only worse, so the earlier the better.

In what my opinion differs from yours is not the idea itself, but the implementation: I'd go for a KISS-approach. Just have one more tab in the ui_columns globals page called "vars (non-trackspecific)". After parsing its string, it will just export vars just like the trackspecific global string. It would also automatically make the exported vars available to the track-specific global string. The track-specific globals string in turn should be able to overwrite vars exported from the non-trackspecific global string. These are instantly available to ui_columns itself (just as it is now) - BUT, additional ui_columns gets a service which makes the exported non-trackspecific vars also available to other plugins and panels.

Technically under-the-hood, this means that there are two var-tables.... each of them can contain vars with the same name, but different value. This is because the non-trackspecific string gets executed only one time(possibly only when selecting a playlist) and then creates a read-only copy of its exported vars...... these vars then can be called from the trackspecific global string - and overwritten - but in reality, they're not overwritted but instead stored in a 2nd var-table..... the trackspecific one.

I dunno if this makes sense.

- Lyx

yep Lyx, that makes sense ... and that's one way to implement it that i was thinking about. i don't know what would be easier for musicmusic to implement though ...

making results from non-track specific global string available in track specific one is easy, but merging them would take some work. it's probably not a big issue and you're not going to have lots of variables, so you could use simple look-up method when merging them, but because of my education it would be against my habit to do that, ehm . how would musicmusic implement this?

how about an option to display just the artist and track when you hover the mouse over the systray icon? it currently displays quite a lot of info and for me at least seems to vary what info it displays randomly.

I forgot to mention that in the docs, but you can do that already. Open the prefs->titleformatting and switch to the systray-tab of that page. At the top of the string which gets then displayed you can enable/disable each line which gets displayed in the systray.

I'm sorry, its currently technically not possible to make this configurable from the globals-string in ui_columns..... among other things, thats what mazy and i were discussing: the ability to control other stuff than the playlist from one single config-section in the ui_columns globals page.

- Lyx

edit: oh, i forgot to mention - you may need to disable and then reenable the systray-display to see the changes.

thanks, i really like this fcs.

Thanx Lyx,
just when I thought I had Foobar how I wanted it !!!

Sweet fcs, Lyx! Much classier than my own.

Performance is fine in full album-mode with a playlist of 28000 songs on my XP 3200+. All of my songs are full tagged, though, so I can't imagine there's much tag-guessing going on.

I should have been really worried if any kind of lag is visible on a 3200mhz machine ;-)

In the normal version, a bit of performance is always taken away by the tag-guess code - thats because even if that part of the fcs is skipped when all tags are there, then even "skipping" that part still takes about 1/4 of the speed which would be used when it would indeed guess tags. Or more simple: even skipping tag-guessing takes a bit resources. Thats why on lowend machines a difference is perceivable when using the lite-version, even with fully tagged files.

Then again, having tag-guessing as a backup kicking in when its needed has some advantages :-) While designing the albummode i stumbled over a possible bug a few days ago.... i thought "hmm, i wonder if i remove the artist tag if the lines in the album-column would then get out of order"..... so i removed the tag...... but nothing changed - then i remembered that tag-guessing was enabled ;-)

- Lyx

thinking about tagz, it would be great to have some kind of pre-processing function in the core, which would make some sort of derivation / parsing tree.

you would call that function for string, which you're not going to change that often (ideal for playlist string) and it would return you some data about it.

then, when displaying the string, you would call new formatting routine, which would take extra param - these data.

it could use them to quickly skip to next token etc ...

what do you think? this could really speed things up, but peter would have to implement that himself ...

Umm, i'm sorry i can't follow your idea? The only thing i understood was that it sounds like some serious magick ;-)

- Lyx

edit: actually, although it doesn't look like it - i'm really bad at coding and not very knowledgeable - its all just intuition :-)

sorry Lyx, i know i go way to far sometimes .

you can imagine result of that pre-processing for example like data, that would tell you for left bracket on given position where is (=position) corresponding right bracket etc.

you could store this info for brackets, string constants, parameters of tagz functions in the string etc.

it would help you with evaluation of the string. for example when you come to $if and evaluate its condition as false, you could jump right to false-branch of that $if instead of doing parsing of the string in between. in other words, when skipping large parts of code because of $if, you wouldn't have to look for where to continue by inspecting (parsing) the string, but you *would* know where to continue right away because of the look-up table (in reality it doesn't have to be a table).

parsing is probably quick enough, but for huge strings repeated over and over it can slow things down (as you saw for yourself - disabling large chunk of code doesn't give you same speed-up as actually deleting it).

this, combined with global non-track specific string could help a lot in columns ui ...

Okay, now i understood what it does, but not "how" :-) But i guess thats natural for me, because i'm actually quite bad at maths and complex-systems. As long as something is intuitively imaginable my brain works great - but as soon as it becomes too abstract and complex i fail miserably (don't ask me how i got that tag-guess spaghetti-code to work ;).

- Lyx

hmm, can i have IFs inside of a $strstr and $replace? like this:




That would allow me to cut the size of the VA-code in half. Maybe there is an easier solution than using cascaded IF2s.

- Lyx

edit: nevermind - found a much easier less resource-hungry solution.

Hi Lyx.

Just downloaded Navigator 1.01 and I really like it.

Using "singlemode default", how can I remove the album info from the artist column?

Thanks for your help.

Alessandro

Just rightclick the column-headers - there you can enable and disable every column.

For example, there is:
Artist
Artist & Album
Album

"Artist & Album" is enabled by default, and the artist- and album-columns are disabled by default. But you can also make it the other way around :-)

- Lyx

Awesome config, i will try it!

Soo easy!

Thank you!

Alessandro

updated to v1.02 - changelog is in the first post of this thread.

I will probably not add new features for a while and only fix bugs when they're found and optimize the code. Instead, i'll work on a trackinfo-panel string in the next 1-2 months.

I had been using eriks3 format string for quite some time, so when I switched over to Navigator I really wanted to keep the same color scheme. So, I whipped this up:



And here's a screenshot.

Hope someone enjoys it.

cool, thanks for sharing this one.

Now, if i would include it in the next version, how should i call it? Also, since you mention that the scheme is from another FCS how to handle the credits?

edit: the way you made the highlighted (primary) colors appear like the secondary by defining it as a dark-scheme instead of a bright one is interesting

As far as I'm concerned, you can just give the original author credit, I'm not really worried about seeing my name. So I guess you'd just call it eriks3, or 4, or whatever.

Edit: Also, I've just noticed that when it's defined as a dark theme, the stars on the rating column look really awful. If you set a song to a 4 rating, 4 stars are light grey, and 1 is black. Personally I think that's backwards. But if you set it to a light theme, it looks fine. Just thought I'd point that out...