Navigator-Suite Feedback, questions, bug-reports or just chatting Options

[Lyx]

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:


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:
 Navigator_v1.4.3.zip ( 97.89K ) Number of downloads: 21802

Old version for foobar 0.8.3:
 Navigator_v1.3.2.zip ( 66.64K ) Number of downloads: 1676


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)


This post has been edited by Lyx: May 21 2006, 15:19

[Tomacco_Boy]

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

[musicmusic]

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..

[Lyx]

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

This post has been edited by Lyx: Feb 14 2005, 02:54

[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.

[dano]

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

[mazy]

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

This post has been edited by mazy: Feb 14 2005, 15:35

[.zolder]

congrats on the release

may it bring enlightenment to many

[mazy]

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:

CODE

$strstr($lower($replace(%_path%,'.',$char(),' ',$char()),'_',$char()),'\va-'),

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?

This post has been edited by mazy: Feb 14 2005, 16:10

[Lyx]

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

[mazy]

great, thanks ...

[Lyx]

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

[dano]

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

[Lyx]

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:

CODE

$strstr($lower($replace(%_path%,'.',$char(),' ',$char()),'_',$char()),'\va-'),

Fixed Codeline in upcoming 1.01:

CODE

$strstr($lower($replace(%_path%,'.',$char(),' ',$char(),'_',$char())),'\va-'),

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.

This post has been edited by Lyx: Feb 14 2005, 19:11

[upNorth]

lyx - i'm with you on that issue with play_date. it would be better (for general configs) to have only one standard form

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.

[Lyx]

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.

[upNorth]

@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.

[topdownjimmy]

@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

[Lyx]

on 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.

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

[upNorth]

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.

[Lyx]

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

[topdownjimmy]

on 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.

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

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).

[Lyx]

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.

[mazy]

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:

CODE

// OST-SUBCHECK
$if($strcmp($get(enable_ost),1),
$if($or(
$strstr($lower($replace(%_path%,'.',$char(),'_',' ','-',' ','\',' ')),' OST '),
$strstr($lower($replace(%album%,'.',$char(),'-',' ')),' OST ')
),$puts(albumartist,'Various Artists')
))

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

This post has been edited by mazy: Feb 14 2005, 23:02

[Lyx]

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

This post has been edited by Lyx: Feb 14 2005, 23:08