Okay. One problem: while declaring it as a dark-scheme looks nice with the tracknumbers, it makes the calculation of the "special-color" go wrong - with the result that the tag-matrix and rating columns dont work (it will always look as if everything is enabled).

- Lyx

edit: fixed it

Can I see what you changed, out of curiousity? Did you just switch it to a light-scheme?

Nope, i made the special-color cyan with medium-saturation - thats makes it recognizable in the metadata-matrix and ratings, yet still fits to the rest of the color-scheme.

But i will probably do a different approach in the next days. Your color-scheme (or eriks made me thinking that it may look better, to generally make the tracknumbers and time "weak" and the tracktitles "strong" in albummode. So, i will probably change that in the column-code itself, so that it isn't necessary anymore to declare color-schemes as dark to get this effect.

- Lyx

I really liked this Fcs, i did some color changes my own, without dark-scheme:




looks like this,

link: http://img.photobucket.com/albums/v674/cche/teste.jpg

Comanche
Your link isnt working for me

retry using the alternative link please, i sended to another host.

Just a thought, and I don't know if it's feasible or not (although I would imagine it is), but it would be nice to be able to choose the two colors the FCS uses when row-stripes is enabled. As far as I can tell, currently it simply darkens by a certain amount the one color already chosen for the background. Anyone else think this'd be a nice feature?

Can't seem to get the ext and quality tab to display.

I have installed the modified foo_input.dll

Is there a chance of adding in the trackrating column based on the playcounter value instead of trackrating (i dont use trackrating on my mp3s) like this bit o code i found in one of the forums

On first sight, it may look like something easy to implement. But when looking at it a bit closer, its almost impossible to do without strong disadvantages.

The reason for this is the following: It may not look like it, but Navigator uses up to 30 colors in total for the display. Thats why it looks less "flat" and "painted" than i.e. azrael when stripes are enabled. So part of why Navigator looks so nice on first sight - no matter which color-scheme - is the heavy use of sub-colortoness. I can write a long story about expieriences with an earlier FCS which tried to make more stuff configurable to the user, but that would become a long story with too many unnecessary details, so i'll make it short:

With a color-scheme "engine" which makes use of many sub-colortones, you can either have one of the following:
1. Its very configurable, looks great, but crawls like hell
2. Its very configurable, looks ugly, but runs really fast
3. It only allows the user to set the basic-colors, looks great and runs at medium speed

In short: the more colors you make configurable to the user, the more difficult it becomes for the "color-scheme engine" to automatically calculate the other colors in a way which looks nice. So, the more colors the user can input, the more unpredictable and "trial & error" the result. Either that, or you need to throw a truckload of additional calculations into the game which makes the whole FCS crawl. I did just that in the precursor of Navigator - it wasn't fun at all.

- Lyx

Works for me. They're even displayed by default after importing. Maybe check if you have an old version of ui_columns?

- Lyx

edit: both are not displayed in albummode, because the fileformat and quality info is already displayed in the albummode-column. So, having those columns in albummode would just waste space with duplicate-info unless the "album" consists of mixed fileformats. If you need this data for each individual single track, then switch to singlemode.

Problem here, is that the _scale_ will be different for every user:
for user-A, 25x played may be lots already, but for user-B 25x played is low and 100x played is high. That would mean having not one but two additional options in the config. I'll think about it, but dont hold your breath. If play-date gets a standardized ISO-date, then its more probable that i do implement something like the "hotness"-proposal in an additional-column.

- Lyx

Ah,that explains it, i was in the album mode display.

Thanks!

updated to 1.03 - changelong as usual in the first post.

If you did create your own color-scheme, please backup it to a txt-file before updating.

When sorting by play counter, as the single digits have no leading zeros, 3s turn into 30s then to 4s which then become 40s and so on....

would there be a way to give the option for selecting the number of leading zeros (0,1,2,3...)?

or is there a workaround that I am not aware of.

TIA,
addicted

Sure, i didn't think of that - will be fixed in next version. Thanks for pointing that out.

edit: manual fix until that version is out:
In the ui-columns preferences go to the columns-panel. Choose the "Count"-column and then the "sort"-tab on the right.

replace %play_counter% with $num(%play_counter%,5)

Lyx, i have feature request regarding tag guessing. it doesn't recognize tracknumbers in filename in form 101-, 102-, 201- etc., it's being used for some multi-cd releases. could you add that?

i know, i want too much , you should see my old tag guessing code, hehe. i guessed not only track, but also disc#, so i could show only album name for cd 2 and so on, saving space and making it more visually clear that it's just part of multi cd release ... (old screenshot here).

heck, i should finish my tag guesser

I'm sorry, nope - that would make the tag-guess code double the size as it is now - and 3digit-tracknumbers are too rare to justify the performance-impact for all other users. If i remember back when i wrote the tag-guess code, i think at that time i also didn't implement it because false-alarms were a possible problem (remember, you cannot do bullet-proof pattern-checking like you can do in LUA with TAGZ - you need to keep it "inaccurate" to allow some error-tolerance with acceptable speed).

The indent-idea for double-CDs is interesting, but that would only look nice when you have all CDs of a multidisc-album enqueued right after each other - otherwise it will look strange.

- Lyx

yeah, i know ... but i did that even in my old formatting string. only for files without tracknumber, then it would be quite safe to interpret 3-digit filename prefix as disc#track#.

but of course, it would slow things down for most ppl and help only few ... stupid me, i can run my tag guesser on it to tag it correctly

what's really difficult is guessing track# for files with vinyl-style filename, there's no safe way to do it on track by track basis.

How much faster is tag-guessing in LUA?

it is faster, but i do way to much in it and on per album basis, so it's not meant to be used in realtime, but as sort of automatic processing ...

So, if one would use it only for those tasks which i do, then it should give a speed-boost, right? Especially since one can search for..... how was it called again..... for example, direct searching for numbers instead of the $upper/$lower hack.

Are there ways yet to get tags only written to the DB and not to the files themselves?

- Lyx

well with current sdk, all you can do is to tell the core not to update tags in the file (we have discussed that before) - and that's available in that foo_lua plugin too.

you can do much more, faster and without all kinds of hacks with foo_lua. for example complete, unicode compatible regular matching / replacing is available.

for example, i use these arrays of regular expressions to extrack tracknumber and the rest of filename for later processing:

once you get into it, it's really easy and powerful. my goal was to transfer almost all advanced guessing and some additional calculations (which are not possible on track by track basis - total no. of tracks, real average bitrate, no. of discs, real va album indicator etc.) to lua script and use easier and more advanced (in the sense of using advanced info) display formatting string.

the project is usable atm, but i haven't been working on it for a long time and i still want to recode it in better way and add some more features. few things are preventing me from putting more effort into it - stopped development of foo_lua (there are few things i would like to be added to foo_lua), the state of things in regards to foobar's database etc.

edit: btw i block updates to db (my collection is mostly releases which i do not want to retag), so i don't really care much about adding these additional tags etc. that tag guesser can do the work most of the time with no effort from my side, so it's great for quick correction etc. my final goal is to recode it together with my tag export / import script so i could easily backup hand-edited tags, replaygain info or statistical tags like play_count. of course once foobar's db changes to support db-only info, it would be much easier to do all kinds of things ...

But as soon as someone changes the other tags in a file, or chooses "rewrite tags from DB", the db-only-tags will be written to the file, right?

- Lyx

yep, of course ... we've been talking about this before and i said what i see could have been done with current sdk, but its all hack-ish.

that db-only thing is really temporary, i think it was meant to be used to disable immediate updates to the file in case of multiple changes in short time, or for adding tags that are not crucial and user wouldn't mind loosing them in case of crash and db failure ...

edit: you can read my post about that here

Bummer. So the situation is still the same - i'll stay with how it is for now, and when the SDK gets updated to allow plugins declare db-only-tags in the DB, then i may replace the TAGZ-tagguessing with LUA-code....... plus some other stuff - for example, "walking" the comment-tag for multiline-display in albummode should be much more simple and fast in LUA than it is with TAGZ. Not just that, because the results are stored in db-only-tags, they only need to be regenerated when files change - which means one would only need to guess tags one single time for a file, instead of again and again.

you're welcome, just helping iron things out as best i can, i appreciate your work and time.

the $num string isnt giving the expected results here. i'm still going from 17,18,19,2,20,21,22,23....

i replaced things as you said in the appropriate spot, and the files are tagged properly (play_counter=2 etc)


thanks,
addicted

Weird *checks again, because that should usually fix it*. You did re-sort after applying the fix, right?

sorry, my bad. I was sorting by the toolbar sort option but using %last_played% as the formatting pattern, as i hide the column headers. i put that sort srting into that field and it sorted just fine that way too as expected. wow look at me learn lol


thanks Lyx,
addicted

np :)

