February 27, 2013, 18:46:54 Last Edit: March 02, 2013, 08:20:39 by stormwatch
Here's my itch:

Very often I need to filter the db by year of composition. I created a field Composition_year with "Field name"="Year of composition" and "Field Type"="common number". I can filter the db successfuly if I use the filter dialog box and create a new custom filter but still, I am having trouble to write the filter in the quick search dialog box widget thingy (dont know it's name, I mean the text entry box with the magnifying glass, is it called SimpleSearch?). After setting a play filter with for example, "Year of composition > 1950", updating the colection filter (Playing->Use the playing filter), and clikcing in 'Recent Filters' it shows "Year of composition > 1950" and updates the filter accordingly but if I type that string in the aforementioned SimpleSearch widget the filter shows no songs. I've also tried typing "Composition_year > 1950", "Year_of_composition > 1950", and variations on "Composition_year:>:1950\x1d" (that was the string in my gmbrc) I still cannot make it work.

That would be sufficient to be able to filter my db but I'd like to also store the month and day of composition in the cases  when they are known. I am thinking of two fields, Composition_date_start and Composition_date_end. A date field type could be really handy here. Those fields should also accept being filled with only the year or year and month when the month and day are unknown. Perhaps filling the unknown parts with zeros or whaterver way is better suited to work with the date representation perl libraries use.

thanks for reporting this, there was a small bug that prevented the SimpleSearch from working with custom fields, fixed in git : http://git.gmusicbrowser.org/commit/47306eda62
(it came from a change I made to support translated field aliases)
The custom fields configuration is not very clear, to use the field anywhere you have to use the form without spaces that is displayed in the fields column. So Composition_year>1950 should work now

About dates, yes it is planned, and yes I thought about the problem of handling some dates that are year, some that are month-year, or others day-month-year. I can't use the same type that I used for existing dates (added/played/...) as those are unix timestamps that begin in 1970 and have 1s resolution. So it will require a brand new type, that use other date functions. Can't say when, sorry

#2 March 02, 2013, 08:19:37 Last Edit: March 04, 2013, 02:16:00 by stormwatch
Thank you Quentin. Will I be able to save custom fields to files? I plan to add more, like Key (tonality), Mode (aeolian, major, maqam rast, octatonic, etc. ), Meter, Foot (binary, ternary)... perhaps would be easier if I add them as standard fields, it could even be the only way if I want to store this kind of information. In the case of Key for example, a single enum-like range from 0 to 11 that maps to key names (C natural to B natural)  wouldn't suffice because C sharp is not the same as D flat (altough it woul be nice to be able to filter including enharmonic keys). Two values are required instead to store tonality unambiguosly.

Saving custom fields to tags is planned, but again not sure when. Though it's not hard, I'm mostly a bit afraid of giving users a way to mess up their tags.
About the type of field, for what you are describing you should use what I've called "common string", the "common" part means that in memory it is stored as numbers, with a table that maps the number to the string. It uses less memory if the value is found often, and allows using the field in a FilterList.

#4 March 04, 2013, 02:09:58 Last Edit: March 04, 2013, 02:16:24 by stormwatch
So I made a mistake in assigning type "Common number" to Composition_year? It should be "integer"?

Earlier, I made an errata. Where it says 
QuoteC sharp is not the same as B flat
it should read
QuoteC sharp is not the same as D flat
sorry  ::) I've already amended it.

Quote from: Quentin Sculo on March 02, 2013, 17:36:52
Saving custom fields to tags is planned, but again not sure when. Though it's not hard, I'm mostly a bit afraid of giving users a way to mess up their tags.

great!!  :D
sorry for opening the other thread, I missed this bit  :)
I'm OT here, but I don't think you should worry about letting us mess with the tags.. we're not itunes users =) I think your userbase is savvy enough to handle even that overwhelming power :P

Quote from: stormwatch on March 04, 2013, 02:09:58
So I made a mistake in assigning type "Common number" to Composition_year? It should be "integer"?
Well yes, integer would be better. Common number is more for special numbers, that would need more space than an integer, but with few different values.