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

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.

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?

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?

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 hell2. Its very configurable, looks ugly, but runs really fast3. 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.

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.

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.

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

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

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?

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

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