Great fcs!

This is probably dumb but... The album formatting works great when adding albums from the album list:



but not at all when adding them through Play in foobar or Enqueue in foobar from Explorer:



This happens with all albums, VA or not.

What am I doing wrong???

I have a suggestion too, how about changing the background color to something matching the theme background instead of the clashing black? Is that possible through the theme string?

I am using Navigator 1.03 album default mode.

Update: The same behaviour where the album formatting is lost happens when loading the album by right clicking in the Album list and choosing Send to playlist. The only way it looks right is by double clicking in the album list. Weird.

You probably have fb2k set to automatically add "incoming files" to the playlist named "Default"....... default automatically is shown in singlemode, even with the albummode default version. Thats intentional, because most people use this playlist for quick-adding mixed tracks. If you don't like that, then go to the preferences->core and look at the "always send to playlist" option - change "default" to something like "incoming albums" or whatever you like (the name doesn't really matter, as long as it does contain "-a-" or "album".

About the background - sorry, currently not possible with ui_columns. The string has no access to the "basic colors" like i.e. the background color. One can only change it manually in the ui_columns prefs with a color-picker.

- Lyx

edit: forget what i said about the playlist name - i was thinking in "singlemode-default"-mode ;-) just call the incoming playlist however you like as long as its name does not contain "-s-", "single" or "default".

