Development advice sought for adding metadata fields

[aramando]

I’m new to MediaMonkey and to get the most out of it I would like to develop some kind of extension, be it an add-on or script, to create additional metadata fields with which I can tag and then organise and search my media, as the standard track properties fields (including Custom 1-5 fields) are not sufficient for my needs.

So, what I would like to know is: is it actually possible to extend MM by adding new database fields to the “Songs” table to support additional metadata fields, and to modify the track properties sheets to enter data into these fields, and to filter and search on those fields using the column browser? And if not, is it at least possible to change the display name of existing fields that I do not need so I can use those fields instead, and perhaps also change the type of those fields (e.g. change the custom data fields to use listboxes)?

Any guidance will be most gratefully received, although at this stage I am really just trying to find out whether what I want to do is even possible.

Incidentally, I am not experienced with VB or VBScript so would rather program externally with C# in Visual Studio using the COM interface, but am happy to muddle through script development in VBScript by referring to existing scripts if necessary.

[Lowlander]

This is on the todo list for the MM developers. It will allow Addon writers to create additional tags that aren't natively supported by MediaMonkey.

[Mizery_Made]

Relevant Mantis entry: 6218: Scripting: Add support of non-standard frames in tags, and to an extent: 6248: Scripting: Ability to add a custom Page to the Track Properties Dialog

[aramando]

Thanks for the replies. I look forward to being able to create custom metadata fields.

In the meantime, I plan on using a disparate set of text fields that I currently have no use for (copyright, ISRC, etc.), and using the scripting API to create proxy custom fields for these, organised together with the labels I need, on a custom track properties sheet. Hopefully I will be able to present these proxy fields as drop-down text fields as well, even though the real fields that the values will be stored in are just standard text fields.

If anyone foresees any major problems with this approach, do please let me know; otherwise I will plug on.

Also, if anyone knows how I might be able to allow these fake fields to be searchable from the column browser, I would love to hear about it, although I suspect this isn't possible. I notice that even a few of the real fields I plan to use are not available as options for the column browser.