edit2: sigur ros on a jazz-CD?

That's what it was, thanks a lot.

Just to comment on the date/time format stuff mentioned earlier in this thread:
I suggest to stick to the ISO 8601. There's not realy a need to start using a different format again when there is a common and recommended format available already.
The ISO 8601 format is the following: "YYYY-MM-DDThh:mm:ss". This includes the hyphen in the date to have the advantages mentioned earlier by Lyx. Using the capital "T" clearly separates the date and time, so does the colon for the different time parts. The only problem might be the T though...since having that displayed might not be everyone's preference. You could deviate from the standard by leaving it out the have the parsing advantages but deviating from standards isn't something I prefer at all.

Anyway... Just my 2 (Euro) cents

Something very similiar to that has already been agreed upon - see here:
http://www.hydrogenaudio.org/forums/index....showtopic=31530

In the 'Playlist view' tabs of the ColumnsUI preferences, click the 'Playlist view display settings' button and select 'Exposed background colour'. Voila. Took me a while to find that too, and yes the default black is rather hard on the eyes if you ask me.

well, i could change the default to dark-grey. Making it brighter would make dark-schemes look ugly. There's not much more i can do about it, because as i said, the strings have no access to the playlist background-color - they can only change the colors of track-rows - thus, there is currently no way to change the bg-color based on the selected color-scheme - unless i make every color-scheme a seperate fcs - i'm already maintaining 4 FCSs and that slows down updates quite alot (thats why i'm now "collecting" fixes and changes and then apply them all together in a new release).

Perhaps you could give instructions on how to change it somewhere in the included html file? If it's a common enough question, anyways. Might be helpful.

Lyx

May you change sort of Pos. column to [%_path_raw%].

In this way you can sort playlist from first song to last and also reverse mode.
This is usefull when I want restore original playlist order after sorting by any columns.

Hmm, but this would only work if the default sort-order for incoming files is also %_path_raw%, or not?

- Lyx

To Lyx

When I add all files from any directory (usually it is all songs from album) - order of this files in playlist is according to full file name including path and protocol ([%_path_raw%]).

Then I may sort my playlist by any criteria.

When I want return to initial playlist order - I sort playlist by Pos. with sort rule ([%_path_raw%]. (from first sont to last or last song to first).

Yes, but the problem is that not everyone is using your settings :-) But i will look into how to improve the current sort-criteria, because it doesn't really achieve anything right now

I'm not sure if this is possible with columns UI or not, but i'd like it of the album column and the title column resized together, kind of "maintaining aspect ratio" type thing. if i click the toggle area on the left of the side panel and the playlist expands, it would be cool if those two columns resized at the same rate. is this a possibility?

Thats how it was at first, and i changed it before the release because it did look bad imho. Especially since the width for multiline-comments is fixed. You can change it yourself by going to the columns-tab, choosing the albummode-column, and then on the top right change the "resize" value to something else than 0.


Tracknumber-display in singlemode will be fixed in next version - i'm suprised that no one mentioned it yet.
- Lyx

Actually, the ISO 8601 standard allows for a variety of notations. The page you linked to is not the standard itself (you have to pay ISO to get that), it only gives examples. According to this report on the standard the letter "T" is optional:Thus it seems to me that the proposed format does not violate the ISO 8601 standard; omitting the "T" also does not lead to ambiguity in this case (since the used components, precision and delimiters are fixed).
Personally, I prefer to use a space instead of the "T" in a combined data/time format whenever possible, since the "T" joins the data and time portions into one solid, hard-to-read (for human eyes!) block of characters. The author(s) of the APEv2 tagging format apparently felt similar about this.

Well, the recommended format for play timestamps has already been decided upon, but perhaps this post can help you accept it.

Between the lines, we do already exactly that. Although it is not "officially" accepted and not part of the agreed tag-standard, exchanging the space with a T would probably not break anything, because:
- when validating the format, we avoid checking the space - validation in the proposed code-snipped depends on the year-format and the appended dash, and the position of the first collon in the time-part. Thus, the tag would still validate even with a T in it.
- when splitting up the timestamp, we also avoid touching the position where the space is.
- when displaying either time or date only without reformating, we as well dont touch the position where the space is.

So, even if someone would "break" the agreed standard, then it still wouldn't break anything in the formatting/plugin - with the exception of sorting: having mixed versions of the tag (some with T, some with space) would mess up sorting(without reformatting).

Short version, it is strongly unrecommended to change anything to the format itself (except of appending stuff after the timestamp) - but in case someone would use the T, then it wouldn't make the world end ;-) But don't take this as a guarantee - while the example code-snippets don't depend on it, someone else may write code which depends on it.

- Lyx

Why not just set the default exposed background color to match the default theme and then explain in the html file how to change it? I set mine to the darker stripe of the default theme, 55 60 85, and it looks great.

I've installed Navigator a couple days ago and I'm really impressed. It's been growing on me ever since. Great work.

major update - changelog as usual in the first-post - backup your custom color-schemes before upgrading

Besides of many other changes, this version drops support for many exotic-tags. I guess an explanation is in order: When i began writing formattings - back to the days of "Gems" - it was my impression that the reason why so many different ways did exist to do the same thing was that users and developers were just in an ambigious situation or couldn't know better(everyone was a newbie once) - and that possibilities were missing to standardize things. In other words, that users and non-commercial devs were mostly innocent about the situation.

This was the reason why i began to support all kinds of different ways to mark stuff - users shouldn't have to live with incompatibility when it wasn't their fault. And so i began to write FCSs which would work no matter how the users does mark, name and sort his files. This made my formattings slower than those of others - but that imho was still better than incompatibility.

However - while i understood the "effect" quite well, i heavily underestimated the "cause": We have another installment of "overally, everyone gets what he/she deserves" here - the cause are the same people who are the "victims"(users as well as devs). This changes the entire fundament of why i initially began the "compatibility-with-everything"-approach. Thus, i see neither reason nor motivation to continue spending dozens of hours slowing down my FCS because and for the same people who are responsible for the ambigious situation.

------------

Comanche, i wanted to include your color-scheme, but because of the recent changes to the way colors are calculated, its now quite out of balance, sorry. Also, the special-color is very difficult to read on the background which you did choose. I'll include your color-scheme when you got some time to rebalance it.

- Lyx

Lyx, i don't know exactly what i did, but when i change Special_color nothing happens, just like something is missing in the code, so when i select some song on the playlist it gets too dark, the selected song only gets better when i use Light-theme.

In the colors i think i choose a mid-term for Light and Dark-theme and i can't figure out what side to choose

an small change in the color, i made it dark:


Dark-Theme


image: